Is The Original Programmer Responsible For Maintainable Code

Extreme Programming Mantras: DoTheSimplestThingThatCouldPossiblyWork and YAGNI

If in the process of programming the assumptions of these mantras result in code that is hard to understand in a couple of years by the original programmer, never mind the one who is to add the feature that was not thought to be needed. Since another very vocal mantra exists within this mindset, that code documents itself, and that with proper procedure and variable naming one can easily understand what the code does and what it enables to be done. Never mind inheritance, polymorphism and other such separations of the code from what it does. The question offered by this page is whether or not the original programmer should be concerned with making the code speak for itself in such a way as to make extension and maintenance possible. Should the addition of a simple functions to existing code be enabled by design, documentation and attention to detail and conventions clearly spelled out by the discipline, language documentation and convention. Does code that "works" also need to be easily "modified or extended"?

The answer is "Yes, the original programmer is responsible for maintainable code." Add RefactorMercilessly to the mantra list. CodeForTheMaintainer

". . . separation of the code from what it does . . ."

What does this mean? Is it desirable for code to not reflect what it does? No.

''The word used was separation, not reflection. It is typical for the operational details (code) to be separated into many different fragments, with the details hidden from view and available through such references as APIs, syntax descriptions and form, etc ... It is typical for programmers to use code and coding procedures because of what they do, rather than because of how they do it. When the requirement for maintenance requires breaking into the the otherwise acceptable usage, to forge a new usage (as in adding a method to a class), one must delve into what the code does and determine how to make it do something more or differently. (The change may be either structural or procedural)''

The most probable answer to the question is - NO. Particularly in programming environments where code is issued with known bugs and shortcomings under the pressures of accelerated schedules and failures in quality control. Just deliver something that under anticipated conditions "works" GoodEnough.

Doing extra work to make software "modifiable" or "extensible" usually leads to only to additional complexity and rigidity that has to be undone when the time comes to modify or extend it. Designing software up front to be extensible rarely actually makes it easier to extend. Programmers are not very good at predicting what changes will be needed in the future, so it is best to avoid any crystal ball gazing.

The original programmer is responsible for creating understandable code that works--that is my definition of maintainable code. If the code is simple and understandable, it is just as easy for a maintenance programmer to make changes later as it would for the original programmer to do it now. And if the changes never become necessary, then unnecessary work has not been done.

Unfortunately, maintainable code has another definition in environments where either a HighlyPaidConsultant or very senior programmer is assigned to write the initial program, and then low-paid and low-skilled SoftwareLabourers are expected to be able to plug in new functions or make minor changes without any understanding of how the program works. In such an environment, yes, the original programmer is responsible for foreseeing all possible modifications and creating a bloated architectural monstrosity that allows a GruntProgrammer to add new menu items or text fields without regard to the effect on program structure. The problem with such an architecture is that it only supports certain kinds of changes, and it is not flexible or adaptable over the long term. You will be dependent on that HighlyPaidConsultant to make any non-trivial changes, as nobody else will be able to understand the architecture.

Someone is missing something here (it could be me). I consider DoTheSimplestThingThatCouldPossiblyWork and YouArentGonnaNeedIt to be mantras that make code maintainable, not the other way around. If I always do the simplest thing and don't add lots of extra stuff I don't need right now, two years later when someone looks at the code, they'll see simple code with no cruft, right? --BrianRobinson