The Getting Things Done Trap

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.

  1. 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?
  2. It needs to be maintained, adapting to changes in the business requirements over time
  3. 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:

  1. 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.
  2. If developers are not asking about or clarifying the ambiguous multiplicity of business entity relationships before coding… You need to stop and plan.
  3. 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.
  4. 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

 

Advertisements

Why are Small Development Teams so much more Productive?

For anyone that has read “The Mythical Man Month” this should really come as no surprise but there is a very simple way to see and understand why the larger the team you have – the slower you’ll actually develop.

Its all about communication.  In an ideal world every member of the team will share everything they are doing with the rest of the team and each of them will share their updates with everyone else.  In this scenario everyone would know what is going on and there wouldn’t be mistakes or duplication due to lack of communication.

In fact when you develop by yourself (team of 1) there’s not even the possibility of communication issues because you have no one that you need to share info with… and no one you depend on for critical data.

If your team is 2, you have 2 channels of communication to maintain… A to B… and B to A

Team of 3? now you’re up to 6 channels… and it keeps growing exponentially.

Even with a team of 10 people your communication channels jumps up to a massive 90 communication channels! # of channels = (n * (n-1))

peopleVsChannels

So whenever you are embarking on a new project try to keep the team size as small as you can while still enough to be effective.  If your team is part of a bigger organization be sure to have a “Point Person” that is the one who interfaces with other teams to both broadcast updates and collect any info from external sources that is to be passed to the team.

Managing Communication is key to not getting caught in a project that just seems to stall and run in circles.