Thank you everyone who attended our presentation last night at the Calgary Agile Methodologies User Group. We had a tonne of fun, and hope that you took away some valuable information.

If you're going to practice any form of unit testing you need to learn about the different types of tests. I have yet to read XUnit Test Patterns, but I'm sure this will offer a great deal more detail then this post. Also, I'm anxiously awaiting "The Art Of Unit Testing"

Unit Tests

Unit tests are blocks of code that exercise very specific areas of a code base to ensure the it is meeting it's responsibility (NOT responsibilities in the plural sense. See Single Responsibility Principal). At it's core its asserting that a very specific result or behavior is met. Unit tests can be broken down into two types.

Black Box Testing (State)

The first is the traditional state based (black box) unit tests. These are unit tests that assert that components of the system exert a behavior that expected from the perspective of a client component. It cares less about the actual implementation of the component and more about the result. These types of tests tend to be easier to refactor and are a great way to start learning about test driven development or unit testing in general. The unit tests give you the confidence to go in to the trenches and make significant changes to the underlying implementation. This allows you to evolve a code base with confidence and precision. (And remember software development is an evolution. Using the same architecture and tools that you did from several years ago could indicate a smell.)

For example:

        [Test] publicvoid Should_be_able_to_lease_a_slip()
{ ICustomer customer = CreateSUT( ); ISlip slip
= ObjectMother.Slip( ); ILeaseDuration duration
= LeaseDurations.Monthly; customer.Lease(
slip, duration ); Assert.AreEqual( 1, ListFactory.From(
customer.Leases( ) ).Count ); }

White Box Testing (Interaction)

This type of unit test is more focused on the interaction of components then the result. It's verifying expectations that components are working as expected with it's dependencies under different conditions. It's a way to simulate different environment conditions without actually having to exercise the component in that environment. The canonical example is to mock or stub out an interaction with a database or third party component.

It's called white box testing because it's like you can see clearly through the box to see what's going on inside. It might make more sense to refer to this as glass box testing.

For example:

        [Test] publicvoid Should_leverage_task_to_retrieve_all_registered_boats_for_customer()
{ long customerId = 23; IList< BoatRegistrationDTO >
boats = newList< BoatRegistrationDTO >(
); using ( _mockery.Record( ) ) { SetupResult.For(
_mockRequest.ParsePayloadFor( PayloadKeys.CustomerId
) ).Return( customerId ); Expect.Call(
_mockTask.AllBoatsFor( customerId ) ).Return( boats ); } using (
_mockery.Playback( ) ) { CreateSUT( ).Initialize( ); } }

Integration Test

Integration tests are tests that sweep across a system. They exercise the system from top down, to ensure that it is behaving as expected in a production like environment. This is a great place to weed out contracts that have not been implemented, and help to identify different environment scenarios that may need further unit testing. These tests actually hit the third party components and exercise the full system. These tests typically take a little longer depending on the environment conditions such as hitting a database.

There are frameworks available, such as Fit, that allow business analysts to define test criteria that can then exercise the system top down. The problem with some of these frameworks is that they can implicitly allow the BA to start designing how the system is implemented if taken as a literal design spec. I much prefer writing top down tests rather then implementing fit-like fixtures.

One of the books I've read this month is....

Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series) by Kent Beck, Cynthia Andres Read more about this title...

I really enjoyed reading this book. It paints a picture of what an ideal XP team can look like and talks about the principals, practices and values of XP. I'd like to share some excerpts from the book that really stuck out and hand an impact on me.

"If you have six weeks to get a project done, the only thing you can control is your own behavior. Will you get six weeks' worth of work done or less? you can't control others' expectations. You can tell them what you know about the project so their expectations have a chance of matching reality. My terror of deadlines vanished when I learned this lesson. It's not my job to "manage" someone else's expectations. It's their job to manage their own expectations. It's my job to do my best and to communicate clearly."

