“I Just Have To…” Project Management

“I Just Have To…” Project Management
By survivalofthecraziest

If you’ve worked in/with a software development team, in any capacity, you have heard this optimistic statement before: “I just have to and then I’m done!”

• “The new approach worked. I tested it. I just have to move this method to the other class, and then I’m done!”

• “I’ve committed my changes in a branch. I just have to re-run the tests once more, and then I’m done!”

• “I’ve finished everything. I’m ready to start the next task. I just have to update the README and then I’m done!”

Well, you know what they say: in any software project, 90% of the work is completed in the first half of the schedule. To complete the rest 10%, it requires the rest half of the schedule, plus another 50% schedule overrun, plus x extra resources, everyone working overtime and oh yeah, we’ll ship the documentation later because we were focusing on delivering the functionality… you get the point.

You know Brook’s Law? It applies to machines as well. When you write tools and post-build scripts to automate development tasks, when you adopt the latest DVCS, when you start using the latest test automation framework… you are adding resources to your project. And it has been clearly established that adding resources to a project that is already behind schedule (and which project isn’t) is only going to make it later.

Here are a few things I’ve learned over the years:

• Nothing on planet Earth is a zero-time activity. Your plan: “I just have to move this method to the other class, and then I’m done!”. What happens in real life:
  • You need to get your code peer reviewed.
  • But there is nobody available at the moment to review.
  • You finally interrupt someone, because y’know, it’s just one method, you just have to quickly review it… (of course you would conveniently forget how you would feel if you were the one being interrupted)
  • What? It’s a public API? Then you have to update the acceptance tests.
  • And the unit tests.
  • Go back for peer review and sign off. After lunch.
  • OK, all done, just commit and… What now I need to merge?!
  • And rebuild.
  • And re-run the tests.
  • And re-start the PC because of that pesky Visual Studio bug.
  • What? Windows updates? Now?!

• Murphy’s Law is as fundamental to computer science as Boolean algebra. It’s a pity they don’t teach it in school.

• Remember algorithmic analysis? When you estimate something, don’t always consider the best case. The worst case happens more often than you’d think.

• ABC: Always Be Collecting. Data. Statistics. Your past project data will show unrealistic your estimates really are. Nothing else can convince you as much.

• If you haven’t been able to solve a problem for too long (confused customer, unreliable dev environment, too many distractions or interruptions), then maybe it’s not a problem, it’s a fact. So adjust your future estimates accordingly.

• Say “out of scope” more often. Just because it’s software and easy to modify, doesn’t mean it should be modified. Agile doesn’t mean the freedom to constantly change requirements, it means adapting to changing requirements (amongst other things). Changing requirements doesn’t mean freedom to change fundamental constraints. Think of it this way: if you were building a bridge, it would be acceptable to try out different road surfaces. But would you change the bridge into a tunnel because it offers less wind resistance? And should there be a need in the future, you can just drop the already built tunnel underwater? Some software change requests and developer’s grand visions are equally unrealistic, and unnecessary.

• Life is a fractal. If you’re late every day, you will be late every month, every year… and you will feel the same way about your whole life. It happens at home too: “I just have to get dressed, and I’m ready to leave”. Real life: Get dressed, grab snack, drink water, close window, remove phone from charging, respond to missed call, tie shoelaces, oops mismatched socks, find keys, lock door, wait for stuck elevator…

• Work-life balance doesn’t mean work-life separation. Bring your good habits to work. Inculcate learnings from your work into your personal life. Why limit Continuous Improvement only 8 hours in a day?

• Learn from others’ mistakes. Every time someone is being a moron, they are secretly trying to teach you something. The daily standup is not only about you, it’s also an opportunity to improve based on others’ experience.

• Most importantly: Stop saying “I just have to…”

You can read more from the author (who’s half-anonymous) on this blog. You can also follow the author via Twitter.