Fast forward to my current job. I can assure you that there are a plethora of examples that I could choose from for the point I will be making here, but one strikes me as perfect. You see when we developers started there things were volatile, unstructured, and pretty much a mess. My now fellow programmers and myself were hired in the wake of a collection of other developers leaving for one reason or another. We were also thrust into a project pretty much from the moment we sat in our chairs.

This was all fine and good, and we build what we thought we were supposed to build. Three days before we showed it to the client, we went through a run-through with the manager, only to find out that what we built was not what the client wanted. Well okay parts of it were, but for the most part it was off the mark. The result was months of us working grueling hours of overtime, wherein time became an abstract concept and my world knew nothing but code.

What the hell happened?

We didn’t have a process.

We built what we were told to build at the start, but things changed. The functional spec. was updated and we were never told. On the flip side, we also never went looking. Communication was sub-par at best, and the short of it is that there was enough blame for everyone.

We thought we had a process, but the debacle that we ran headlong into demonstrated that whatever process was in place either wasn’t working or was never initiated. The result was everything blowing up in our face. As it turns out, if you do not learn from this mistake, it will happen again and again. I could pull from more examples, but I’ll refrain… sort of.

I am on a new project, in fact I am the lead developer of said project. It’s my first time doing this and I’ll admit that it is a daunting task, but I set about doing my best. I was given a functional specification, which I thought odd because I’m pretty sure I’m the one that’s supposed to build that. I was told to add my section to it and that was that. I did so, to the best of my ability, with the information I had available to me.

It was okayed, and I started handing out tasks and the development cycle began.

Then I was told that the way things were supposed to work wouldn’t work that way anymore. This was after we had built stuff. This is generally a bad design move, because now any development that was already done now has to be reviewed and possibly scrapped. I updated the spec. again, and away we went. Then I realized that something wasn’t covered with the information I was given, so I asked a question. One question, I swear to God I only asked one but what was the end result? Another overhaul. Another attempt at the functional spec.

This has happened a couple times, and is not how the process should work. In a perfect world, the functional spec. is completely done before a line of code is written. The world is not perfect of course, and we have to make do with what we got, but damnit, I wasn’t about to go and take another stab at anything only to have it change on me again. So I went back to my college roots, and I made a decision:

I will make the process work again.

How can I do that though, when everything has apparently been thrown to the wind? It’s easier than I thought… well sort of. It still requires effort, but I’d rather expend the effort where I did fixing the process then rebuilding anything three times.

I sat down with my other main developer, and we went through everything. We went through every aspect of the functional spec, screen designs, and data sources, and figured out how it all works. We asked all the ‘hows’ and ‘what ifs’ as well as all of the ‘what the hells’ that subsequently came up. We went through every resource, created or not, and decided what was needed, what information had to be stored, etc.. We created use cases for the complex cases, and walked through more processes then I would care to count.

The end result? I spent ten hours (minimum) in a board room with a print-enabled white board and wrote everything down. I’m pretty sure we have at least 15 printouts of notes and questions and diagrams and use cases which helped clear up the utter ambiguity that surrounded the project. They get it now, and so do I. It’s no longer a matter of “how does this work?” but a matter of “what’s the next task?” Yes I have to update the functional spec. again, but at least now I know what to add, and where. The document is finally useful, and the project is understood. The process exists once again.

I’ve also taken it upon myself to write all of those tasks down in a shared location, so that whoever is on the project can take on new tasks as the run out of their assigned ones. That way no one has the excuse for not knowing what is next.

So yes we lost a day of development, but we have saved ourselves days of effort of unneeded rebuild time. Do it right the first time, and you’ll save time later.

On a side note, Sorry Mr. Miller turns out you were write all along about Analysis. My Bad.