This is true until it's no longer solving the problem. Maybe the business grows or changes and the software needs to change with them. Then the code needs to be easy to change and robust.
In practice it isn't even that much more likely to break, or even add features to. The code is just much uglier and more complex than it could be, and probably slower. But it runs and keeps running.
Most of the time those business types are correct on this.
The only thing is that once the original team has moved on, then if the code is too complex, it can become almost impossible to change.
Exactly right, it can be very hard to make changes (even the right changes) once it's in customer hands. Sometimes it is easy, sometimes it is not. However, it's always easy to throw out code that isn't yet committed.
there's an amazing thing about code is that once it works, it can continue to work in the exact same fashion indefinitely as long as nothing changes
No business stays the same. All systems have to change, either due to evolving business needs or because the data inside them are growing. The first means bad code getting changed, generally at incredibly high cost. The second puts stress on critical points in the bad code, generally causing unexpected and intermittent failures.
I think this is true for any specific moment, but as we are creatures of the 4th dimension, we must also care about how we change our code over time. When code complexity is managed, users can enjoy better versions of a piece of software more quickly and more often. If we let our code deteriorate into an inscrutable pile of tech debt, it will eventually affect the user experience, so the guts need to both do something correct (and useful) and also be amenable to change over time.
Expecting code to be replaced every 2 or 3 years is nervous-making for a couple of reasons.
First, new code is always less reliable than old code, so -- all other things being equal -- devs should lean toward keeping the old code rather than replacing it.
Second, code should be architected so that any changes required to adapt to changing conditions should be limited in scope. The bulk of code for most projects should only very rarely need changing to adapt to changing conditions.
Software solves business problems. Code that meets its requirements needs to be left alone. Developers just changing code because they feel like it need some coaching. They're wasting everybody's time for reasons that amount to "I like it My Way".
So, with normally performing developers, the only code that changes is the code that needs to change. Good or bad only has an influence on the cost of a change.
What happens when the needs of the customers or users change? What happens when your understanding of their needs was imperfect and needs to be updated? Is the software that met the old needs still good? Was it ever good?
What happens when the software could only ever meet the old needs, but is impossible to update to meet the new needs? Was it ever good?
Needs change. The ability for software to be altered to meet evolving needs is not simply a "technical quality of the implementation." It doesn't just have a faster algorithm. It's better software.
I think the core problem is that it assumes you know what part of the software will need to be changed. But you often don't so you end up with code that is too rigid in places that you need to be flexible and too flexible (i.e. complex) in places that don't need it.
Needs change over the lifetime of a project. The flexibility that is a virtue at first becomes less so as designs solidify. Theoretical issues become problems as a codebase/team scales.
Can you fix a point in time? Software evolves and I think a point I saw is that it wasn’t well tested then they changed once production workloads told them it needs to change.
> In most business cases, code needs to change frequently
That has not been my experience in several industries. Sure, there is always something that is being changed, but once the project matures the changes tend to be at the boundaries or around new features that were recently introduced. A relatively small % of the code is changed each year.
reply