One of the common reasons why software bugs are not fixed is:
"The developers often don't have time or it is not economical to fix all non-severe bugs."
Bugs scattered across software systems cause "software entropy" to increase (a term that I coined.) Therefore disorderedness of any isolated software system increases over time, similar to physical systems.
On the other hand what makes a software company survive is selling "orderly behaving" products. But competitive market forces and aggressive Sales pressures may increase organizational tendency not to fix bugs. This behavior in turn may lead to software entropy to increase in an exponential rate.
Therefore the size of the backlog of Support department may start to increase exponentially rather than logarithmically. In those circumstances increase in software entropy may result in "customer dissatisfaction" which may eventually lead to sales to decrease.
Therefore there must be a balancing act between Sales and Support. Development resources must be shared and utilized in a way to keep software entropy increase in a logarithmic but controllable and stable fashion if not decrease.
This is similar to "clean house" analogy. If you don't clean up, air and maintain your house regularly, say once every two weeks, it would become more difficult to keep up with entropy. Dust and mold will cumulate. Certain mechanical devices will rust away, or start to malfunction, more dust-mite colonies will flourish, the air will become stuffy and unhealthy. If you leave your house for 20 years, the chances are you may need to rebuild the interiors, i.e. start from scratch.
Software business is no different, negligence of balancing out software entropy may bring catastrophic consequences. And at some "no return" point the business may fail all together if not acted early enough.
2 comments:
Love the photo of you.
Software Entropy aka "Technical Debt".
See: http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
Thanks for the link MemeMachineMan. This paragraph sums it up well:
"The reason most often cited by technical staff for avoiding debt altogether is the challenge of communicating the existence of technical debt to business staff and the challenge of helping business staff remember the implications of the technical debt that has previously been incurred. Everyone agrees that it's a good idea to incur debt late in a release cycle, but business staff can sometimes resist accounting for the time needed to pay off the debt on the next release cycle. The main issue seems to be that, unlike financial debt, technical debt is much less visible, and so people have an easier time ignoring it."
Post a Comment