Bazooka Developer

It is so told, that there should come a time for every developer, when he be faced with the challenge of coding in the sky. A situation like this happens when a client is faced with a critical problem and needs an immediate solution. The solution provider decides to give it a go, sends out a repair man, for a fast, cowboy style solution, and cashes in the check.

When my turn came, I was handed the assignment along with the flight tickets and a brief rundown of the functionality I had to deliver. The functionality took about an hour for him to describe.

This kind of positive thinking often reminds me of the ‘Bazooka Joe’ bubblegum fortune, telling me that by the age of 21 I would probably land on the moon.

Keeping that same positive thinking in mind, I realized it would be a nice opportunity for setting my agile development skills to the test. I preach agility all the time. I preach it to my colleges and to my developers. I even preach it to my boss. There was no way I was about to turn ‘cowboy’ on all that.

The entire time frame for this task was less than a standard agile heart beat, but I stuck with the principles, and used them to guide me.

My first task was to deliver functionality. So I set to inquire whatever I could about the requirements. There was the way my boss envisioned it and there were some correspondence with the customer that preceded the request. I swept through the mail exchanges, to find out how the customer wanted it to work and how it ought to be fitted in the surrounding landscape of the other systems. I came out with a detailed feature list, reflecting the functionality requirements, an outline sketch of the interfaces and a high level cubistic design with a short list of would be obstacles (i.e. outstanding issues yet to be resolved).

Meeting the bare minimum to enable testability: I wrote a mock up interface invoker (two actually, that know how to talk to each other in a session like manner). Just like in the real world, my module was going to be ‘stuck’ right in between the two mockups, doing so I could have a convenient testing envelope where I can gradually grow my functionality.

I felt I was ready for some hard core coding.

Fortune: you will not get much sleep the next few nights.

I developed in short cycles. I used my short list of suspected pickles to define the steps for development. After coding a new solution that was suppose to address a particular issue, I ran the module against the testing facilities, with all the scenarios I had so far, and a new scenario that would test the solution. This got me through debugging and I made sure that I was not disrupting previously developed features (i.e. regression testing).

I know, I know, I was sprinting or whatever. In any case it kept me focused on my goals and constantly in check with working functionality.

I sprinted at the office, I sprinted at home, I sprinted at night, in the airport and on the airplane.

It so happened that by the time I got to the site, I was far from done, but I did have a prototype that was solid enough and being as it was, I had it installed on one of the development environment there.

I made use of the customer. The customer in this case was a respectable American corporate. I met there with the IT team that held everything together. Right at the beginning, they brought into my attention that they had four sets of environments. This was an important point to note since there were differences in application versions between them. The version differences meant that every time I got environmentally promoted, I had to adjust to the changes in protocol and behavior.

Fortune: an overnight success is the result of years of preparations

At this stage, I could have my testing cycles run up against real applications and not the mockup applications I prepared myself. The people from the IT team helped me learn about the extreme scenarios and together we were able to devise a meticulous testing plan. Together we defined the scope for load testing.

During the working hours, I ran tests on the various environments that were available and spent the nights at the hotel for code fixing and optimization. This was not an easy time for me. By the end of the first week we have conducted a few cycles of testing and amendment, and we were already deep into the load testing.

Fortune: the love you give is equal to the love you get

I was also able to cater for some extra requests for changes. These were minor modifications that had to do with logging and configuration options, but it made customer happy. The help I got from the customer staff I met there was absolutely essential in making the delivery and having the module go into production.

A month after I flew back, my module was set into production. Of course there were some more bugs identified and some new feature requests as well. But all in all, the customer was satisfied.

Fortune: don’t let it go up to your head