Tight Deadlines and Change: A Developers Perspective

Posted on November 12, 2011 by Alfredo Scaini

I recently worked on a project where the layout, content and apparently the scope of the application were not finalized and kept on changing until an hour after launch. Needless to say, the project – while being launched on time – was one of the most stressful experiences I have had; not so much in terms of developing the application – that was easy – more so in terms of the change requests, bugs and constant emails that never seemed to end.

Yes, a rookie mistake on my part to be involved in something like this.

Getting Your Ducks in a Row

Projects with tight deadlines, no matter how small, need to be fully planned out with all the pieces known before development work begins. If not, you run the risk of misinterpretations of requirements by stakeholders; missing requirements because they weren’t documented; and, implementing immediate changes that create bugs in other parts of the system.

To avoid this it’s important that the major parts of the system are defined and signed off on; including application functionality, user interaction design and the visual design. If you are going to use an agile approach, then at least make sure that each iteration has the previously mentioned items set in stone or an iteration will drag on and you will miss delivering on the entire project.

Putting Things into Perspective

On top of fixing bugs found in the first build, changes pour in while you, as a developer, are still focused on first build bugs. With a tight deadline, even small text corrections are deemed by stakeholders as high priority that must be fixed immediately – bunched in at the same priority level as a bug that causes the system to crash …. not good.

While I understand the importance of having correct textual information before launch, things have to be put into perspective and stakeholders have to be educated on the importance of categorizing and differentiating issues between aesthetic and functional.

Looking back on this project, I know realize that my stress level would have been considerably lowered if changes were categorized as described, as well as bunched together in phases. For example, if there are 10 content changes that need to be made throughout the application, it would have been beneficial to have grouped these together and set it as an aesthetic change (or if you like, a “content change”). Grouping them into the same high priority category as a bug that crashes the application just adds pressure on a developer and will lead to burn out.

Lessons Learned

By creating the overall narrative of the application (scope and modules) and then at each module, defining the details and how the module will work, look and flow, a lot of changes can be implemented before actual development work begins. This doesn’t mean that you need to plan out whether a property is protected or public, that’s a bit too intense; but, you do have to have everything that needs to be built, how it will work and how it will look defined.

With this recent project I did not do these things; and, while I can come up with a bunch of real excuses as to why I didn’t (design mockups were delayed, workflows changed which caused functionality to change, tight deadlines for this one meant we had to skip steps, etc), the bottom line is that I messed up by starting before I made sure everything was in place.

This project launched successfully because of the inner strength, patience and the competent ability of the people involved, not because of the process that was used. If lesser able people would have been involved in this project it would have surely failed.