One of the things I learned about myself is that I hate being late. This isn't a great trait to have in the world of software development. When I'm handed a deadline I become so eager to meet it that in the process of racing to the deadline quality is compromised. I can't control deadlines or others expectations but I can control my own behavior and if I work consistently as hard as I can without letting go of quality.

"I chose practices for XP because they meet both business and personal needs. There are other human needs; such as rest, exercise, and socialization; that don't need to be met in the work environment. Time away from the team gives each individual more energy and perspective to bring back to the team. Limiting work hours allows time for these other human needs and enhances each person's contributions while he is with the team."

It sucks how XP and Agile have become buzzwords in the industry that mean more to the marketing department then to the software developers. I've said it before and I'll say it again...

"You aren't doing Agile. YOU ARE AGILE!"

"Part of the challenge of team software development is balancing the needs of the individual with the needs of the team. The team's needs may meet your own long-term individual goals, so are worth some amount of sacrifice. Always sacrificing your own needs for the team's doesn't work. If I need privacy, I am responsible for find a ways to get my need met in a way that doesn't hurt the team. The magic of great teams is that after the team members develop trust they find that they are free to be more themselves as a result of their work together."

You've got to sacrifice something, regardless of context you're talking about, in order to succeed. What's important is deciding on what you're willing to sacrifice in order to get closer to your end goals. I have found that pushing the people outside of their comfort zone a little bit not only helped me in growing but also the team as a whole. I also learned that it's important to slow down and reflect. The up and down rhythm of an XP team is balanced by the different members of a team, and with trust it's much easier to maintain that balance.

E.G. Team member A might be a hardcore, heads down, must punch out code as efficiently as possible. Team member B may be more of a let's take it a little slower and sit back and think about the problem at hand kind of guy. With trust the two team members will be able to develop a rhythm that keeps the project going at a sustainable pace without sacrificing quality.

"I trust two metrics to measure the health of XP teams. The first is the number of defects found after development. An XP team should have dramatically fewer defects in its first deployment and make rapid progress from there. Some XP teams that have been on the path of improvement for several years see only a handful of defects per year. No defect is acceptable; each is an opportunity for the team to learn and improve."

Test-driven development/design rather then design in your head driven code. The test is a clear statement of truth. It documents the design that would otherwise be locked up in your head and is very black of white about whether or not the subject under test satisfies the test specification or behavior that is expected. If the team is not disciplined even the best of the best XP teams can forget about the principals behind the practices, and stop following the practices. One of the most important things about unit tests is the early feedback. I want to know as soon as possible when a component in the system is not behaving as expected. By waiting for QA to pick out bugs, then log a bug, then assign a developer to look at the bug does not deliver early feedback, I consider this waste! It's a vicious cycle that can be reduced greatly.

"The problem with reviews is that most reviews and raises are based on individual goals and achievements, but XP focuses on team performance. If a programmer spends half of his time pairing with others, how can you evaluate his individual performance? How much incentive does he have to help others if he will be evaluated on individual performance?"

Out of all the chapters in this book I think chapter 3 is my favorite. It's titled "Values, Principles, and Practices", and to me it speaks the loudest of what is XP and why would we want to consider using it as a methodology for building and delivering software.

I highly recommend this book!

Ok so I have to admit that yesterdays entry cleverly titled "Software Sucks" was a little impulsive and over the top. Software does not suck!

I suppose I over reacted a little bit, but I think the reason I was so upset is because I want people to have positive experiences when working with software that I hand craft for them.

At Subway I love their concept of "Sandwich Artists" where they craft the sandwich right in front of you. You're there for every step of the process, minus the baking of the bread and prepping of the toppings etc etc...

What if software were built in a similar fashion? Do you follow where I'm going.. what if the end user was there for every step of development so that they get the software that they want. Now in an ideal world that would probably amount to bloated budgets and the never complete software. But what if we could get the end user to prioritize and pick the things that are most important to them and guide us as we build the software for them.

You are not doing Agile, you are Agile!

I was a part of an interesting conversation today with Sean and Adam where Sean brought up a great point. (Pardon me Sean if I paraphrase incorrectly!) In the eyes most companies, a software project was successful if it was on time and on budget. Until you can prove to the company how the inefficiencies in software are actually costing them money, you probably wont be heard.

