On every medium to large software system, consistency becomes critical.
By consistency I mean the application of certain architectural patterns that are considered the standard way of "doing things" in a software organization. Consistency helps keep the system understandable to all programmers currently involved, and to those that may come in the future. Consistency also helps when solving known problems as established patterns can be applied with ease. Consistency attempts to keep the entropy of the system under control.
On the other hand, it can also make improving a system hard. How can you change the standard without introducing inconsistencies? In a large project there is probably no good reason to change existing code that is already working for new code that does the same in a different way. No matter how better the new approach is; it just isn't cost effective.
In my opinion, consistency can not be taken in an absolute way. Consistency is never a good reason not to improve a design. If this wasn't true there would be no legacy code ever. Instead new valuable ideas should be embraced and considered the new consistent way. No new code should be written following the old way. Changing the old code should be considered technical debt if it merits the effort which very likely it will. Resistance to changes that improve the quality of a system overall is irresponsible.
How is this issue dealt with in your organization? Is consistency used as a reason to reject changes?
2 comments:
good stuff ... keep it up
In my current team consistency is very important! and every team member takes special care to wrote new code in a manner that is consistent with existing code. This goes as long as the existing code we are using to make our new code consistent with is still considered to be good code. The moment the team decides a certain type of problem should be solved in a way that is different, that old way to solve the problem becomes legacy code, and we take as much care to make sure no new code is written the old way.
The longer you are in a state where you haven't decided if certain parts of the code base should become legacy, the more expensive it will be to replace the future legacy code with good code. All this is without taking in to consideration the endless arguments, and the time wasted in them...
Who decides when a piece of the code becomes legacy ? I think this is one of the responsibilities of team's technical leader.
Post a Comment