The Cost Of Inefficiency

Costs of Inefficiency are evident in the world of business and also in the world of SoftwareDevelopment. The cost is sometimes failure or cancellation of projects and products.

Question: What are the inefficiencies present in the SoftwareDevelopment community and what can be done to minimize the impact of inefficiencies?

Discussion:

''Is TheCostOfInefficiency evident?

"I don't think most people have a clue as to areas of inefficiency, much less their costs. Discovering inefficiency requires a dedicated effort to search for it and identify it.''

The costs exist, whether people have a clue or not.

What costs are involved?

Costs are real and opportunity. The real costs are monetary and must be applied to some enterprise.

The opportunity costs are realized in failure to generate income and profits.

Inefficiency is generally the application of, or the failure of application of, methods, procedures, practices and allocation of resources in an approach designed for success.

That seems wrong. An inefficient approach can be designed for success (and even be successful).

I'll propose: Inefficiency is the difference in aggregate resource costs between an optimal solution and an actual solution. And a resource cost is anything required (constraining) and of limited availability.

Where I get confused is when dealing with dozens of different resources... it is often difficult to even decide what an 'optimal solution' looks like with regards to costs. It's always good to have the lowest cost possible, but the lowest possible cost is non-zero for a required resource, and often one resource can be traded for another. How shall one resource (time or man-hours, energy cost, heat production, power consumption, money, pollution or waste production, etc.) be valued against another?

Inefficiencies I have seen in large projects:

Duplication of work
Incompatible interfaces between components, subsystems and teams
No integration plan
No completion criteria for technical teams
An AddictionToComplexity? - looking smart valued over simple solutions
Lack of honest communication (e.g. head nodding when managers ask about status)
No measures of efficiency

What can be done?

Create collectively a clear vision understood by all
More time spent on the contracting phase of component design
Highlight risks early
Integrate early and often
Reward simplicity
Invest in metrics

Inefficiencies of separation

The biggest inefficiency is treating "requirements," "design," "development," and "test" as separate phases. In this approach, there is nothing to measure for efficiency and no known status. You only know where you are when you are done.

Evolutionary Approach

The alternative to the waterfall model is the iterative, evolutionary approach. With this approach you do not need:

a clear vision understood by all - the software will merely get better as work goes on
to spend time on "phases" - do one thing in its entirety at a time.
highlight risks early - you will hit them head long early
reward simplicity - when you focus on completing a single task, simplicity is a result
invest in metrics - tracking becomes trivially simple, how much is working?

The evolutionary approach provides these things, it is not saying they are not needed. This is a great approach, I have not enjoyed enough time in this kind of environment.

I have succeeded with this approach in small projects where all developers see all of the code. I am currently attempting to consolidate various distributed systems in an very large organization (>75,000)- yes I am a little crazy. The architecture is moving towards J2EE standards. Different skills are required, multiple tools, different technologies used (JSPs, Java Beans, EJBs, Legacy connectivity, MQ, XML, LDAP, JNDI, DB2, and more...). I believe there is a minimal vision required (not a 3 year strategic plan!!) but at least some direction and understanding of how teams and technologies collaborate. I have seen great inefficiencies when developers just begin coding.

p.s. I prefer the term OrganicVsEvolutionary as it implies it we are not always in control of unfolding circumstances.

CategoryPerformance