Why is successful software development so difficult to repeat?

Why is successful software development so difficult to repeat time and again like a factory?

Well it’s about people.  I think that sums it up. (Though it sounds rather crass as I read it.)

I want to discuss two issues.  First, I think many people ignore the fact that software development is actually about creating not manufacturing the same thing every time. Second, communication between even well intentioned people working together every day is fraught with noise and incoherence.  How can you build software if everyone involved is unable to communicate clearly?

I propose that we need to actively work against the assumptions that so much raw material that enters the software factory creates X amount of value because it creates a measurement biased approach focused on utilization as opposed to value delivered.  Software development management cannot be a game of Tetris-like management of hours by role as the project plan for perfect utilization. There are many efficiently developed software systems that have been developed that have not delivered anywhere near their potential business value.

Our ability to pay attention, to listen and then to understand complex concepts is difficult in the most simple settings.  In a more freeform arena such as custom (think green field) software development it is extremely difficult. This is played out daily all over the world as software projects fail, get delayed and miss on expectations of their sponsors. But it doesn’t have to be this way, we simply choose to ignore that development relies on an unreliable factor, human communication.

So what to do?  Create a new certification program?  Derive a new process? Self-improvement guru’s and methodology coaches have similar business plans.  Hey, sometimes it works.  I don’t like gambling on sometimes.

Eliminating the manufacturing/measurement mentality…

We need to change what we measure for success.  We need to suspend the efficiency experts for a moment and look at how to create real value.  There are not many CEO’s or investor’s that I have met who would complain about making a $2 million dollar software project investment to get $50 million in year over year annual revenue return.  (I know there are other costs for continuing operations, but that can be factored in and we can get logarithmic or even exponential scaling if we can design operations appropriately when we build the software.)

By focusing on value we also are better able to make value focused as opposed to process focused decisions. In the above example if we really needed one more QA for a few weeks, can we just pay for it and launch the project rather than argue about estimation methods and 14 step approval chains?  Go get that revenue!

Remembering people are imperfect communicators…

Project teams (everyone involved not just IT pros) can work to make the objectives easy to understand and model.  This involves breaking down artificial organizational barriers, barriers of understanding and closely held assumptions. Not just technical aptitude.  Yes, it involves more than normal commitment.

This is a prime principle of many newer software methodologies.  But it only works if we make the investment to reap the value.  We can achieve more coherent communication by developing common language to define our problem and create the necessary agreed upon concepts for negotiating and managing when we build the software together.

A collaborative creation process can’t work with a drop in interview or a conversation once a week.  It also can’t be done with lots of lingo that creates assumptions. So whether facilitated time together to let ideas grow and develop or a dedicated person who is a product owner embedded in a team every day, creating common experience around the language and concepts is critical to overcoming communication entropy which only increases over time.

Put it together…

The highly efficient manufacturing model actually dissuades dedicating the right time needed to capture the value we can create. If we suspend the manufacturing/efficiency model, we can actually evaluate and justify the right commitment of resources for a project/program/effort.  Applying solid best practices to reinforce coherent communication and clarity will allow for smaller teams to be more productive, more efficient and reactive to change.  Which is a real offset to the arguments in favor of the manufacturing/efficiency model.

And hey, it’s OK if something cool can’t be justified.  Probably needs to be tuned up or trashed. Better early, than investing poorly with incoherent communication for a bad result.

Wrap it up…

Does your company understand it is creating value with software or is it confused by the manufacturing model focused on efficiency?  Can your organization communicate effectively over time and actually increase the value expected and delivered with software? Write back and let me know or ask for help.

Gary

P.S. I am a voracious self-improvement reader.  Love it.  Sometimes it even works for me.  I keep trying.

Leave a Reply

Your email address will not be published. Required fields are marked *