Re: Good programming practices and changes in requirements: how to maintain good code

[sundialsvc4]

In my experience, it is a business-process issue, and this is the biggest point that I stress in consulting/turnaround engagements.   The project faltered, not because the programmers were incompetent nor because the requirement was impossible, but because of unstructured and undisciplined business process.   Many people presume that software, because it “merely” consists of source-code files, is easy to change.   Not so.   Computer software is actually a frighteningly-complex machine that operates autonomously, and whose thousands of parts are all tightly coupled.   Any change could break the whole ... and you are extremely fortunate if you realize that this has occurred.

This means that the business process of managing the software ... of any changes to it or to its requirements ... must be formalized, and that formality must be adhered-to.   You can’t simply get a cool idea in your head, walk into the “dungeon,” and order your programmers to stop whatever they’re doing and do it.   The programmers, in their turn, can’t simply “make it all up as they go.”   Change, itself, is seen to be business-risky no matter how large or how small it appears to be.

Many companies now have a “change approval board,” or CAB, such that nothing may be done to any system (whether in production or in development) without the express approval of the Board, which reports to the CIO/CTO if s/he does not directly sit on it.   Completed changes are reviewed to determine that they correspond to an approved change-order and that they change “nothing more and nothing less” than what is called-for.   Programmers lose the autonomy, the power, and the discretion that they might be accustomed to.   But, the programming environment is vastly improved.

Good software process management also relies upon source-code control, a ticketing system, and the discipline to effectively use both.   It relies paramount on clarity and effectiveness of human communication.

[DanBev]

Many people presume that software, because it “merely” consists of source-code files, is easy to change

You're absolutely right.
Unfortunately, writing code it's considered just writing. When discussing, I often use the metaphor of building an house: If you want a kitchen on the second floor, and after the work ends you realize that is better to have a kitchen on the first floor, if you design a familiar house but after you want an open space, it's easy to realize that throw down everything and redo it's a cost of time, money, and resource.

I'm completely agree with your analysis.

[sundialsvc4]

The analogy I like to use is one that’s lifted from a little Kindle-only book, Managing the Mechanism, available (only) on Amazon.   The analogy is that software is an autonomous, self-directing machine.   Acting only on the yes/no instructions of which it consists, software must direct the digital computer (which knows nothing at all) to do exactly the right thing in all of the circumstances it might encounter.   All without any direct influence by the programming team that built it.   The software must not only play football, but win the game, and all this with no humans on the field.

And the complexity of that software contrivance is ... basically, infinite.   Almost any part can interact with almost any other, and interactions occur both across “logic” and over time.

You would never build a physical device, nor any sort of building, with such complete lack of process discipline.   (Building and engineering codes, laws, etc. would not allow it ... and of course it would be “obviously folly.”   Well, the “folly” in software is many times greater ... but, somehow, not “obvious.”   Project-management of a software project is like no other form of project management, because the nature of the project being managed is like nothing else in the world.

I think it’s coming out on the Apple iBook-store soon.   I see no reference to a printed edition.