> Or maybe I decide to squeeze in an extra if-statement in already tricky code.
And that's how the long tail becomes long tail. Nobody touches that part of the repo, because you have made it untouchable. People find working around easier than understanding and modifying existing code. Mess becomes messier.
Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place better than you found it.
Sometimes you have a root cause deep in the architecture. As long as that cause exists you will have to work around it. Each work around will have to be removed if you ever fix the root cause.
I saw this as a developer and had thought it was better to just leave the architecture alone and keep the work arounds as tidy as possible. Then I started working in manufacturing, a production line has many similarities to a running program, and saw the true cost. We fixed a root cause at the beginning of the line and all the work we put into working around the original problem was more of a mess to clean up than fixing the root cause.
I'm now a believer in trying to fix the source if possible.
That said a legacy code base with no tests is less likely to get a structural change from me.
If you are implementing a workaround, then that is a potential opportunity to solve a root problem deep in the architecture.
The point being made is that going in to fix that root cause because you think that there will be a need for workarounds in the future is premature and can cause problems and unnecessarily break working code.
> Each work around will have to be removed if you ever fix the root cause.
Do they? I feel like many workarounds will just hang around, checking for situations like inconsistent state that no longer arise. You might be better off removing checks for conditions that no longer occur (or not...), but it's not exactly urgent.
>Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place better than you found it.
Writing clean code and leaving the place better than you found it requires time. Time we generally just do not have. There comes a point where things just have to work, and all of your ideas about what is "right" and "clean" have to be set aside to make that happen.
> This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix.
This is not true at all. The definition of "clean code" is highly subjective and context- and experience-dependent. Your personal opinion and feelings towards a code style are not the same as bugs, nor is a lack of compliancd with your personal taste a potential liability similar to not adding a test.
At an ISP, when I was much younger, at the coffee machine I asked the Technical Director why we didn't invest in some technical cleanup. He replied that any available finances are much more profitably spent in advertising, which was directly correlated to sales, which were critical to survival. I guess that's why there are two sorts of companies: those that survived, and those with great code quality !
There is a programmer that reads, absorbs the system as a whole and deals with it as it is.
Then there is the programmer who just wants shit written that can get them most of the way there and he'll fix the other shit to do as he wants eventually.
The software industry is generally run by the latter.
The former are those that see the most value in high quality code, because quality only matters when you can't reerite the thing without applying a cost function.
Context is not critical to knowing when to invest in quality. That is paying lip service to the fundamental nature of what business programming is.
Running a business staffed with programmers is all about balancing onboarding, spin up, time to contribute, etc, etc.
With high quality architecture that business loop is far more efficient. Costwise, time or money, all of that meta-businessy crap dwarfs the actual implementation of new features.
...And you can never rely on the person you need to be there when the chips are down to stay there when it happens, because Murphy finds a way, no exceptions.
You do it right from the beginning, or you write shitty software. There is no middle.
> The software industry is generally run by the latter.
Obviously. The latter adds value way faster, instead of wasting time "absorbing" stuff he will never need to touch.
Also, the latter understands code is ephemeral and the stuff you're wasting your time trying to "absorb" might not even be around once the next ticket is worked on. Even if it is, it will only need to be worked on if it ever gets in the way of a business requirement.
There are plenty of reasons why "goldplating" is a highly pejorative concept in software development.
So you've introduced the context of large scale mission critical software. Not all software is large scale and not all software is mission critical.
Sometimes a crappy script that saves an administrator 2 hours a day can be a Huge win.
Sometimes lives are on the line and bugs are not acceptable. Other times the cost of a bug is some internal user has to deal with a little frustration.
All investments are about weighing the cost with the potential benefits. Developing software is an investment.
>This seems a very short sighted attitude to me, like saying that there is no time for testing, there are too many bugs to fix.
It is. The priority for a programmer goes: make it work -> make it fast -> make it clean. And you either have time for all three of those, or you don't. Generally in reality though, when dealing with business needs and product managers, the pipeline becomes: make it work -> alright now make this work -> alright now also make this work.
I would argue that for most code, making it clean should be a priority over making it fast (optimizing for simplicity and readability over algorithmic performance).
It's distressing how often I see this argument. I've been a proponent of keeping code tidy and tech debt under control for my whole career and all I've ever seen from other developers who do the same is much faster sustained development and far fewer bugs that waste time later. It's the teams who have let tech debt spiral out of control and jump from one quick change to another that I see drifting towards constant firefighting and never having time to do things properly. The argument made in defence of their abysmal performance when that happens is always some vague claim about needing to ship for business reasons at some important moment in the past and yet never considers that there will probably be many more important moments in the future (at least if the business is going to survive and prosper). I'm still waiting to see a startup fail because its developers wrote good code in the early stages.
if your constantly ticketed and measured on an hourly basis, there really isn't "time" available outside of what was allocated to you
on the other hand, if your workload is a collaboration, then you have the opportunity to negotiate "time" to fix issues that are slowing you down (compile times, test iteration, debugging, tooling) which will buy your more time (for features/improvements) later
There comes a point where impossible to leave code in a better state without a major refactor.
The choice is between writing a few ugly if statements making the code a little worse or spending 10x the time refactoring hoping you don't introduce any regressions.
The choice is between writing a few ugly if statements making the code a little worse or spending 10x the time refactoring hoping you don't introduce any regressions.
Those few ugly if statements might make the code only a little worse and take 1/10 of the time to do the job properly if the code was previously good. However the trouble with technical debt is the interest can compound rapidly. Your random set of if statements combined with three other developers' random sets of if statements from previous hacky changes (two of them in other parts of the code that the part you're modifying now implicitly and surprisingly depends on as a result) could be a story with a very different ending.
Developers should only touch production code if there is a good business reason to touch it, whether fixing a bug or adding a feature. If there is no good reason to touch a bit of code, you should not be touching it. Otherwise you're just adding noise to the audit trail, perhaps along with bugs in otherwise perfectly fine code, without any justification.
The long tail is a long tail because there are no bugs not reasons to mess around in those parts of the code. Feeling adventurous is not a good reason to mess with it. If you have to implement a feature or fix a bug, complaining that it's old code won't make things go away.
And that's how the long tail becomes long tail. Nobody touches that part of the repo, because you have made it untouchable. People find working around easier than understanding and modifying existing code. Mess becomes messier.
Writing clean code is not about introducing big abstractions, large refactors. It's about leaving the place better than you found it.