So how does one go about creating change, well start with the all mighty dollar! Perhaps one tactic for introducing Agility into an environment is to discuss how it can save you money. I'm not a big fan of graphs and excel sheets and charts, but I've found that it's usually a good way to communicate with people who have money or are responsible for spending money.

So hit 'em up with a little "Agile vs. Traditional Cost Models" talk. Mr. Joe Ocampo says it best with:

"The quicker you are able to stabilize a production release the more you will increase the value stream for the business." - Joe Ocampo

Sean offers his thoughts on how to introduce change in your shop and why it's necessary. It's definitely worth a read.

With that said... my love of software development continues!

Very few things bring people closer together then dealing with adversity together. It's easy to enjoy good times with others, but people come together when they deal with tough times together.

You never truly get to know someone until you see all sides of them. You've got to see them sad, mad and glad. You've got to get unfiltered, and raw emotion from them to truly understand them.

Pairing is a lot like this, when you put 2 software developers together to solve a problem. It brings them closer together when they solve the problem, together. You get to know all sides of the person quite quickly, from how the deal with stress, to how they deal with differences of opinion, to the pleasure of winning small battles.

There's always a bit of anxiety at first when you put 2 developers together who have little knowledge of one another. It's seems like they're sizing each other up for a fight. ("I can take 'em"!) That's really not how it is, or should be. If you're both focused on the problem at hand, and spend less time worrying about whether your skill sets are up to par, you free yourself to truly enjoy the benefits of 2 minds coming together to put out true value.

One of the things I think I do without actually realizing it is, I announce what I perceive the others persons feeling as my own. When you hear someone say that they feel the say way as you, you tend to feel a little more comfortable with them, and some defenses drop.

When you're pairing with someone, you're completely focused. You don't want to waste the other persons time. The other person surely isn't going to sit idly while you IM back and forth with someone, at least I hope not.

Finding a good pair can be hard, if you don't find one that is close to you in skill and experience it can become more like mentoring. But even a few sessions of mentoring and you can quickly level the skill set of the team. More seasoned developers shouldn't feel like they have to slow down so that the rest of the team can keep up. With constant pairing everyone comes up to speed much faster then doing it alone.

I'm definitely no seasoned veteran when it comes to pairing, but in the last little while at our studio we've gone head first into pairing and I'm really enjoying it. It's so exciting, and it really feels like we're putting out more, much faster and the quality bar feels higher.

For a more experienced take on pairing check out Wendy's post on The Joy of Pair Programming.

One of the few things I've learned in the last few weeks is to not be so politically correct when it comes to sifting through code. What I mean is, if you spot a piece of code that can improved, then address it.

Don't hold back your comments because you're worried that the author of the code will feel attacked or hurt. There's also constructive ways of doing this, if you're intentions are to make someone else look bad or prove that you're a better developer then everyone else, then you've got some character flaws that probably need addressing.

If you spot code that smells deal with it. Explain why it smells and construct ways to improve it. You're not helping anyone by holding back your true thoughts. The only way you and your team is going to get better is if you constantly offer each other feedback.

With constant feedback you might start to notice more more light bulbs turning on in your teams heads. It's no use if only you can see why a certain piece of code smells, but the rest of the team needs to see it to.

Most developers try to put out the best possible code that they can. They want to deliver value, so if you spot a better way that someone can do that, show them. It's the code that sucks, not the author.

On my bus ride home yesterday, I was trying to think about what separates our office from others and I realized it was that our office was less like an office and more like a design studio.

A studio celebrates discussion and creative thinking. It challenges you to think creatively and outside the box. Your uniqueness is what makes your product a better option than your competitors.

I asked my wife what she pictures when she thinks of a designers studio. Here's some of the things that she said:

• Open style loft
• A New York style high rise building with lots of windows over looking a park or people walking along the street.
• Boards on the wall covered with peoples ideas.
• No cubicles
• Elevated desks, like the ones architects use that are tilted sideways and are high enough to look outside.
• One long table where people can come together.

