Sowmya Karmali on Agile Development

... that was what the title said. Yesterday, I had a talk at the .NET User Group in Monrovia on Agile Development. It was a 90 min session excluding the break, thats a long time for someone to be talking. Thanks to the great audience, it was a breeze. My slides:

Part I: the ten commandments for an agile developer


Part II: Agile tools for .NET Development


Here are some interesting points raised by the audience. I'd like to see your opinion too.

(On TDD) What if you are enhancing or maintaining an existing version of a product that doesn't have test cases written? How do you convince management that you need that extra time to write those test cases?

(On build scripts) If your testing required some data in the database, how do you include that into your build script?

(On estimation) How do you estimate for an agile project? Especially when you say you aren't going to freeze your requirements in the first place.

(On FDD & Iteration planning) If you have a product that requires some meta data modeling, how do you plan to do it iteratively? You need to complete the meta model in order to have a complete design.

There were all the usual elements of a geek meetup: pizza, coke, books, oversized t-shirts...I'm glad some things don't change.

My talk on Agile Development

On 19 September, I'm going to deliver a talk on Agile development and Agile .NET tools at the San Gabriel Valley .NET user group meeting. Here's a link to the details. (Note: this link will go bad in about a month's time -- you'll discover why when you click on it.)

The first part of the talk is based on my earlier blog post on the 10 Commandments for an Agile Developer.

If you or any of your friends are going to be around in around Los Angeles, do drop by for the pizza and coke ;).

At Code Camp, San Diego

Got bitten by the BarCamp bug again. I spent the last weekend at the Rock and Roll Code Camp at San Diego. This was one unconference that covered a lot of MS technologies. I got my fill of Silverlight, CardSpace, and some refresher/updates on WCF and WPF. I also saw an good demo of TeamCity. This is a build management tool (quite comprehensive) from Jetbrains, the same guys who make Idea, my favorite Java IDE.

My presentation on "The Ten Commandments for an Agile Developer", was based on a post I wrote earlier. My slides:





This was one unconference that made the speakers feel extra special. A speakers' room, bags and t-shirts as audience giveways, and even a speakers badge! I'm saving mine :), I've never seen it in an unconference before.

The Ten commandments for an Agile Developer

I'm not playing God, just being Moses.

I'm putting down things that I feel are important for any developer in an Agile project. For me, any project that involves iterative planning and continuous integration is agile enough to begin with. One can see enormous benefits just by following principles like feature-driven development (FDD) and test- driven development (TDD). You dont have to go from zero to XP or Scrum to be agile. In fact, I think agility is a continuum and each project needs to find its sweet spot on it.

A lot is said and written about the need for self-managed development teams in an agile project. I interpret "self-managed" in a psychological way - I think it is a frame of mind that you need to be in, day in and day out, throughout the project. It requires rigour and a sense of self discipline. This may raise the hackles of developers who think discipline chokes innovation, and it takes out the "cool"-ness out of programming; I'll turn the argument on its head and say that to be truly innovative, you have to be disciplined about your fundamentals.

The rest of this article is about those ground rules. I'm not advocating any Agile process over another - follow whatever processes your project has decided to. This list is a daily to-do list. Over time, these things will be next to breathing for you as a developer (Do you realize how many times you hit Ctrl-S in 5 minutes?). They're really so simple, I should have called this the Zen way of agile development. I've seen its benefits, and more importantly, seen the mayhem caused when these rules arent strictly followed.

Write tests before code. Use a testing framework - there's one available for your language. Writing tests first ensures that you write just enough for the functionality of your program to work, nothing more. We often spend a lot of time writing that one extra method with that one extra parameter just in case you need to use it tomorrow. None of this happens if you first write a unit test before actually writing the code. How many tests should you write? The minimum required to make the code feature complete and secure. Use test suites liberally to create user scenarios involving a set of features. Execute these in your coffee break (Heck, why does the computer need a break?!).

Build from source on your local machine. Every day, before you start work, take the build from the build server (you should have one, btw). Treat every checkin as sacred, especially when fixing a bug. Gone is the era when you could say "it works on my machine". They dont even joke about it these days. Before you checkin, make sure you run the build scripts locally. If it takes too long to make a build, it is the build process that needs fixing (good ruse to ask your manager for a better machine ;) ).

