Ah yes, the famous Fred Brooks quote. How does a software project get to be one year late? You guessed it, one day at a time. The project that I had embarked on at my company for the past 14 months was supposed to have taken 5. Imagine that, it was 9 months over the deadline, which is 180% late. When factoring in the fact that we had about 1/4 of the features, it actually was closer to 700% late. How could this have happened? Were we all sleeping? These are hard questions to answer, but I know that given a choice, we would not repeat this again. If we learn from our mistakes then we might have a fighting chance on preventing this from happening again. To start, how did this all happen?

It all happened so quickly (lol), I didn’t know what hit me until it did. It was a combination of many things that led to this huge delay,
- Project scope was constantly changing.
- Overly optimistic estimation of completion time.
- Inexperienced team.
- No code reviews.
- No set priorities.

We could have easily mitigated most of these by identifying problems earlier on and dealt with them as needed. Of course, hindsight is always 20/20, but our foresight, blind as a bat.

The elusive scope
I’ve read about this topic in papers and even heard it on various audio and podcasts. I even took a class on project management and we had a section on project scope, but none of it translated to reality for me and I had to find out the hard way. I didn’t know what a scope creep looked like until it snuck up and smacked me upside the head. Inexperience was one of the largest culprits for our downfall. Why was the scope creep in this project so elusive? The lack of a clear requirement specification.

We did not have much in terms of documentation but a simple PowerPoint slideshow. It was a very basic, naive specification that had a lot of missing requirements. To make up for it, the management pushed the responsibilities onto the developers. The developers were to apply “common sense” liberally. Yes, you heard it right, common sense (funny, my blog name). A word of caution, if you hear your manager state that the team/group/company doesn’t have enough common sense, take extra precautions and document everything you do in case you need it. Eventually, the word was thrown around so much where, to me, it felt that we should have gotten a degree “telepathy” instead. How can you quantify common sense? One person’s common sense does not necessarily apply to another person. If you decide/have to rely on common sense to produce a piece of software, I really pity you.

Don’t get me wrong, writing software requires a lot of common sense, but should never rely on it. You should rely on specific documentations, clear objectives, and frequent verifications/validations of the software. If the validation process seems to fail at a high rate, like it did in our scenario, then your requirement specification is weak and poorly developed. Each time we had accomplished some milestone, we checked back with our “customer,” who happens to be the boss, there was always something missing. Sure, some of it were the developers’ fault, but more often than not, it was the lack of specification requirements. In management’s words, “we did not apply enough common sense to fill in the missing pieces.”

We had specifications, but we didn’t have enough. We should have been spent more time on the planning stage. More discussions and debates regarding the product features and its priorities. Parallel with this planning stage should be prototyping of the new system’s infrastructure and implementation details such as file organization, data modeling, interfaces, etc. Since we were a new team, this would have been a good time to also sketch out basic coding standards to adhere to. A structured approach would have given us some foundation to give a strong start.

Sadly, we did not take this route. Our team dove right into the feature list without the slightest thought of refactoring anything. We had limited time and a huge, unprioritized todo list. The boss wanted to see results, and our direct manager pushed us to get features done. Right from the start, we were in a rat race. Naive were we, we happily chipped away at that insurmountable list. We were able to get some of the bigger features done and thought we were making headway. Each time, we pat ourselves on the back for the accomplishment. Without any milestone party, discussion, or thorough testing, we jumped right back on the treadmill, going full speed ahead onto that next feature.

Four months in and we weren’t even close to the halfway mark. Bugs started popping up left and right, but it seemed like we had more than our fair share of bugs. Bugs that I swore I had fixed kept on coming back. Something did not feel quite right, did we have zombie bugs? Unsquishable, unstoppable, undead bugs? So I put on my dumpster diving suit, closed my eyes, plugged my nose, and jumped into our code base. My heart sank, or to use my dumpster diving metaphor, I had major gag reflex. Copied and pasted code were everywhere, blocks of nearly 200 lines of code were identical. It was at this very moment that I felt I was entering a world of hurt.

To be continued…

late software · late software project · prevent late software projects · preventing late projects · requirement specification · software documentation