My picture of a designers studio is quite similar, except I see white boards scattered just about every where. So you can have an impromptu design session while eating lunch, where you can literally stand up and start writing on the wall. I picture an open work space, where people can actually see each other work. I picture constant communication and feedback.

When I think of an office, I picture cubicles where people spend their days isolated at their desk. I picture a lot of emails being read and answered. I picture a lot of phone calls being answered, and less face time with people. The office is usually quiet, so if you want to have a discussion you've got to send a meeting request through outlook and book a board room to communicate with others.

Why is that when we think of where software developers work its in an office and not in a studio. Designing software is a lot like designing art. It takes a lot of creativity to build code bases that not only deliver clients value but also make other developers want to contribute to the code base.

In my opinion, if you are striving to create an Agile shop, start by trying to create a studio environment and leave the office behind.

This is a story about building the great wall of agility. In the last few month here at the office we adopted this concept of the visual workspace. It's awesome! We lay out our story cards and tasks out on the wall and as soon as you walk in the door you're immediately reminded of what you're currently working on, how far you are from the finish line and who else might need some help.

Our first wall, was literally a wall with sticky notes on it. In the corner of the above picture you can see a photo of "Jim". Jim, was our image of the typical user of this application we were working on. Anytime we had to make a design decision we asked ourselves... "What would Jim do?" 

Our latest wall is a glossy wall that our manager picked up from Rona. It's excellent, because it doubles as a white board. It allows us to write up impromptu design discussion up on the board after our morning stand up.

One of my favorite new additions, is the sprint retrospective. It's a time for a critical look back and to hold hands and sing songs...

Yesterday at work my manager had a group of us get together to watch a presentation by Mary & Tom Peppendieck on Lean development. It was a really good discussion on identifying what makes company's successful and sparked a lot of conversation afterwards. One the major takeaways from the video were the 7 principles of lean software development.

1. Eliminate Waste
2. Build Quality In
3. Create Knowledge
4. Defer Commitment
5. Deliver Fast
6. Respect People
7. Optimize the Whole

Later this afternoon us dev's will be getting together to discuss what these 7 values mean to us, and how to identify and measure them. In the meantime I thought I would share some of my thoughts on the principles just to get my brain warmed up.

1. Eliminate Waste. For me there's nothing more painful then working on something that does not need to be worked on, or building something that does not need to be built. This point drives out the idea of focusing directly on exactly what is necessary to accomplish the goal. Waste is produced when you create unfinished work. (I have a lot of that, you should check out my sandbox) Or building in features that aren't needed, and carry with it potential for introducing "bugs".

2. Build Quality In. I think by developing with a test first mentality you implicitly build quality in because you're only building the system that is required and you're verifying that it's doing what it's supposed to do with unit tests. When the system needs to change, the unit tests help you to verify what parts of the system has been effected by your change. This reduces the "blind faith" attitude of building software in hoping that it works, and instead verifies that it does what it ought too. Verify it!

3. Create Knowledge. To me this goes further then just reading books. True knowledge comes from experience, so to create an environment we need to practice and learn. Books are a great way to start, but following through with practical application of the reading is what makes the reading valuable. What use is it if it just sits in your head?

4. Defer Commitment. When you practice Big Design Up Front, you very rarely have all the information you need to make decisions or even estimates. Like Mary says "The beginning is the time of maximum ignorance." We often jump to making big decisions up front when really most of them can wait, until we have more information. Work towards short term goals, and piece by piece you'll eventually complete long term goals. It may turn out your long term goal ends up being slightly different from the short term.

5. Deliver Fast. This isn't about hacking together code to meet deadlines. I interpret it more as setting shorter milestones and deploying more often. Do we need a web application, that does reporting, and registration all at once? Can it be broken down?

6. Respect People. Ultimately people want to do more good then bad. So "enable" them to do so by treating them with respect. You're not always going to see eye to eye, nor would you want to. But if you're passionate about your stance, speak up and say why. To respect someone you must also be willing to listen,

