In the world of software development there is an interesting bi-polar fascination with the “GTD” (Getting Things Done) mantra.
On the outside, GTD seems awesome and exactly what you want to strive for and a quality you want to look for in a team member.
However there is a dark side to GTD and that’s going to be the subject of this post.
There’s a classic quote I first heard from my grade 8 math teacher.
“No one ever plans to fail, they fail to plan.”
This statement is so simple yet so prolific. It is entirely accurate 99% of the time.
Let’s break down the things that can go wrong and cause a project to fail.
1.) There isn’t enough time to complete the project (even if you were Superman)
2.) The requirements are never solidified until a point at which #1 kicks in
3.) A technical challenge crops up that can’t be solved within time/budget (you find out you need to support infrared communication on a mobile device that has no IR sensors) and #1 kicks in
4.) Pure incompetence by 1 or more of your team members
5.) An external event beyond your companies control de-rails the project (e.g. A flood wipes out your building and electrical for 6 weeks and #1 kicks in
Everything except for #5 is something that could have been resolved if it was discovered and raised in time.
This is where the quote comes into play. If you plan out all the important aspects of your project, and maintain up to date digital documentation that everyone on the team can reference, then you almost completely remove the risk that the project goes south.
With software, there’s 100’s of moving parts that need to work together and not getting the right design from the get go can cause significant pain, cost and stress… In the worst case cause the code to be throwaway and require starting from scratch.
Of course “building” the software project is really only phase 1. Once built it takes on a new life and has a new set of requirements.
- It needs to perform well once released to the masses
- Are the SQL/NoSQL queries as optimized as they can be? Are new DB indexes needed, or further DB normalization?
- Are the loading/rendering response times as fast as they can be?
- Are there any wasted code paths that are chewing up CPU, Network, Memory, or bloating data payloads etc. that should be cleaned up?
- It needs to be maintained, adapting to changes in the business requirements over time
- It needs to be flexible (code design wise) to handle tweaks and changes as part of #1 and #2 above
So what’s the moral of the story? Well in short, I’m fully behind the GTD mantra when it pertains to getting focused on solving a problem and working fast & hard on a solution. However it is really key not to get caught up in the excitement and “just start coding” without working out the key requirements and implementation details.
If you or your teammates are diving in without *really* knowing what you are building, there’s a very high risk that it won’t be the right thing. You’ll either have to throw that work/effort away, or you’ll end up with a poor and/or cumbersome solution because you went too far down the wrong path and didn’t have enough time (or courage to admit defeat) and go back and start over.
This is where the GTD mantra can get you in trouble… and let’s call a spade a spade… Where the Agile “build, fail fast, iterate” can get you begging for mercy too.
So how do you detect when your project’s planning is being skipped? Here’s the telltale signs:
- If developers are anxious to build “part a” and worry about “part b” later… But there are aspects of “part b” that affect how “part a” should be designed or work… You need to stop and plan.
- If developers are not asking about or clarifying the ambiguous multiplicity of business entity relationships before coding… You need to stop and plan.
- If anywhere along the development process a developer says they can’t do “X” because the just built model/data structure doesn’t support it… You need to stop and plan.
- If the UI (User Interface) can not do what it needs to do because it is missing key information… You need to stop and plan.
I’ve seen developers that have worked on small projects plow ahead and duct tape their way through an implementation but in the real world of business / enterprise software development these are the things that kill progress and create fragile software if not caught early.
An hour of planning now can save you weeks or months down the road if you have to go back and re-engineer something that you built wrong because the plan wasn’t there or complete.
(Plan, Build, Test), Iterate