Feeding the Machine Part 2: agile or nimble?

Some people have heard me come down on xp (eXtreme Programming) and assume that I am also anti-agile. At first glance that may be true, but that's just because I'm not a big fan of any method that takes more than one book and 2 seminars to grasp (I already have a degree, unless you plan on giving me a Masters I'm done with the seminars). But overall I'd say I'm a fan of Agile practices. I'm a big fan of doing things the easiest way, even if that means for now it's a pain in the neck but I know that next year I won't have a problem working with it. I believe people should make themselves better, but most of all I wish they'd just do a good job.

I'm not going to sit here and go over the agile manifesto with pros and cons and my 3 cents on them. I will say though that it wouldn't be a bad thing to go over from time to time and see if you can apply to known problem areas you have. But don't let it be your only compass, far be it from any sane, logical person to think that that little list of suggestions is the only resource that can be used to improve your daily work routine.

I'd say that overall I'm a very agile developer, but don't try and weigh me against the text book, it won't add up. I do like test-driven-development and think that all code written for any framework should have a living contract in the form of a unit-test that proves it does what you expected it to do. I even think that if you can you should use test-first development, but I can't presently go into my thoughts on how that isn't always the best thing to do (in other words that's too many words for an aside in this post). I like iterative development; but seriously, it only works if you have iterative testing going on in tandem with integration, otherwise you have an iterative waterfall that may as well have been waterfall but upper-level management prefers the buzz words so iterative development it is (with waterfall testing).

Don't get me wrong, I know I'm relatively young and new to the programming world, but in my brief stint between college and my current job I did some web development with a small company (small being the guy who started the company and me, and .... oh right, that was it). I did several small business web sites/apps that I was lucky enough to have time to start and finish there. They were pretty much all attacked from a waterfall standpoint, but I tried to get iterative use from the clients when I could. One app in particular that was a very prime cut for a young coder such as myself was almost more than I could handle, but one of the best teachers I could have had in my young career. It was a billing application for a ... well, no details please.

Needless to say it was a way for this company to manage clients and to allow their clients to log in and submit their clients for billing. It had a reporting function that printed out these neat little mail outs that I was so proud... right, I said no details. Well, on the technical side it was an ASP (classic, none of that dotnet stuff) app with VBScript talking to a MS SQL Server in the background. Starting the development process we had to right idea: meet with the clients, go over the way their system currently works (all paper and fax machine), get base requirements and client direction, fill them in on what our abilities and vision were and get the thing started.

Well, upon meeting with the clients we found that they had less time and interest in sharing their app features with us than they needed to have. It seemed all they really wanted was for us to write their app and they would use it, end of story. So we mostly had email correspondence and the occasional phone conference, but really these people didn't want to be reached. Why didn't we drop the project at this point? Well, for a 2 man company, 1 guy straight outta college and the other teaching college courses on the side, we couldn't let the project price we had all agreed on slip away (which looking back was way too cheap for what we did, 'doh!).

So what we had was a shabby set of here's what we do and a goal (the good news was no real deadline). So I took off, designed the database wrote screens, tied it all together with VBScript and I was rolling.

We got a working product going, we knew it wasn't finished, but we thought we'd accomplished a ton. Finally setup a meeting with the ever elusive clients and show off their new rig.

They're not pleased. It doesn't do this, and this isn't supposed to work like that, and why can't we see this? Being young and broke and stupid I didn't realize devastating that meeting was. So I went back to the drawing board. Re-worked the database to make all the relational data more relational and tore my app to pieces and used what was left to code what our latest meeting went over.

Again, working product. Present to clients. Go over why it's not what they wanted.

You see the pattern. It was a waterfall going dry and if I hadn't been so young in the business I would've talked the partner into giving them what we had and taking what little money we could and shake the dust off. But I worked it until it was finished and acceptable. But really, should it be that hard? No. Although, I think that with those clients I could have tried to enforce more methodologiesand tighter contracts but I don't think we would've landed the contract either. So we did what we had to.

Looking back on that I do have to say that I love a handful of agile practices and think that we could all use a refresher on how to make ourselves better programmers. But we can't forget that at the end of the day it isn't about how well we followed the process, but "how well did we write the program?".

Until next time,
Les