7. Optimize the Whole. Throughout your cycles whether daily or monthly be conscious of bottlenecks, and take the time to reflect. What's slowing you down? What's not working well? Why? Figure out what or where the weaknesses are, then figure out why and how it can be improved.

As usual wikipedia has some wisdom to share.

More Info can be found here...

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn Read more about this title...

The XP Values

• Communication: Most desirable is face to face communication where we can talk, respond, gesture and draw on a whiteboard. Talking = good, documents = bad!
• Simplicity: Focus on creating a solution to the problem faced today, not the problem anticipated tomorrow.
• Feedback: Developers give and get feedback from pair programming, from automated tests, continuous integration. Customers are part of the team even sitting in the same space with the developers, and provide feedback through constant interaction with the team, and through acceptance tests. 
• Courage: They have courage to refactor their code, proceed with an overall master architecture.

The Principles of XP

• Rapid Feedback: Constantly sending and receiving feedback, and responding to it.
• Assuming Simplicity: Favor simplicity and attempt to create a simple solution before evolving to a complex one.
• Incremental Change: Improve the software through small, incremental changes.
• Embracing Change: Developers are able to adapt and accommodate change.
• Doing Quality Work: Insist that the software consistently exhibits the highest level of quality workmanship.

I'm still fascinated by the Agile XP methodology. So when I came across the overview of XP in the Appendix of...

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn Read more about this title...

I had to read on. Here's what I learned:

Roles

• The XP customer role is responsible for writing stories, prioritizing stories, and writing and executing tests that demonstrate that stories were developed as expected.
• The XP programmer role encompasses a broad range of technical skills. XP projects tend not to draw distinctions between programmers, designers, DBA's and so on.
• XP teams benefit for the use of an XP coach and possibly a project manager. The coach is responsible for monitoring the team's use of the XP practices and gently nudging them back on track when they stray.

The 12 Practices

Small Releases

Project progress in a series of iterations, which are typically 1 to 3 weeks long. Features are fully delivered within a single iteration.

The Planning Game

• This is the name for release and iteration planning where developers and customers collaborate to make predictions about the future.
• Prior to planning, the customer has written user stories on note cards and developers have estimated the cost of magnitude of each story and have written the estimate on the story card.

Refactoring

• Refers to the restructuring or rewriting of code so as to improve the code without changing its external behavior.
• XP advocates constant attention to refactoring. Whenever a programmer makes a change to code that should be refactored, she is required to refactor it.
• She's not encouraged to refactor it; she's required to refactor it.
• Instead of spending time upfront thinking through a system in advance of coding it, and therefore taking guesses at some aspects of its behavior, XP systems are refactored and kept in a state that perfectly meets known, implemented requirements.

Testing

• The developers write automated unit tests.
• The customers write acceptance tests.
• In test-driven development, tests are written before the code. Developers follow a short cycle of test-code-test-code... No operational code may be written except in response to a failing test.

Pair Programming

• Refers to 2 programmers sharing one computer and 2 brains to write code. One programmer types the code, the second is watching the code develop and thinking more broadly about the code.
• This leads to lower defect counts, less code is written to solve the same problem, problems being solved more quickly, more people understand each piece of code, an increase in developer satisfaction.
• It requires discipline to refactor every time you notice poorly structured code.

Sustainable Pace

• The believe is that an XP team moving at a consistent but brisk pace will achieve more over a period of time than will a team working at a pace they cannot sustain over a long period of time.
• It is up to the team to determine their sustained pace.
• A team will typically devote around 6 hours per day to pairing and spend the remainder of the day in other activities.
• An XP coach is responsible for monitoring the team for burnout.

Team Code Ownership

• It's common in non-XP teams for individuals to "own" portions of a systems code. This leads to comments like "We can't change the billing source code until Eli gets back from vacation."
• All code is owned by everyone.
• Pairs are expected to change code they didn't write.
• A strong suite of unit tests ensures that changes do not introduce unanticipated side effects.

