Fixed one thing, broke something else. What is the name of the pattern?

Question

How do you call the pattern or architecture of the system, that when you fix something in one place, you later notice that something is broken somewhere else?

I am failing to come up with a concise name for that. It is the situation with the system when you lose confidence in that you or someone else is doing things right. You feel like you've lost control over complexity. In worst case it is the architecture where you afraid to do any change without thorough test coverage or rigorous testing. The pattern where you start to hate your job, because every minor code change is connected with enormous amount of time and effort, where you begin learning language with static typing or just start to do more "dumb coding" that "smart thinking" in hope that coverage will warn you about mistakes.

Before this problem in software development can be dealt with, it needs to be defined in short and concise manner. Maybe you know an entry on jargon file or already coined this definition in your team?

This word is needed to describe a bad architectural move. Quite often it is called spaghetti code or smelly code, but it not an exact description of the system that supports only this hole patching development process. The main characteristic here is that every fix is likely the cause of new issue. Sometimes the process is endless, because new people can not see the real cause, and repeat the mistakes over and over again reinventing the wheels on the way, etc.

Answer 1

Michael Feathers has some good points about this in his "Working effectively with legacy code".

He mentions an anti-pattern "shotgun surgery" that obviously matches systems like the one you described: if you want to introduce a change you have to touch many different places in the system because concepts are not designed clearly and are not segregated. Often copy-n-paste orgies led to the current system.

Further he says that "There are basically two ways to work with code":

• Edit and pray
• Cover and modify

He sums up the edit-and-pray methodology:

This is the industry standard, and consists in the following steps:

1. Carefully plan the changes
2. Understand the code you are going to modify
3. Start making changes
4. Poke around to see if everything is working (this step is very important)
5. Repeat 3 and 4 until done

WEWLC boils down to blaming all code without test coverage to be legacy code. In contrast to that with "cover and modify" you have (unit) tests.

And finally his point about the Legacy Code Dilemma: "before making changes we should have tests, but in order to have tests we have to change code".

Answer 2

There's no common name for that, although it occurs so often in practice, that a whole new programming discipline was invented mostly because of these errors: Unit and Integration Testing.

I'd call it 'brittle' or 'fragile system architexture' with no automated tests in place.

HTH Thomas

Answer 3

A software regression is where a feature that has worked before stops working.