Should we expect a software crisis?
I read a blog post titled The Quiet Crisis unfolding in Software Development that mainly says, current software building practices lead to accumulate technical debt and legacy software becomes unmanageable in time.
It warns about highly skilled developers
“These kinds of high performers are actually low performers when when TCO is factored in. Unless you’re a startup where time to market is the highest priority, keep these kinds of developers under close scrutiny with extensive design and code reviews.”
and says continual improvement should be an innate element of all software building practice.
“Continual improvement isn’t a stand alone project. If you make it a stand alone project you’ll eventually find a reason to abandon it entirely because it’s impacting deadlines. It should be something developers are tasked to do all the time during their normal development activities. This is not unlike the power of compound interest.”
For my experience the following holds too
“Some employees aren’t aware of the impact they have on other team members and interrupt them frequently with one quick question or worse. Encourage your team to prefer communication in roughly the following order so that interruptions are minimized: e-mail, chat room (if your team isn’t using a chat room yet, they should be), instant message, phone call/dropping by in person.”
but in general I would not expect a crisis in software development. Software is not like a building or a tool, it’s rather like an orchard you gather value in time. It surely needs maintenance but the cost of maintenance and the value it provides should be thought together.
I believe that most errors are preventable in software development, but (communication/technical/financial) cost of perfect software is usually worth more than the value it provides. It’s true that we should aim particular practices that reduce such cost, like not interrupting team members when they are working but striving for perfect software does not bring it.
What brings it? Receiving and listening to the feedback. Software developer should be open to feedback, be it from the tests they write or users’ bug reports. Our foremost aim should be opening as much as feedback channels, in the form of unit tests, integration tests and shipping results to the users as much as possible. We can only evaluate the technical debt on top of this feedback.