A Developer’s Praise of Agile
October 17, 2011 | Jason Kozemczak
In case anybody was wondering where I’ve been for the past 8 or 9 months, I’ve certainly kept busy. Aside from getting engaged and buying a house, I started working for a great company in Saint Louis called Asynchrony Solutions (we’re hiring). Aside from everyday work, I’ve also been working on a number of different side projects, some of which I’ll hopefully have time to write about in the near future!
One of my biggest takeaways from Asynchrony thus far has been agile and extreme programming (XP) practices. Below are a few reasons why you should appreciate agile as much as I do:
Pair Programming
Ahh, but of course, there’s no way a post about XP/agile would ignore the oft-mentioned practice of pair programming. I figured I’d go ahead and get it out of the way. I realize that there’s a reason pair programming is often touted as the cash cow of extreme programming: it’s pretty damn awesome.
What pair programming has taught me (and continues to teach me) is that if we can’t explain our logic and thought process to an individual sitting next to us as we write the software, there’s no chance in hell anybody will be able to decipher it later (btw, comments are cheating! A codebase littered with comments is probably telling you that you’re doing it wrong). Pair programming in this way helps the developer determine very early the intent of the code he or she wishs to write.
Pairing helps me learn alternative approaches to problems. It allows me to gain the insight the person next to me has. As such, I’ve probably grown more as a software developer in the past few months than since the time when I first started writing software. Not only that, but you get to learn new keyboard shortcuts (or face humiliation of your peers!); double rainbow, all the way!
The final perk of pairing is that you often don’t have to type as much. Unless you’re a keyboard hog, of course.
Kanban
Kanban is system pioneered by Toyota for managing lean processes involving supply chain management (though it can be applied to many processes, including SDLC). To give a quick and somewhat trivialized description of Kanban: index cards are placed in pools on a large board. Each pool has a size limit, so that when a spot becomes free, a card can be promoted or “pulled” into the next pool.
Applying Kanban to software development, at the beginning of an iteration, we break iterations down into stories which are then written onto index cards. If the amount of effort required by the stories is greater than the team has historically been able to complete, stories can be prioritized and moved to later iterations. Once the cards for the iteration have been determined, they are all placed in the first work pool. Cards are then pulled into the next pool as they begin to be worked.
What the pools are called and represent will differ, but generally most of the Kanban boards at my company have a starting pool, an “in development” pool, a “review” pool, a “UAT/integration” pool, and a “completed” pool. Limits are imposed on each of these pools (aside from the “completed” one); these limits are often based on team size, velocity, and past history. They can be adjusted as iterations pass to better fit for the team (continuous improvement, yet another joy of agile!).
There’s a significant amount of subtlety to Kanban that I’m glossing over. I recommend to RTFG if you’re curious. I’d rather focus on why it works for me; one of my least favorite aspect of being a developer is that I have often in the past felt like my voice was often ignored in favor of business owners and more functional types. In waterfall-ish situations, this lead to unrealistic deadlines which were ultimately missed, at which point undue blame would be pushed onto development.
A Kanban process leaves the act of determining story length/weight up to the developer; this added responsibility gives me as a developer a greater sense of ownership, instilling the desire to meet deadlines while also making me more likely to accurately estimate development effort (win-win for both sides!).
A subtle yet powerful psychological effect of Kanban is the feeling a person gets by “pulling” a story to work. The language used was intentional. Instead of having work pushed upon you, you as person taking part in a Kanban process must consciously pull work from the previous pool. For me, this helps with morale and also tends to reinforce the ownership I mentioned above.
Test-Driven Development
I get this sense that your everyday IT manager thinks of agile as a bunch of cowboy coders spewing sphagetti code from their six shooters bolstered at their hips. This could not be further from the truth. Agile is disciplined. Let me repeat: Agile is disciplined. It takes patience and diligence to practice agile correctly. Test-driven development (TDD) plays a big role in guaranteeing this discipline.
TDD allows developers to programmatically determine if the code we are writing is doing what we expect it to do. Ideally, every (or as many as possible) behavior of the software can be proven by a test; when a story calls for a new piece of functionality a TDD practioner will write an example (i.e. a test) proving that the software does not do the thing the story wishes it to do. He or she will run that test, and it will fail. The developer will then write the code necessary to make the system behave as the story (and subsequent test(s)) expect it to behave. The developer can stop once the test(s) pass.
This process can be repeated over and over, building up a large number of tests which help to ensure that the software will continue to perform the things it should do. If we make a change that breaks a feature of the system, a corresponding test will fail, signalling that we have taken away some functionality of the system. This quick feedback loop makes it much more difficult to introduce bugs.
My favorite part about all of this? A developer with excellent test coverage can refactor with impunity. You can refactor to your heart’s content (as we probably often do anyway…), and as long as the tests pass, you can rest assured that the software is still doing the things it should do. That is an empowering by-product of TDD.
tl;dr
Agile development has a lot to offer. Though I’ve only lightly grazed over those areas that have most affected me over the past few months, if I’ve at all interested you, I suggest checking out what others who are more knowledge than me: Kent Beck, Martin Fowler, or Asynchrony’s own Brian Button. There’s several other tenets that I have passed by (continuous integration, release often, etc.) that are worth your time.
If you’re interested in lean methods in general, I just finished Eric Ries’s The Lean Startup, and I thought it was a great read. Ries gives a strong argument for utilizing agile/extreme programming in startups specifically, but the substance is applicable to businesses and organizations of all types.
