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.
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.
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.
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 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.
Context is critical to knowing when to invest in 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.
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.
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.
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.
It obviously depends on the application.
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.
Am I the only one who thinks this old trope is a fallacy in most situations?
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
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.
Not really.
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.
sure, but you might decide to work on a different feature/bug because this part of the code is too arcane to touch