Coding Standard

• XP teams collectively own their source code, so it's important to follow a coding standard.
• A small, close-knit team may be able to get by without a written, formalized coding standard.

Simple Design

• Pursue a goal of having the simplest possible design that delivers the features a customer needs.
• The operational code and the test code fully convey the programmers intent.
• There is no duplicate code.
• The system uses the least number of classes.
• The system uses the least number of methods.

Metaphor

• Quest for simple design by finding a metaphor that can be used for the whole system. The metaphor describes how they think about the system.
• E.g. "The system is like a chalkboard and various parts of the system can write on the chalkboard. When a user is done with the system she can either save the contents of the chalkboard or erase them."

Continuous Integration

• Code is integrated continuously.
• A developer completes a small change, he checks the change into source control, where the CI box initiates a full build. When the build is finished a full set of unit tests are run. If any tests fail, the developer is notified by email and told about the failure.
• Integration problems are fixed one at a time in extremely small batches as soon as they occur.

On-Site Customer

•  The customer is expected to sit with and be part of the development team. The customer writes the stories and the acceptance tests and is also available to answer questions as they arise.
• If the customer is not on site, delays will disrupt the predictable progress of the XP team.

Last night I finished reading...

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn Read more about this title...

It was a nice quick and dirty read, to get my feet wet in the world of applying user stories. I really prefer working with user stories as opposed to full blown system requirements specifications. Although, a typical SRS is much thicker then a set of user stories, I think more information is delivered through user stories because it done so piece by piece. As you require the information, it's your responsibility to gather it.

I want to share some of my favorite quotes from the book.

"Pay attention to who is contributing during a story writing workshop. Occasionally a participant will remain silent through much or all of the meeting. If this is the case, talk to the participant during one of the breaks and make sure she's comfortable with the process. Some participants are reluctant to speak up in front of their peers or supervisors, which is why it is important that story ideas not be judged during these sessions. Once participants become comfortable that their ideas will simply be noted, not debated, at this point they will contribute more readily."

I have to admit that at my first story writing workshop I didn't say much. It was kind of a foreign concept to me and I worried about getting shot down by the other developers if I mentioned a story idea. I felt like there was a good chance that would occur because the rest of the team felt they had a similar vision of how the product would look and feel before and discussion had even begun. I later realized that they did indeed want to hear my story ideas, but it just took some time getting used to the culture of the team.

"When you cannot find, or get access to, a real user, avoid falling into the trap of thinking you know your users' minds and do not need or can ignore your user proxy. While each type of user proxy has some type of shortcoming that makes her less desirable than a real user, most developers come with even more shortcomings for pretending to be a real user. In general, developers do not have marketing backgrounds that allow them to understand the relative value of features, they do not have the same amount of customer contact as salespeople, they are not domain experts, and so on."

I know as a developer that there are many times where I know how I would like a piece of software to work. Because it would work well for me, but ultimately that's not always going to work best for the end user. It's difficult to put yourselves in someone else's shoe to try to think like they would. It's much easier to just ask, instead of making a design decision, implementing it then later having them tell you that's not what they wanted.

"Ideally the customer writes the stories. On many projects the developers help out, either by doing the actual writing during an initial story writing workshop or by suggesting new stories to the customer. But, responsibility for writing stories resides with the customer and cannot be passed to the developers."

Wow... I had no idea. Right now we're writing the user stories...

"In a blame-filled organization there are always some individuals who have learned that their best decision is to avoid all responsibility. If you're not responsible for something you can't be blamed for it when it fails, yet there's usually a way to lay claim to at least some of the success. Individuals in this type of culture will want nothing to do with hard decisions like prioritizing features into and out of releases. They'll fall back on statements such as "It's not my problem that you can't complete everything by the deadline, figure out a way to do it."

This seems to happen more often then not. I think when someone because slightly hostile, it's usually because of their own insecurities. But reading the above statement just helped me to realize to think about what they're going through. Who's grilling them, and how can I help so that they're are happy with the software but it also makes them look good to their peers.