Rampant CodeCraft

My company produces software that doesn't break. Our entire reputation is based on that. But behind that software is code that even the original authors have real trouble modifying. Why is that? All software produced everywhere is assigned a version number. Wikipedia has 4000 words on the subject of Software Versioning. Versioning is inherent to software. We know that software will be updated, modified, changed. So this begs the question: If we know that software will need to be modified, then why have we been setting ourselves up to fail by not writing code that can be modified? We've relied on something characteristic of software production for small business: there is no version 2. Problem now is, this is no longer our niche in the market. We have grown and produce software for large corporations now.

We are in the early stages of an event here. Parts of this are changes in the fundamental way my company authors code. Gone are the days of "Git-er-Done however you need cuz the client can't afford a version 2". Now is the time of "Why did this maintenance modification cost more than the original construction?". I could go on, but I mention this only to frame a point. Our move to code creation that is able to afford change is not this singularly great idea for a problem that exists in the development phase. The new concepts and skills can be applied to everything we do here.

In the development phase we produce what the client requests: software that gets a job done and doesn't break. For the past however long, that is all that was required. Our search for efficiency, combined with a track record of software not needing an update because it doesn't break and clients not requesting a second version has resulted in us gaining efficiency by cutting out all real considerations for future extension or modification. Our ability to do this well has resulted in larger clients with larger needs. And now when their large software solutions need an update; when version 2 is requested, we find ourselves in real trouble. This situation not only exists in our development phases of projects. It also exists in the requirements and specification phases.

In the design phase we produce what the client requests: a document that defines the intent, appearance and functionality of the software to be produced. But after development based on that document is over; when the client requests a version 2 and we need to refer back to the document to understand version 1, we find ourselves in real trouble. Why? Because we don't document the changes made to the product during development. We can't keep up, and we have never had a real need to, so we don't. Our specification documents have just enough detail to satisfy the client. The document leaves so much of the technical detail up to the developer coding, that within a matter of weeks what is delivered to QA has diverged from the specification so far that the document is useless and the QA assigned needs the new specification communicated to them directly from the developer before they can begin testing.

What is needed is method of documenting requirements that can be so easily modified that the developers actually do update the documentation as the application is refined, or requirements change or the application design diverges from the original for any reason.