Practical Programming (part 3)

First there was the traditional model of software development. Then there’s agile software development. And both models fail miserably for me, and I’ll tell you why.

I work in a fluid environment. It means I drift from one team to another based on need. I’m now the “user interface guy”. Anything that has to do with web applications, Windows applications, screen messages/errors, they look for me. I’m also the only programmer doing interface work, which brings me to…

Why the traditional development model fails

As I’ve said before, the traditional model takes too long. My users want a feature or a small complete program ready to launch in a few days, inclusive of whatever testing required. There was this one time where I was expected to come up with a complete web application in one month, with all the backend supporting processes running as well. That was in a December holiday season. They had a big paying customer. The project must launch. I was seriously stressed out then…

My users also don’t usually have concrete interface requirements. They have concrete business requirements, but as far as the user interface is concerned, they’re pretty casual. Documentation is focussed on business logic. Interface screen design is sketchy at best when it is time to sign off on the requirements. This means I have to come up with a good and usable design. Then the screen design is recorded into the sign off document post-development, as a formality.

Why the agile software development model fails

My users don’t want to be intimately involved in testing. They’ll tell me what’s right and what’s wrong after the project was launched and they’ve used it. My testers don’t want to do iterative testing. They have a very specific testing period, and they’ll only do testing after I’m completely done with development. There goes frequent iterative test cycles…

Due to limited resources (I’m the only programmer, remember?), any major changes introduced late in testing severely affects development. There’s this recent incident where my development work was completed, and I went on to work on another team’s development work. Everything seemed fine, until a day before the project was to be launched, the tester sent me a bunch of interface enhancements.

The enhancements required more than just a change in error messages. These enhancements required me to change business code classes, write a new stored procedure and add more stuff on the web forms. In a day? And I have to test it myself first, and I’m involved with another team’s development work.

The current system simply cannot handle sudden additional requirements like this.

The lone wolf development model

No, it has nothing to do with the canine. It refers to the fact that you’re the only one doing everything. Ok, so you may not be the only one. You can still be handling a lot of responsibilities.

What do you do then? Think and design very carefully. The motto is “Do it once, do it right“, because you might not have time to go back and correct the code. Code resiliency is important; Your code must be fairly change-resistant.

I typically use a day or two studying requirements. I pick out relations and dependencies in database tables and the desired screen interfaces. Once I’ve isolated independent screens, I draw out the desired screen layout on paper. I design supporting business class, and consider if there’s any special code I need to make the screen interface work. Only then do I start coding.

This has saved me lots of time, because the code I write is capable of handling minor changes efficiently, and can easily be expanded on for medium-scale changes. The code also becomes the basis of a reusable framework. I wrote simple tools that help generate code for my data classes, which become part of that framework.

All this made it easy for me to come up with a completely brand new web application from scratch. Well, not really from scratch. The code is newly written, but the base idea and structure was already well thought out.

Being a lone wolf programmer and still churn out working code in a practical time frame isn’t easy. But it can be done. You just have to think harder.

Comments are closed.