My Recipe for Agile Development

Software development isn't easy. It never has been. In an effort to tame the beast that it is, development teams and managers seem to come up with new methodologies on a daily basis. There's XP, agile, scrum, yadda yadda.

In the ten years or so I've been out of school, I've gotten to experience a handful of environments and styles. I started on a large development team in a huge organization and did some solo contracting work during that time. Once I transitioned to my current job, I developed solo for a while when the company was about half of the size it is now. As we've grown and I've grown my team, I've moved into managing a small group of developers on which my role is mostly advising and minimally developing.

Through those transitions, I've settled in on a few guiding principles that work for me. They might now work for everyone, but here goes:

Wiki Requirements: I like a living, breathing collection of requirements which my team and our end user or customer both have read / write access to. I also think it needs to have a single home instead of living in an office file which starts on a network drive and then gets duplicated into twenty different versions. It's best to keep it dead simple and in plain english. If everyone can read and understand it, it serves as an informal contract we can all refer back to. (This doesn't have to live on a wiki, but it's a pretty natural fit.)

Fast Iterations: The agile school definitely did get this one right. The faster we can put functionality in front of an end user and get their feedback on it, the faster we know if we got it right. It's almost impossible to hand over a product that doesn't meet your customers' needs if you work in short development cycles and constantly get feedback along the way. 

Find the right users for beta testing: Anyone who's done software will understand this one. The wrong users will give you vague, generally not very useful feedback. You won't get much insight into how you can make your product better.

If you don't have the right users, design your software to tell you when it breaks: The original Pragmatic Programmer gets credit for this one. It's particularly useful when your portfolio of applications has a significant number of background tasks. Unless you have a reliable way of being notified when a process goes awry or encounters data that causes it to throw an exception, you won't know about it. Nobody I know is diligent enough to review logs everyday. Don't kid yourself.

Painless Documentation: I know plenty of developers who'll tell you that good code negates the need for heavy documentation or that good code is your documentation. In practice, particularly with a language like Ruby, this can be pretty close to the truth. However, it's usually not sufficient. Between tools like RDoc and JavaDoc, adding meaningful, high-level explanations inline with classes and methods is so easy that it's almost seamless. I like to explain the context or the thought process which led to a particular approach here, since that's usually the first thing I forget when moving on to another project. If you write clean code and abstract everything properly, your code can come pretty close to speaking for itself otherwise.

This is such a massive topic that I've only barely scratched the surface. I could probably write another 50 posts on it and still just cover only a fraction of the body of knowledge out there. But it's a start.

Business Email Style Guide (pt 1)

I am a huge fan of using email to get things done. However, the way in which some people use it bugs the crap out of me. It's entirely possible that I'm just more anal than most, but there are some simple rules which I think bear restating:

• I don't care that you're not writing a formal letter. Using bad grammar, stupid abbreviations (such as "thanx") or incomplete sentences all make you sound like an idiot. I don't want to read your email and will probably discount whatever you have to say in it if I think you sound stupid.
• Email is a wonderful mode of communication for a few things: quick thoughts or requests, formal communication where it's important to be able to refer back to what was said at a later date and asynchronous communication amongst others.
• Email is not a good tool when a discussion about something simple drags on for more than two emails in either direction. Did everyone forget about their phones with the advent of crackberries?
• Make whatever point you're trying to make clearly and quickly. You're not writing a novel. (Or even a short story.)
• Before you carbon copy anyone, seriously consider whether they need to get whatever it is that you're about to send them. It's one of my pet peeves to get an email which I don't really care to read just because someone thinks they need to "keep me in the loop," or to receive an email with other people cc'd for the same reason.
  
• Contrary to what some other folks preach, courtesy thank you and you're welcome emails are just fine.
  
• Lastly, please don't ever send anyone an email from your smartphone which serves little to no purpose. My very informal observation is that people tend use such devices to communicate more frequently and faster, but with far less valuable thoughts than they would otherwise.

Call me old fashioned or crabby, but I hate to see the demise of the art of communication because of a collective decline in the standards we hold ourselves to.