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

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.

Comment on Re^2: Good programming practices and changes in requirements: how to maintain good code

Replies are listed 'Best First'.
Re^3: Good programming practices and changes in requirements: how to maintain good code by locked_user sundialsvc4 (Abbot) on Feb 13, 2015 at 00:55 UTC
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.

Replies are listed 'Best First'.

Re^3: Good programming practices and changes in requirements: how to maintain good code
by locked_user sundialsvc4 (Abbot) on Feb 13, 2015 at 00:55 UTC

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.