Be lazy (automate everything you can). I mean, thats what the computer is supposed to do, right? Take the repetitiveness out of a job. So, please put the computer to work at the True Purpose for which it was invented. You can build, deploy, test, report bugs, clean-up just by pressing some shortcut key combination. There are plenty of tools available to do this - lots of them are open source too, so there's no limit to how lazy you can afford to get. I'm not going to go into details of how to automate a project (too long, and out of scope for this article), but here's an excellent book that tells you how to: Pragmatic Project Automation.

A feature in the (daily) build is worth two on the (drawing) board. This is about planning how to write your code. Rather than having "database days", where you do all your table design and "UI days" to layout all your screens, have "Create User days" where you write just that one feature - end to end. At the end of the "Create User days", someone who installs the build should be able to actually, create a user in the way your product spec says it should.
Not only is this more gratifying for you as a developer, the whole product starts taking shape much earlier, allowing for mid course changes that may come along because of end user requests, market changes, and... innovation.

Write meaningful comments. If your product is worth something, there'll be modifications to the codebase for years to come. Be polite, and write a line or two about how your method implements the feature. Rather than say /* this method authenticates the user */ (that should be clear from the way you name the method), say /* this method checks the user credentials against the LDAP server. It assumes that the LDAP connection properties are specified in a file called LDAPProperties.xml*/ It takes less than a minute to type that out, and everyone who reads your code - whether to enhance it or to use an API will bless you for it.

Honour change. Change == Good for the product. I deliberately didnt say "accept change". I think we all are mature enough not to crib when requirements change, but we still think of change as something that throws our well made plans awry. In an agile process, assume that change will happen no matter what you do. Plans will change with each iteration, features will change as users start using them, code will change as you refactor and/or integrate. In fact, it is this ability to respond to change that is one of the core tenet in the Agile Manifesto.

Love thy neighbour's code. Code reviews are one of the best software development practices I've seen. A code review can catch a lot of "thingies" early that would otherwise grow up to be "bugs". Especially in a time crunch, we tend to make some easily catchable and fixable errors (we're all so human). Loving your neighbour's code also means understanding it enough to be able to fix a bug in it. Get yourself into the habit of doing code reviews and getting code reviews done. Like debugging, it is a skill that is constantly honed with experience.

Communicate, mate! Key sucess mantra for many things in life - whether it is marriage, a football match or an agile project. If you changed a piece of code in the build, tell the rest. If you are stuck with an algorithm, ask for help. If you think you arent going to meet your deadline, say so upfront. If you found a tool that would save everyone's time, communicate. If you have the next big feature idea for the product, communicate. I think the first thing a project manager should do in an agile project is to setup a communication platform. This could be a wiki, a mailing list, a list of phone numbers, a notice board - or all of them. It is super important that everyone (including the customer) is aware of the status of the project on a daily basis. Use all the
tools you can to make communication better.

Refactor...when you need to. Developers love to refactor - there's always a better way to write that class. Refactoring code should be a part of every project because of the iterative nature in which the code was developed in the first place. Your only objective in the first iteration is to get the feature to work. In the next, you can revisit the same code (or identify common pieces of code) and refactor it into a design pattern, optimize the resources it
uses and so on. (A good refactoring catalog is available online, most of it is from Martin Fowler's book.)How much to refactor really depends on your priorities at a given time. I think it must be done once, and once is good enough.

Stay with the standards. Use standard ways of doing things wherever possible - tools, coding conventions, patterns. Remember, innovation comes at the next level - the level of your product. Follow a coding convention in the project. I dont care about line breaks and where you place your curly braces and whether it is iCount or i or count, but I do care about what you name your class, what package structure you use and where you place your resource files. Dont re-invent the wheel. Scout the open source world for solutions to some common problems, implementation of design patterns (warning: check the licensing model of any external software you use before you use it). Its okay to make an exception if you are consciously doing so.

Well, this is it, my torchlight on the path of coding Nirvana. I told you it would be simple. Amen.