When I started my career back in 1994, I was trained to become a classic “waterfall programmer”, we were taught to read (and not participate in) requirement specification, then read (again not participate in) system design and after spending couple of weeks each on these activities and when the requirements were frozen, we start coding for the module that we were assigned. We worked separately until end of the coding phase and then we integrated the modules and boom!! … everything fell apart and we were flooded with defects and we ran around fixing them and more time than ever, this would lead to even more defects. Late nights and extra hours and working weekends until the quality stabilized (from developer point of view that is). The the UAT started and boom!!!… Users started logging defects to which our project leads and managers debated for days all together to prove them as change requests for new feature as it was not described in the requirement specs. These guys are the top did some compromises and agreements and next round of coding started and above all steps started yet again only to this time bring delivered software closer to what client requested. This is how I worked on three projects in two years. And then something changed…
I joined a new company (a big investment bank) in New York and I happened to be assigned a project where our lead did things in a different manner. He used to be the favorite of the bankers those wanted to get their system delivered fast and as per their changing requirements. I didn’t know that my life and how perceived programming was going to change forever while working there. First thing I noticed that we did not get any requirement documents, all we used to get a one pager or a card or even a paper napkin with requirements written in a very concise manner. I felt very odd as I was used to reading requirement specs for weeks before I actually started to code. Anyways I started to code for the brief one pager requirement and tested it as per my comfort, now the next shocker was that it was suppose to be described to my peer programmer and he did the same with his code and we tested each others code. The next biggest shocker was that we were suppose to show it to the client in the evening itself and based upon the feedback we got we were suppose to proceed ahead.
This was the typical day for all of us programmers and it was very very different from how others in the bank or for that matter in the industry, worked on software development. We integrated code every few days, gathered as a team to discuss the progress and tested the software based upon the notes that we had made while having the client meetings. It was mandatory for all of us to document these meetings as it was the basis on which we developed and tested our software, rest of usual software documentation was optional and left us to decide. Overall our team lead was invisible most of the time and work with each one of us to offer tips or help us resolve issues and manage the daily client meetings. For first few days it was very uncomfortable for me as if felt like we worked at a breakneck speed or at least it seems to me like that compared to my days as the “Waterfall programmer”. I also felt that I was so unlucky when I saw my other friends relaxing while they were in the requirement phase, design phase or coding phase while the delivery date was far away in future and here I was working everyday as if it was a delivery everyday!! (getting requirements on paper napkin was the peak of my amazement in the first week). But I got used to it and not only that started to like it and then subsequently love it the way we worked. I loved the fact that we always delighted our bankers with our flexible software approach and work was always of high quality as we tested for what was important for the client (it always helped that as a reward the big bankers always took us out for a night out partying the successful releases, and they were very frequent and we didn’t mind that).
Due to our unorthodox way of working, we were called “The Rogue Programmers” and I was proud to be one them and never realized that it was my introduction to Agile software development and funny thing is that I didn’t realize it while we were doing it, there was not hype around it, we just wanted to do give our best to deliver software that was useful to our client and in fastest possible way. I was on my journey to Agile development and was spoiled so bad that I was not capable of working in so-called-normal waterfall delivery anymore… it has been 19 years and it is still is a handicap.