Disagree to Disagree

90% of the time when two people disagree about a solution, they really disagree about the problem.

Usually Person A’s solution is the best for the problem that Person A sees.

And usually Person B’s solution is the best for the problem that Person B sees.

But since they go back and forth about who’s solution is best, they never realize that they are talking about two different problems.

If they would just step back and discuss the problem, they will resolve their disagreement so much sooner. But alas, defining the problem is boring analysis and who wants to do that?

Giant Sucking Noise

Has this every happened at your company?

A problem is identified. The person doing the analysis only does a little before announcing their wonderful solution.

It seems problem solving is fun and creative. The person coming up with the solution feels so clever.

However, when full analysis is not done, it leaves a vacuum. And that giant sucking noise we hear is that solution based on half-assed analysis. It sucks because it does not fully solve anything.

But problem solving is funner when the analysis is incomplete – actual constraints and issues puts boundaries on the clever solutions. And analysis is so much work – not nearly as fun a being a clever problem solver.

A complete analysis usually practically points directly to a solution. The issue is vivid, the need real. But when we are led to the answer, where is the satisfaction of clever problem solving?

It is overwhelmed with the satisfaction of a good solution.

DevDelivery’s Second Rule of Development Process

Any process where key steps depend on humans executing perfectly is guaranteed to fail.

Humans make mistakes – it is what makes them human. Anything that has to be done right should be either

  • Automated
  • Reviewed
  • Structured so that mistakes are obvious and quickly found

If one of these are not built into your process, don’t blame the person who made the mistake that caused the deployment to fail – blame your process that did not catch/prevent that mistake.

DevDelivery’s First Rule of Development Process

Any process that depends on psychic mind reading for communication is guaranteed to fail.

Not may fail – will fail.

This may seem obvious, but communication has to be built into the process and not depend on it happening accidently. I’m constantly amazed how many decisions are made in hallways or actual meetings but never relayed to anyone not present at the time.

Project management is about three things – communication, communication, and communication.

Hello world!

Welcome to my blog. I had thought that blogs were ramblings from egoists, but then I started following a few and found that they could be well done and informative.

Still, I did not really think of doing one of my own. Certainly in the whole internet, someone else has already said whatever I would say, and their version would undoubtedly be better.

But I’ve started to repeat a few rants of lessons learned in my years in software development so am starting to think that maybe you would find some useful tidbits in these rants. Or, at least, we could commiserate.

I’m calling this blog DevDelivery because my concentration is on the actual delivery of useful software development. This being the first name I thought of, I was very surprised that it was not already registered.