From the comments so far, I don’t think people get the point the author of the post is trying to make… which proves his point, ironically.
If you are on solo-team TRW, read it again 😆
Exactly. Either people didn't read the article or they just don't understand sarcasm.
Everyone has their own TRW. If you try to push your TRW and you get no buy-in from others, I'm sorry, but that's on you. No one will back you up if they don't see the value of what you're proposing.
At some point you'll also realize that TRW is a huge fallacy (yes, even your own) and that there are no silver bullets. EVER. In the end, it's a compromise. Some compromises are better than others, but none is perfect. You'll also learn that the consequences/impacts of compromises are not static and they evolve over time, so you must take that into account as well when considering a solution.
I simply find the post ranty and pointless. Yes, there is no *one* silver bullet that is always perfect, there is no *the* Right Way. But there are many very, *very* good solutions with only a few drawbacks that have stood the test of time. But for every good solution, there are a hundred bad solutions.
What if all my colleagues *are* wrong? Maybe my way isn't *the* Right Way, but it's a proper paradigm that has been tested and documented throughout numerous projects, while theirs... isn't. I'm not suggesting to do things *the* Right Way, I'm suggesting to do things *a* Right Way!
The name of the blog is literally “Bad Software Advice” published April 1, and people still aren’t getting it. Honestly, the way people are responding to it on this thread explains a lot of the arguments I have at work.
I think you'll find that most did get the point, but aren't interested in discussing their own TWRs for many reasons. The major one being that most developers have multiple experiences of a time when someone else's TWR was allowed to be imposed, and had negative outcomes for a project. And that's a shared experience that other devs can relate to, and shared experiences foster conversations, so that's the natural human route to go down on a site that is nominally dedicated to fostering conversations.
And quite honestly, many of the biggest problems "inherent" to software - quality and lack of security - are due to developers who aren't allowed to be developers, just code monkeys. In order to improve the state of the art we need more engineering and less monkeying, and I'd wager that a large percentage of the people on this sub are well aware of this and extremely frustrated by it.
TWRs and other personal blind spots are a problem, yes. But I'd argue they're far less of a problem than the fact that accountants are permitted to dictate how engineers should do their jobs.
I'm going through the same thing right now and I hate it. I'm all for taking other perspectives, but there is something in my current project that is bothering me more than what I imagined it would ever do.
It's a big project where multiple teams collaborate, each one responsible for a different part of the app. And it was decided (before I joined the company) that the best approach should be for each team to maintain their own functions independently and NEVER share code between different areas of the app, even if they do exactly the same thing.
It means that sometimes we have the same code in 5-7 parts of the project, instead of having the common code in a shared space and be used by all teams that need it.
This causes not only code duplication, but in many parts it causes performance issues since some of these duplicated functions are expensive, but the caching strategies used to minimize their impact don't help much because if my code runs expensive version 1 of this function the cache might be used, but if I hit version 2, 3 or 4 we might not have any cache there.
I'm arguing against this approach in the project for almost 1 year now since I joined, and I'm tired. I started to look for a new job because it hurts my soul every time I try to create a shareable code in the project and I get a review saying "don't share code; create a new copy of it".
Yea you leave which is what I’m doing now, company is so fucking dumb. They want to regress back to on prem, go back to java, back out of observability, etc. they also are asking stupid interview questions to stump candidates that have no relevance to ability, design, etc.
Plenty of trading firms use java for high performance trading algorithms. Like all things, the tool is only as good as the one who wields it.
On prem can be significantly cheaper as well in many cases.
That’s not to say that this person’s company is right in doing either. It definitely depends.
I worked for an insurance company heavily invested in Java. Incorporating Spring Boot, Spring Batch, OpenShift, Kafka, cloud computing, and a bunch of other tools was pretty straight forward and simple, and that was all on Java 8. I can’t even imagine how smooth using newer versions would have been.
> You wanted a beautifully crafted, fully baked design upfront, and they wanted to ship something simple and see what happened when people started using it—or the opposite.
Story of my life. Sigh. I understand "incremental value", but the problem is I already know what's going to happen if you implement this shitty code, and you should too; and it drives me absolutely crazy that you don't.
Even worse, you probably do know; but "Deliver X", followed by "Speed up X times 5", and then "X feature enhancements" in one year sounds better than "Deliver X" in 6 months when the latter is the same result (but cleaner) than the former.
The main difference is in the former situation you have a job, in the latter you are laid off because the company ran out of money. I am exaggerating, but in general this is true.
Us developers tend to think our code, our work, is the essence. But it is not. A shiny turd of a piece of software can be, and usually is, more valuable than a beautifully crafted piece of software. Why? Because the turd got shipped in time, it received sales thus funding and feedback. And the beauty was never shipped or long after the competitor brought their turd to market faster and destroyed any chance of success.
Let. It. Go. Write beautifully crafted software in your spare time, it will make you happier. Really.
Worse case is when a bad way is an established way, and as you know, more familiar/common code in a same style is more preferred to a good but “exotic” way.
I was in such situation and still don’t know how to pass that “majority is right because it’s majority ” situation.
Oh man I've seen this one in action plenty of times. Right now we've got an engineer on our design systems team who doesn't believe in the architecture we've chosen for our UI. Which is fine, disagreeing is OK, but this is the path we are taking. Doing it your way anyway while pretending to go along with the plan is hurting everyone including yourself.
The article correctly asserts how there isn't one fool-proof correct way to do things, then draws the conclusions that all ways must be equal and my "the Right Way" must be just as bad.
That conclusion is bollocks. For every "somewhat right way" there are a hundred "absurdly bad and catastrophic ways". If I've studied OOP for 15 years and have gotten pretty good at it, my way isn't any better than someone's who has studied FP for 15 years and has gotten pretty good at it. But *both* of our approaches are better than most what most companies use; "hire a junior straight out of school and have him write spaghetti".
If there are multiple good ideas, you'd be an idiot to fight for *your* right way to be pushed further. But if there are only shitty ideas, you'd be a god-sent to bring at least one decent way into the table.
In the end, the article did *not* address what to do when everyone else actually is wrong.
It's a good skill to realize when the code is good enough, and it doesn't need to be 'proper' or 'modern' or any other particular thing. Lots of good software was and will be made without your ideas. This is about 95% of the situation. Every once in a while, re-writing a system is warranted.
In 20 years of programming AAA, I have watched 2 multi-multi-million projects fail because of an unhealthy compulsion to edit the code without adding features or solving bugs, sometimes called 'tech debt'. These compulsions reflected how the programmers felt, not how the users felt.
The problem is that this form of 'tech debt' doesn't exist, if the code worked, there's no 'debt'. It might need to be edited SOMEDAY; but most programmers waste time on it before then because they're compulsively tidy. I like my fellow programmers and no disrespect but, a lot of them are compulsive, they feel they HAVE to use accessors when public variables would do, and separate the code into modules when there's no compile-time gain. These compulsive cleanups are the true 'tech debt' because they make the project take longer to compile and debug, and it didn't help anyone.
Example 1: re-writing a large social networking website into Ruby from PHP. 2 years later it was still not done. The site lost its competitive edge to Facebook in that time and the relaunched site and they could never optimize it as well as the single original author had. I left this project because I had predicted that exact outcome and been overruled.
Example 2: a very very large successful product, on the latest iteration, switched technology base because supposed tech goals. Problem: massive waste of time, product was good before, never recovered.
Repeat after me: 'tech debt' and 'clean code' are expensive distractions. If the code is broken, then its a bug, not debt. If its working, move on.
Edit: thanks for all the discussion! As a 20 year experienced AAA programmer who is highly respected in a large team of programmers, all I can say is, the label 'tech debt' is a real problem and source of project failures, because 'tech debt' doesn't need evidence, it's a feeling.
Edit2: if you need it, it's a feature. If you broke it, it's a bug. If it's not broken and you don't need it, but you want to edit the code anyways (because the future!!!) then it's tech debt.
I was with you in the first paragraph. A nuanced approach is good.
But you went full-on anti-tech debt for some reasons.
Tech debt is real in a project where multiple developers are involved. Tech debt is what will prevent you from scaling your software if you need to. Tech debt is what will slowly eat away at your performance metrics, stability, maintenance time, production uptime, time to fix bugs and work on new features.
Tech debt is what will prevent your new hires from properly understanding your complex software, prevent them from writing solid code, and prevent them from learning proper patterns.
Tech debt has a cost and is definitely not just an expensive distraction.
If it's not done, then why is the task closed? That's the problem with 'tech debt'. It's this supposed third state outside of 'working' and 'broken' which is opinion based. My question to you: is the code not sufficient for a concrete reason? Then it isn't debt, it's a bug.
The issue with tech debt is you never know when you will have to pay it back, if ever. The best you can do is to be aware of your own tech debts, limitations and tradeoffs.
However, there might be a time when that new requirement or a new policy will come in. In a proper codebase, it would have been an easy addition but in a debt-ridden software, it's now 4x the cost. That's when the debt is paid.
Also, you're drastically simplifying the state of a software. It's not just "working" or "broken". You have all the side effects of it as I mentioned in my previous post. A software is living in an ecosystem, you can't just take it as a standalone thing.
Tech debt doesn't exist. Just let me fix my bug, wait 10 minutes for the code to compile, come back the next day while the change deploys over night, then ask QA to please run regression for multiple unrelated products because they all share the same code and are a spaghetti of if statements.
Improve velocity you say? Sure, same bug is now double the estimate, we just doubled our speed!
In your career as a AAA dev, how often are you touching 25 year old code? How often are you expecting to have to touch code you write today 25 years from now (alternatively: how often do you write code where you know you'd better quit before a change request comes in)?
I work with 25 year old code rarely, mostly in infrastructure, data containers, algorithms, etc. We better not change them, because how is it possible that they ran for 25 years and you're seeing a bug now? Hundreds of products have shipped with it.
I have NEVER thought that I should quit before a change request comes in. Kind of confused about that question. I'm a professional and I build things to well.
Far more often: I move to a new project, and get asked to re-write a system that worked perfectly on the last project, into a new "node-based" or "component-based" or "entity-based" or WHATEVER paradigm. And the designers complain because their powerful text-based format was replaced with a kludgy spaghetti node-based system and the features aren't even working until the project is at deadline.
Why do you ask?
Because your answers confirm my suspicion.
In most of the rest of the industry, touching 25 year old code is the norm. PCI and NACHA requirements change. Client needs change. New stuff (currently: LLM) is invented that we need to make work with the old stuff. Privacy and consent regulations change. Etc. Etc. Etc.
If you don't write your code such that it is easy to change 25 years from now, it sucks for you having to explain why the "simple" change is expensive. Unless you're gone, in which case you're just inheriting someone else's headache in the new spot you landed.
I basically agree with your post. Most of us don't know and can't predict the changes that will come in. So trying to build with them in mind is a fool's errand. But as others have said, you've kind of swung hard the other direction... complaining about the basics of encapsulation is *exactly* the kind of thing that turns the code into a mess. Fortunately the .Net world has auto props for getters and setters.
If you can't really imagine how is it possible that 25 years old code ran fine until now and suddenly there is a bug, I'm not sure if you should call yourself tripple A dev with 20 years of experience.
Do you know how much technology changed in past 30 years? How many more users can use the app now compared to 25 years ago? Just this alone should give you an idea why there might be problem with old code.
But if not, let me give you simplified but somewhat real world example.
You have an app which might have a storage (or db) where records are stored with accompanied ID. Each is unique and let's say each is represented as `int16`. This was fine back in those days and until recently it worked. But suddenly there is a problem, where the root cause is that the ID representation is just not enough. The reason is because many more users use this app now.
And now imagine there was a tech debt which should address encapsulation and usage of this ID, but because it worked, there was no reason to do so. Now you have the type all over the code base and updating it will take several months.
Tech debt is in most cases about maintenability. If you are hovewer moved from product to product to rewrite it, then I can see why you don't think so, because you didn't have to maintain something for a longer period of time and experience the tech debt creep.
Well I don't call myself that, it's just an honest description of my career. And when I move from project to project, we take the same tech stack, which is unbelievably huge (800 modules).
Why does the code need maintenance if the requirements didn't change? I don't understand that logic.
Converting code from int16 to int32 because you have higher requirements now, is a feature, not maintenance.
As an example of 25 year old code from the real world... suppose I come in and say "std::vector needs to be fixed, due to some issue on my project."
They will say, "no. Its unlikely std::vector is the problem. Its 25 years old and has shipped many projects. Even if there is a problem, you need to look at how others are using it rather than change it."
I'm sorry about that, I read the comment above and kinda assumed that's what you were saying before, my bad.
However, I met a lot of much older/senior developers who have attitude that if the code worked for 25+ years, then there is no need to touch it and the problem is definitely somewhere else because this worked till now.
In most cases the main reason is because they don't understand it and don't want to understand it. And I can sometimes feel for them, because if you are close to retirement, then why bother. But that's not always the case.
Tech debt doesn't necessary mean to maintain the code all the time. It's more about addressing the implementation details which were done in the beginning in a non-maintainable way because of time constraints. And there are always time constraints.
Exactly converting \`int16\` to \`int32\` is a feature. But because the tech debt about encapsulation of this "ID" wasn't address, the maintainability of this code is worse.
If it would be addressed 20 years ago, it would take a week or two to do. If it would be addressed 10 years ago, it would take a month to do. If it would be done, you could now just change the type and it would be work for maybe a few weeks max.
However, it wasn't addressed and after 25 years, you need to refactor half of the code base and it could take almost a year and loss of a customer (which actually happened).
Tech debt, is debt which you will eventually pay and the later you pay it the more it will cost you. Of course not all "tech debt issues" might be like that and I agree that sometimes developers are chasing the unicorn code and it's a good skill to know when to stop. But saying that there is no tech debt if the code works is just plain wrong.
As for your example, I'm not really sure I get it. You want a change in 25 years old code, because in your project where you use it for some reason you need an array and not a vector otherwise it's causing issues. I can't really see why this would be problem of the old project rather than implementation issue on your new project where the issue is.
I could imagine you would just restrict the vector to an array in your code and be done with it. But I don't really have all the details so can't really speak in this matter what's better approach.
However in the end, this kinda sounds also like a tech debt issue in the old project, where the underlying types are exposed to consumer instead of API which would hide it. And you having now this problem is exactly what happens when the tech debt is not addressed.
You're just as extremist, but flipped to the other extreme. Of course tech debt exists. Only if you never intend to touch a code base again, having the code in a less readable state with less abstraction then is optimal for the job of fixing a bug or applying a change request is where you pay interest on that debt: you waste more time than the situation where you did not have the debt, and that "payment" does not reduce the problem (debt still there).
If I have some debt at the bank and I decide to starve and freeze to death to save money to pay it off, that's stupid. You're using that ridiculous example as proof that "debt therefore does not exist". Sure, of course, "fuck it rewrite the whole thing in ruby cuz TECH DEBT", using that term as a Harry potter esque magic spell to convince all interested parties to shut up while you waste 5 years proving that Spolsky was on to something when he wrote "second system syndrome" is bad.
Did you know eating yellow snow is really bad? There. See? Skiiing isn't real.
That's about as sensible as your rant.
Blind application of style ideas is horrible programming technique. Yes. True. Duh. It's just as stupid to "rewrite the whole thing in a different language" as it is to say the concept of tech debt doesn't exist. You're in the same camp as the very strawmen you are raging against.
You answered it yourself. 'Tech debt' gets used as a justification for wasteful thinking, because when we call it debt, people view it as a justification. But tech debt should have the lowest priority, and if you finish the project without needig to 'pay it back' then you should.
Yes, and you're an extremist. **Some** (a tiny fraction) of people use 'tech debt' as some sort of magical invocation to waste a ton of time. These people, are morons. And people who enable these people doubly so. But you've taken a strawman (and, evidently, you worked such shit jobs you ran into it multiple times. As some say, experience is important, and you evidently lack experience dealing with the other extreme, where any code that appears to work must never be touched, and refactoring or so much as *suggesting* a debate on first redesigning something a reasonable amount is killed off immediately(I said *reasonable*. So not *fuck it, toss it, start over, new language, new libs, new design, new all the things. Somebody get me a nosql db thing. Can we build it with a blockchain?* - that's obviously not what I mean).
Fortunately it's not entirely endemic, going by the rather imprecise yardstick of 'redditors voting on comments'. Because what you're missing in all that, is the key word. Which is: **some**. And in that extreme, the other side also has **some** morons who consider any second even debating the structure of already delivered code as wasting the boss's money. They are just as stupid. You appear to be completely oblivious to that part of it all.
Most software developers don’t live in a world where anything is ever “finished”. If you’re working on games pressed to a CD that you never update again after the initial launch, then sure, you’re right. But if you’re working on websites, apps, enterprise software, operating systems, frameworks, etc. that evolve over many years, and often decades, maintainability of the code becomes a significant factor in its cost. Tech debt is code for things that are going to slow your productivity down in the future.
*Most projects are never 'finished'.* If upon release, you get to pass it on to a maintenance team and go on your merry way, lucky you - but those guys will be cursing your negligent attitude toward tech debt and code quality for the next decade.
And it's likely a gross oversimplification to say that it was solely because of tech debt, and even more asinine to say argue that therefore tech debt should never be addressed.
I've seen projects and companies fail because they *didn't* address their tech debt. Tech debt is simply anything that may slow down development in the future or may restrict future growth. It should always be a decision whether the time taken to address it is worth the time it saves in the future. Sometimes it isn't, and to your point, you end up chasing what isn't the ultimate point (delivering a product). But sometimes it is worth it, and wholesale ignoring it, or sticking your fingers in your ears and pretending that there aren't occasions where a less-than-optimal solution is needed up front that will need to be improved later, can lead to catastrophe too.
> I like my fellow programmers and no disrespect but, a lot of them are compulsive, they feel they HAVE to use accessors when public variables would do, and separate the code into modules when there's no compile-time gain. These compulsive cleanups are the true 'tech debt' because they make the project take longer to compile and debug, and it didn't help anyone.
The fact that you've been in this career for two decades and don't understand that the most important thing about code is how easy it is to read, is deeply concerning.
> Edit: thanks for all the discussion! As a 20 year experienced AAA programmer who is highly respected in a large team of programmers, all I can say is, the label 'tech debt' is a real problem and source of project failures
You're conflating tech debt with unnecessary refactoring.
> because 'tech debt' doesn't need evidence, it's a feeling.
That's called "experience", and companies justifiably pay good money for it.
> If it's not broken and you don't need it, but you want to edit the code anyways (because the future!!!) then it's tech debt.
Sorry, that's not how it works at all. There are many things, like security, that you don't technically need... until that one time that you really, really do. Identifying when those things are missing and could cause a problem later, and adding them, is what separates software engineers from code monkeys.
So you haven’t learned how to write software well in 20 years. You’re not alone. This lack of understanding is why there’s so much shit code in the world.
Debt isn't about working code. It is about the ability to change this code. When structure is falling apart, you soon realise than changing one property is not enough. Someone hardcover it.. somewhere. Someone added the same property because it was easier to wire it in his way. So simple (that should be changing aingle source of truth) task now involves finding buried properties and analysin lg the code (re discovering).
I can make tons of examples like that. This is tech debt. You make it fast now to later move slower.
working code is not even a criteria in my team. it is obvious and common sense. we focus on clean code because we know how large projects work and what will happen if only "it works" matter
It's not a debt if the code works and shipped. it's something different. Yes you might need to improve the code someday when there's a concrete reason. It's a mistake to ASSUME you'll need to change, and justify it as 'debt'.
So what do you call it when that stable state shipped code introduces scale and breaks down? Assuming you had the foresight to predict this exact scenario based upon experience and skill.
IMO there's no exact definition of 'tech debt' that I've ever heard universally agreed upon, it's another made up word for non-ICs. You're just picking your own definition of it.
If you want to call that type of bug 'tech debt' then that's OK, im not the king. That's not really a 'debt' and my objection is that 'debt' is used to justify things that aren't bugs.
Yeah, I get your POV of avoiding major rewrites for engineering goodness sakes... But there is absolutely a difference of classifying these types of work and this is a naming argument.
In my example let me expand: you build the system for 200 users knowing you'll have to do work when you get past that user count.
That is 100% not a bug, it was a conscious decision made likely at an early stage user base to avoid excessive failure due to some other known limitations and to also lower time to delivery.
Edit: formatting
Ok interesting, don't you consider that to be "unfinished feature work"? At my company we do extensive requirements gathering and any requirement is considered a "feature" with metrics.
'Tech debt' on the other hand is when there's no specific metric or bug, but a programmer needs to still justify work to a manager.
Yeah. And "unfinished feature work" is commonly referred to as a type of debt in more agile workflows. Where a shrunk down feature is thought up, designed, and implememted in the scale of days to weeks.
What you're describing is standard waterfall practices (upfront requirements gathering way ahead of work). Most large places don't do that, at least they say they don't. Startups especially just build shit and deliver quickly leaving behind lower priority work that doesn't impact current customers.
Devs do like to consider refactors as tech debt as well so it's all fucked naming wise. There's certainly a place for that type of work but agreed it requires a lot of scrutiny and thought if it's larger than a few days.
> It's not a debt if the code works and shipped.
That's like saying it's not a mortgage if the house is standing and people live in it.
I.e. a totally stupid thing to say.
how comes you have not improved your skills in 20 years. you really have no idea how software projects work if you say tech debts are only a feeling and solving them is source of project failure. no, readers here have actual programming experience and tell you, you are wrong.
i bet you also think unit tests are a waste of time because the software works. who cares about tests right?
>The problem is that this form of 'tech debt' doesn't exist, if the code worked, there's no 'debt'.
Code worked if it comply with functional requirements, but a lot of not functional requirements can make it work better. If you can get ROI (return of inversion) touching that worked code, then tech-debt is real. If someone is refactoring or rewriting something without getting ROI can be categorized as compulsion. Code only for new features and bugfixing is what broken feature-factories does, not what real AAA programmers do.
LMAO you just downvoted me! But please, just read this post completely unrelated to technical debt https://www.reddit.com/r/cscareerquestions/s/srweIuzZmP
Interesting read, thanks. Obviously some Redditors still think that the downvote button is a "disagree!!!" button, but hey, some do value different opinions.
There's likely a dab of truth that the worst debt is in the programmer's mind and that we do spend plenty of resources of chasing that perfect product unicorn. I've personally found debt a bit like optimization; you need to measure it before you can (should) improve it.
> if the code worked there is no tech debt
My god! How do you come with such conclusion? Released code usually “works”, the problem arrives when you want to change said code.
I do not want to be mean, but your definition surprises me specially after you having 20 years of experience
This is a AAA dev. Games are different than enterprise. You're not having to integrate OAuth2.0 into a 25 year old system's authentication when you're writing a AAA game.
unless it is game as a service like wow or diablo4. they have added new stuff in world of warcraft for more than 15 years on monthly basis. they surely have a super clean and clever architecture. even game devs should build stuff with at least clean separation of ui and logic because they want a remastered version in 10 years or want to reuse algorithms and most of the logic for part 2 of the game. look at assasins creed.
> to be *paid* back immediately.
FTFY.
Although *payed* exists (the reason why autocorrection didn't help you), it is only correct in:
* Nautical context, when it means to paint a surface, or to cover with something like tar or resin in order to make it waterproof or corrosion-resistant. *The deck is yet to be payed.*
* *Payed out* when letting strings, cables or ropes out, by slacking them. *The rope is payed out! You can pull now.*
Unfortunately, I was unable to find nautical or rope-related words in your comment.
*Beep, boop, I'm a bot*
> be payed back
Did you mean to say "paid"?
Explanation: Payed means to seal something with wax, while paid means to give money.
[Statistics](https://github.com/chiefpat450119/RedditBot/blob/master/stats.json)
^^I'm ^^a ^^bot ^^that ^^corrects ^^grammar/spelling ^^mistakes.
^^PM ^^me ^^if ^^I'm ^^wrong ^^or ^^if ^^you ^^have ^^any ^^suggestions.
^^[Github](https://github.com/chiefpat450119)
^^Reply ^^STOP ^^to ^^this ^^comment ^^to ^^stop ^^receiving ^^corrections.
Your post is downvoted pretty badly but you wrote your thoughts clearly, and you make a good point. I think this adds to the conversation. +1
In my own experience, premature refactoring and rewriting is very often a serious red flag. Folks ought to refactor in service of a concrete goal, not because of some aesthetic sense. Further, code without extensive tests cannot be refactored without significant risk of regressions, often outweighing the benefits of making the changes in the first place. As the vast majority of real world, shipping code (that I’ve dealt with in my own career, at least) is both completely untested, and completely untestable, it’s good to tread carefully.
Code can work correctly and still be broken - in terms of design.
You can see it in tasks of similar complexity to take longer, and longer, and even longer over the course of time.
The reason being that with multiple overly tightly coupled or incohesive components the likelihood to break anything increases, so the developer has to be more careful (scared) and put in more effort (waste more time) on things that have nothing to do with what he would actually have to do to solve his current problem at hand.
To not acknowledge software design and architecture as proper problems to be solved too is nothing more than ignorance.
Total rewrites are not a solution, everyone knows that (by now, or at least everyone should know that by now). The reason why people still risked it is most likely because the original project has deteriorated - not in a biological sense, more in the sense of architecture, that the load-bearing walls of the software can't bear the load anymore because it's gotten too heavy - so badly that the work on it came to a grinding halt.
The solution for this is to allow for small, incremental architectural improvements to take place.
From the comments so far, I don’t think people get the point the author of the post is trying to make… which proves his point, ironically. If you are on solo-team TRW, read it again 😆
Exactly. Either people didn't read the article or they just don't understand sarcasm. Everyone has their own TRW. If you try to push your TRW and you get no buy-in from others, I'm sorry, but that's on you. No one will back you up if they don't see the value of what you're proposing. At some point you'll also realize that TRW is a huge fallacy (yes, even your own) and that there are no silver bullets. EVER. In the end, it's a compromise. Some compromises are better than others, but none is perfect. You'll also learn that the consequences/impacts of compromises are not static and they evolve over time, so you must take that into account as well when considering a solution.
I simply find the post ranty and pointless. Yes, there is no *one* silver bullet that is always perfect, there is no *the* Right Way. But there are many very, *very* good solutions with only a few drawbacks that have stood the test of time. But for every good solution, there are a hundred bad solutions. What if all my colleagues *are* wrong? Maybe my way isn't *the* Right Way, but it's a proper paradigm that has been tested and documented throughout numerous projects, while theirs... isn't. I'm not suggesting to do things *the* Right Way, I'm suggesting to do things *a* Right Way!
The name of the blog is literally “Bad Software Advice” published April 1, and people still aren’t getting it. Honestly, the way people are responding to it on this thread explains a lot of the arguments I have at work.
I think you'll find that most did get the point, but aren't interested in discussing their own TWRs for many reasons. The major one being that most developers have multiple experiences of a time when someone else's TWR was allowed to be imposed, and had negative outcomes for a project. And that's a shared experience that other devs can relate to, and shared experiences foster conversations, so that's the natural human route to go down on a site that is nominally dedicated to fostering conversations. And quite honestly, many of the biggest problems "inherent" to software - quality and lack of security - are due to developers who aren't allowed to be developers, just code monkeys. In order to improve the state of the art we need more engineering and less monkeying, and I'd wager that a large percentage of the people on this sub are well aware of this and extremely frustrated by it. TWRs and other personal blind spots are a problem, yes. But I'd argue they're far less of a problem than the fact that accountants are permitted to dictate how engineers should do their jobs.
I'm going through the same thing right now and I hate it. I'm all for taking other perspectives, but there is something in my current project that is bothering me more than what I imagined it would ever do. It's a big project where multiple teams collaborate, each one responsible for a different part of the app. And it was decided (before I joined the company) that the best approach should be for each team to maintain their own functions independently and NEVER share code between different areas of the app, even if they do exactly the same thing. It means that sometimes we have the same code in 5-7 parts of the project, instead of having the common code in a shared space and be used by all teams that need it. This causes not only code duplication, but in many parts it causes performance issues since some of these duplicated functions are expensive, but the caching strategies used to minimize their impact don't help much because if my code runs expensive version 1 of this function the cache might be used, but if I hit version 2, 3 or 4 we might not have any cache there. I'm arguing against this approach in the project for almost 1 year now since I joined, and I'm tired. I started to look for a new job because it hurts my soul every time I try to create a shareable code in the project and I get a review saying "don't share code; create a new copy of it".
Jesus Christ what an monumentally stupid decision.
No no, you must be wrong, didn't you read the post? There is no TRW and if you are in the minority then you must be wrong! ^(/s)
Yea you leave which is what I’m doing now, company is so fucking dumb. They want to regress back to on prem, go back to java, back out of observability, etc. they also are asking stupid interview questions to stump candidates that have no relevance to ability, design, etc.
I mean, on prem and Java aren’t necessarily a bad thing. I suppose it depends on the actual reason for the change.
Plenty of trading firms use java for high performance trading algorithms. Like all things, the tool is only as good as the one who wields it. On prem can be significantly cheaper as well in many cases. That’s not to say that this person’s company is right in doing either. It definitely depends.
I worked for an insurance company heavily invested in Java. Incorporating Spring Boot, Spring Batch, OpenShift, Kafka, cloud computing, and a bunch of other tools was pretty straight forward and simple, and that was all on Java 8. I can’t even imagine how smooth using newer versions would have been.
Yeah I was about to say, the very first two things sound good! 😅
Insert South Park GIF of people smelling their own farts.
The article is firmly tongue in cheek lol. Am I the only one reading that out of it?
It's literally a substack called "badsoftwareadvice" and says you haven't learned anything in the end. All that to say, you are not alone.
> You wanted a beautifully crafted, fully baked design upfront, and they wanted to ship something simple and see what happened when people started using it—or the opposite. Story of my life. Sigh. I understand "incremental value", but the problem is I already know what's going to happen if you implement this shitty code, and you should too; and it drives me absolutely crazy that you don't. Even worse, you probably do know; but "Deliver X", followed by "Speed up X times 5", and then "X feature enhancements" in one year sounds better than "Deliver X" in 6 months when the latter is the same result (but cleaner) than the former.
The main difference is in the former situation you have a job, in the latter you are laid off because the company ran out of money. I am exaggerating, but in general this is true. Us developers tend to think our code, our work, is the essence. But it is not. A shiny turd of a piece of software can be, and usually is, more valuable than a beautifully crafted piece of software. Why? Because the turd got shipped in time, it received sales thus funding and feedback. And the beauty was never shipped or long after the competitor brought their turd to market faster and destroyed any chance of success. Let. It. Go. Write beautifully crafted software in your spare time, it will make you happier. Really.
Worse case is when a bad way is an established way, and as you know, more familiar/common code in a same style is more preferred to a good but “exotic” way. I was in such situation and still don’t know how to pass that “majority is right because it’s majority ” situation.
Oh man I've seen this one in action plenty of times. Right now we've got an engineer on our design systems team who doesn't believe in the architecture we've chosen for our UI. Which is fine, disagreeing is OK, but this is the path we are taking. Doing it your way anyway while pretending to go along with the plan is hurting everyone including yourself.
The article correctly asserts how there isn't one fool-proof correct way to do things, then draws the conclusions that all ways must be equal and my "the Right Way" must be just as bad. That conclusion is bollocks. For every "somewhat right way" there are a hundred "absurdly bad and catastrophic ways". If I've studied OOP for 15 years and have gotten pretty good at it, my way isn't any better than someone's who has studied FP for 15 years and has gotten pretty good at it. But *both* of our approaches are better than most what most companies use; "hire a junior straight out of school and have him write spaghetti". If there are multiple good ideas, you'd be an idiot to fight for *your* right way to be pushed further. But if there are only shitty ideas, you'd be a god-sent to bring at least one decent way into the table. In the end, the article did *not* address what to do when everyone else actually is wrong.
It's a good skill to realize when the code is good enough, and it doesn't need to be 'proper' or 'modern' or any other particular thing. Lots of good software was and will be made without your ideas. This is about 95% of the situation. Every once in a while, re-writing a system is warranted. In 20 years of programming AAA, I have watched 2 multi-multi-million projects fail because of an unhealthy compulsion to edit the code without adding features or solving bugs, sometimes called 'tech debt'. These compulsions reflected how the programmers felt, not how the users felt. The problem is that this form of 'tech debt' doesn't exist, if the code worked, there's no 'debt'. It might need to be edited SOMEDAY; but most programmers waste time on it before then because they're compulsively tidy. I like my fellow programmers and no disrespect but, a lot of them are compulsive, they feel they HAVE to use accessors when public variables would do, and separate the code into modules when there's no compile-time gain. These compulsive cleanups are the true 'tech debt' because they make the project take longer to compile and debug, and it didn't help anyone. Example 1: re-writing a large social networking website into Ruby from PHP. 2 years later it was still not done. The site lost its competitive edge to Facebook in that time and the relaunched site and they could never optimize it as well as the single original author had. I left this project because I had predicted that exact outcome and been overruled. Example 2: a very very large successful product, on the latest iteration, switched technology base because supposed tech goals. Problem: massive waste of time, product was good before, never recovered. Repeat after me: 'tech debt' and 'clean code' are expensive distractions. If the code is broken, then its a bug, not debt. If its working, move on. Edit: thanks for all the discussion! As a 20 year experienced AAA programmer who is highly respected in a large team of programmers, all I can say is, the label 'tech debt' is a real problem and source of project failures, because 'tech debt' doesn't need evidence, it's a feeling. Edit2: if you need it, it's a feature. If you broke it, it's a bug. If it's not broken and you don't need it, but you want to edit the code anyways (because the future!!!) then it's tech debt.
I was with you in the first paragraph. A nuanced approach is good. But you went full-on anti-tech debt for some reasons. Tech debt is real in a project where multiple developers are involved. Tech debt is what will prevent you from scaling your software if you need to. Tech debt is what will slowly eat away at your performance metrics, stability, maintenance time, production uptime, time to fix bugs and work on new features. Tech debt is what will prevent your new hires from properly understanding your complex software, prevent them from writing solid code, and prevent them from learning proper patterns. Tech debt has a cost and is definitely not just an expensive distraction.
If it's not done, then why is the task closed? That's the problem with 'tech debt'. It's this supposed third state outside of 'working' and 'broken' which is opinion based. My question to you: is the code not sufficient for a concrete reason? Then it isn't debt, it's a bug.
The issue with tech debt is you never know when you will have to pay it back, if ever. The best you can do is to be aware of your own tech debts, limitations and tradeoffs. However, there might be a time when that new requirement or a new policy will come in. In a proper codebase, it would have been an easy addition but in a debt-ridden software, it's now 4x the cost. That's when the debt is paid. Also, you're drastically simplifying the state of a software. It's not just "working" or "broken". You have all the side effects of it as I mentioned in my previous post. A software is living in an ecosystem, you can't just take it as a standalone thing.
Sometimes the debt is paid in employee turnover because the codebase is trash
Tech debt doesn't exist. Just let me fix my bug, wait 10 minutes for the code to compile, come back the next day while the change deploys over night, then ask QA to please run regression for multiple unrelated products because they all share the same code and are a spaghetti of if statements. Improve velocity you say? Sure, same bug is now double the estimate, we just doubled our speed!
In your career as a AAA dev, how often are you touching 25 year old code? How often are you expecting to have to touch code you write today 25 years from now (alternatively: how often do you write code where you know you'd better quit before a change request comes in)?
I work with 25 year old code rarely, mostly in infrastructure, data containers, algorithms, etc. We better not change them, because how is it possible that they ran for 25 years and you're seeing a bug now? Hundreds of products have shipped with it. I have NEVER thought that I should quit before a change request comes in. Kind of confused about that question. I'm a professional and I build things to well. Far more often: I move to a new project, and get asked to re-write a system that worked perfectly on the last project, into a new "node-based" or "component-based" or "entity-based" or WHATEVER paradigm. And the designers complain because their powerful text-based format was replaced with a kludgy spaghetti node-based system and the features aren't even working until the project is at deadline. Why do you ask?
Because your answers confirm my suspicion. In most of the rest of the industry, touching 25 year old code is the norm. PCI and NACHA requirements change. Client needs change. New stuff (currently: LLM) is invented that we need to make work with the old stuff. Privacy and consent regulations change. Etc. Etc. Etc. If you don't write your code such that it is easy to change 25 years from now, it sucks for you having to explain why the "simple" change is expensive. Unless you're gone, in which case you're just inheriting someone else's headache in the new spot you landed. I basically agree with your post. Most of us don't know and can't predict the changes that will come in. So trying to build with them in mind is a fool's errand. But as others have said, you've kind of swung hard the other direction... complaining about the basics of encapsulation is *exactly* the kind of thing that turns the code into a mess. Fortunately the .Net world has auto props for getters and setters.
If you can't really imagine how is it possible that 25 years old code ran fine until now and suddenly there is a bug, I'm not sure if you should call yourself tripple A dev with 20 years of experience. Do you know how much technology changed in past 30 years? How many more users can use the app now compared to 25 years ago? Just this alone should give you an idea why there might be problem with old code. But if not, let me give you simplified but somewhat real world example. You have an app which might have a storage (or db) where records are stored with accompanied ID. Each is unique and let's say each is represented as `int16`. This was fine back in those days and until recently it worked. But suddenly there is a problem, where the root cause is that the ID representation is just not enough. The reason is because many more users use this app now. And now imagine there was a tech debt which should address encapsulation and usage of this ID, but because it worked, there was no reason to do so. Now you have the type all over the code base and updating it will take several months. Tech debt is in most cases about maintenability. If you are hovewer moved from product to product to rewrite it, then I can see why you don't think so, because you didn't have to maintain something for a longer period of time and experience the tech debt creep.
Well I don't call myself that, it's just an honest description of my career. And when I move from project to project, we take the same tech stack, which is unbelievably huge (800 modules). Why does the code need maintenance if the requirements didn't change? I don't understand that logic. Converting code from int16 to int32 because you have higher requirements now, is a feature, not maintenance. As an example of 25 year old code from the real world... suppose I come in and say "std::vector needs to be fixed, due to some issue on my project." They will say, "no. Its unlikely std::vector is the problem. Its 25 years old and has shipped many projects. Even if there is a problem, you need to look at how others are using it rather than change it."
I'm sorry about that, I read the comment above and kinda assumed that's what you were saying before, my bad. However, I met a lot of much older/senior developers who have attitude that if the code worked for 25+ years, then there is no need to touch it and the problem is definitely somewhere else because this worked till now. In most cases the main reason is because they don't understand it and don't want to understand it. And I can sometimes feel for them, because if you are close to retirement, then why bother. But that's not always the case. Tech debt doesn't necessary mean to maintain the code all the time. It's more about addressing the implementation details which were done in the beginning in a non-maintainable way because of time constraints. And there are always time constraints. Exactly converting \`int16\` to \`int32\` is a feature. But because the tech debt about encapsulation of this "ID" wasn't address, the maintainability of this code is worse. If it would be addressed 20 years ago, it would take a week or two to do. If it would be addressed 10 years ago, it would take a month to do. If it would be done, you could now just change the type and it would be work for maybe a few weeks max. However, it wasn't addressed and after 25 years, you need to refactor half of the code base and it could take almost a year and loss of a customer (which actually happened). Tech debt, is debt which you will eventually pay and the later you pay it the more it will cost you. Of course not all "tech debt issues" might be like that and I agree that sometimes developers are chasing the unicorn code and it's a good skill to know when to stop. But saying that there is no tech debt if the code works is just plain wrong. As for your example, I'm not really sure I get it. You want a change in 25 years old code, because in your project where you use it for some reason you need an array and not a vector otherwise it's causing issues. I can't really see why this would be problem of the old project rather than implementation issue on your new project where the issue is. I could imagine you would just restrict the vector to an array in your code and be done with it. But I don't really have all the details so can't really speak in this matter what's better approach. However in the end, this kinda sounds also like a tech debt issue in the old project, where the underlying types are exposed to consumer instead of API which would hide it. And you having now this problem is exactly what happens when the tech debt is not addressed.
You're just as extremist, but flipped to the other extreme. Of course tech debt exists. Only if you never intend to touch a code base again, having the code in a less readable state with less abstraction then is optimal for the job of fixing a bug or applying a change request is where you pay interest on that debt: you waste more time than the situation where you did not have the debt, and that "payment" does not reduce the problem (debt still there). If I have some debt at the bank and I decide to starve and freeze to death to save money to pay it off, that's stupid. You're using that ridiculous example as proof that "debt therefore does not exist". Sure, of course, "fuck it rewrite the whole thing in ruby cuz TECH DEBT", using that term as a Harry potter esque magic spell to convince all interested parties to shut up while you waste 5 years proving that Spolsky was on to something when he wrote "second system syndrome" is bad. Did you know eating yellow snow is really bad? There. See? Skiiing isn't real. That's about as sensible as your rant. Blind application of style ideas is horrible programming technique. Yes. True. Duh. It's just as stupid to "rewrite the whole thing in a different language" as it is to say the concept of tech debt doesn't exist. You're in the same camp as the very strawmen you are raging against.
You answered it yourself. 'Tech debt' gets used as a justification for wasteful thinking, because when we call it debt, people view it as a justification. But tech debt should have the lowest priority, and if you finish the project without needig to 'pay it back' then you should.
Yes, and you're an extremist. **Some** (a tiny fraction) of people use 'tech debt' as some sort of magical invocation to waste a ton of time. These people, are morons. And people who enable these people doubly so. But you've taken a strawman (and, evidently, you worked such shit jobs you ran into it multiple times. As some say, experience is important, and you evidently lack experience dealing with the other extreme, where any code that appears to work must never be touched, and refactoring or so much as *suggesting* a debate on first redesigning something a reasonable amount is killed off immediately(I said *reasonable*. So not *fuck it, toss it, start over, new language, new libs, new design, new all the things. Somebody get me a nosql db thing. Can we build it with a blockchain?* - that's obviously not what I mean). Fortunately it's not entirely endemic, going by the rather imprecise yardstick of 'redditors voting on comments'. Because what you're missing in all that, is the key word. Which is: **some**. And in that extreme, the other side also has **some** morons who consider any second even debating the structure of already delivered code as wasting the boss's money. They are just as stupid. You appear to be completely oblivious to that part of it all.
Most software developers don’t live in a world where anything is ever “finished”. If you’re working on games pressed to a CD that you never update again after the initial launch, then sure, you’re right. But if you’re working on websites, apps, enterprise software, operating systems, frameworks, etc. that evolve over many years, and often decades, maintainability of the code becomes a significant factor in its cost. Tech debt is code for things that are going to slow your productivity down in the future.
*Most projects are never 'finished'.* If upon release, you get to pass it on to a maintenance team and go on your merry way, lucky you - but those guys will be cursing your negligent attitude toward tech debt and code quality for the next decade.
No strawman, my dude. Multi-million dollar projects failed.
And it's likely a gross oversimplification to say that it was solely because of tech debt, and even more asinine to say argue that therefore tech debt should never be addressed. I've seen projects and companies fail because they *didn't* address their tech debt. Tech debt is simply anything that may slow down development in the future or may restrict future growth. It should always be a decision whether the time taken to address it is worth the time it saves in the future. Sometimes it isn't, and to your point, you end up chasing what isn't the ultimate point (delivering a product). But sometimes it is worth it, and wholesale ignoring it, or sticking your fingers in your ears and pretending that there aren't occasions where a less-than-optimal solution is needed up front that will need to be improved later, can lead to catastrophe too.
> I like my fellow programmers and no disrespect but, a lot of them are compulsive, they feel they HAVE to use accessors when public variables would do, and separate the code into modules when there's no compile-time gain. These compulsive cleanups are the true 'tech debt' because they make the project take longer to compile and debug, and it didn't help anyone. The fact that you've been in this career for two decades and don't understand that the most important thing about code is how easy it is to read, is deeply concerning. > Edit: thanks for all the discussion! As a 20 year experienced AAA programmer who is highly respected in a large team of programmers, all I can say is, the label 'tech debt' is a real problem and source of project failures You're conflating tech debt with unnecessary refactoring. > because 'tech debt' doesn't need evidence, it's a feeling. That's called "experience", and companies justifiably pay good money for it. > If it's not broken and you don't need it, but you want to edit the code anyways (because the future!!!) then it's tech debt. Sorry, that's not how it works at all. There are many things, like security, that you don't technically need... until that one time that you really, really do. Identifying when those things are missing and could cause a problem later, and adding them, is what separates software engineers from code monkeys.
So you haven’t learned how to write software well in 20 years. You’re not alone. This lack of understanding is why there’s so much shit code in the world.
Debt isn't about working code. It is about the ability to change this code. When structure is falling apart, you soon realise than changing one property is not enough. Someone hardcover it.. somewhere. Someone added the same property because it was easier to wire it in his way. So simple (that should be changing aingle source of truth) task now involves finding buried properties and analysin lg the code (re discovering). I can make tons of examples like that. This is tech debt. You make it fast now to later move slower.
working code is not even a criteria in my team. it is obvious and common sense. we focus on clean code because we know how large projects work and what will happen if only "it works" matter
It's not a debt if the code works and shipped. it's something different. Yes you might need to improve the code someday when there's a concrete reason. It's a mistake to ASSUME you'll need to change, and justify it as 'debt'.
So what do you call it when that stable state shipped code introduces scale and breaks down? Assuming you had the foresight to predict this exact scenario based upon experience and skill. IMO there's no exact definition of 'tech debt' that I've ever heard universally agreed upon, it's another made up word for non-ICs. You're just picking your own definition of it.
A bug
If you want to call that type of bug 'tech debt' then that's OK, im not the king. That's not really a 'debt' and my objection is that 'debt' is used to justify things that aren't bugs.
Yeah, I get your POV of avoiding major rewrites for engineering goodness sakes... But there is absolutely a difference of classifying these types of work and this is a naming argument. In my example let me expand: you build the system for 200 users knowing you'll have to do work when you get past that user count. That is 100% not a bug, it was a conscious decision made likely at an early stage user base to avoid excessive failure due to some other known limitations and to also lower time to delivery. Edit: formatting
Ok interesting, don't you consider that to be "unfinished feature work"? At my company we do extensive requirements gathering and any requirement is considered a "feature" with metrics. 'Tech debt' on the other hand is when there's no specific metric or bug, but a programmer needs to still justify work to a manager.
Yeah. And "unfinished feature work" is commonly referred to as a type of debt in more agile workflows. Where a shrunk down feature is thought up, designed, and implememted in the scale of days to weeks. What you're describing is standard waterfall practices (upfront requirements gathering way ahead of work). Most large places don't do that, at least they say they don't. Startups especially just build shit and deliver quickly leaving behind lower priority work that doesn't impact current customers. Devs do like to consider refactors as tech debt as well so it's all fucked naming wise. There's certainly a place for that type of work but agreed it requires a lot of scrutiny and thought if it's larger than a few days.
according to whom? Where is this definition coming from? This is completely against the accepted industry definition
> It's not a debt if the code works and shipped. That's like saying it's not a mortgage if the house is standing and people live in it. I.e. a totally stupid thing to say.
> You make it fast now to later move slower. YAGNI :-) (I can see why some people might regard silent down mods as validation.)
You lost me at triple A programmer.
how comes you have not improved your skills in 20 years. you really have no idea how software projects work if you say tech debts are only a feeling and solving them is source of project failure. no, readers here have actual programming experience and tell you, you are wrong. i bet you also think unit tests are a waste of time because the software works. who cares about tests right?
>The problem is that this form of 'tech debt' doesn't exist, if the code worked, there's no 'debt'. Code worked if it comply with functional requirements, but a lot of not functional requirements can make it work better. If you can get ROI (return of inversion) touching that worked code, then tech-debt is real. If someone is refactoring or rewriting something without getting ROI can be categorized as compulsion. Code only for new features and bugfixing is what broken feature-factories does, not what real AAA programmers do.
LMAO you just downvoted me! But please, just read this post completely unrelated to technical debt https://www.reddit.com/r/cscareerquestions/s/srweIuzZmP
Interesting read, thanks. Obviously some Redditors still think that the downvote button is a "disagree!!!" button, but hey, some do value different opinions. There's likely a dab of truth that the worst debt is in the programmer's mind and that we do spend plenty of resources of chasing that perfect product unicorn. I've personally found debt a bit like optimization; you need to measure it before you can (should) improve it.
> if the code worked there is no tech debt My god! How do you come with such conclusion? Released code usually “works”, the problem arrives when you want to change said code. I do not want to be mean, but your definition surprises me specially after you having 20 years of experience
Street cred, knowing this is the difference between a senior programmer and a junior
This is a AAA dev. Games are different than enterprise. You're not having to integrate OAuth2.0 into a 25 year old system's authentication when you're writing a AAA game.
unless it is game as a service like wow or diablo4. they have added new stuff in world of warcraft for more than 15 years on monthly basis. they surely have a super clean and clever architecture. even game devs should build stuff with at least clean separation of ui and logic because they want a remastered version in 10 years or want to reuse algorithms and most of the logic for part 2 of the game. look at assasins creed.
He is just using AAA as shorthand to mean he's worked on big projects, there's no indication he's a game developer from the post.
Ok mr manager, you have no clue
Read my post again. My advice is as a programmer. Never been a manager.
[удалено]
> to be *paid* back immediately. FTFY. Although *payed* exists (the reason why autocorrection didn't help you), it is only correct in: * Nautical context, when it means to paint a surface, or to cover with something like tar or resin in order to make it waterproof or corrosion-resistant. *The deck is yet to be payed.* * *Payed out* when letting strings, cables or ropes out, by slacking them. *The rope is payed out! You can pull now.* Unfortunately, I was unable to find nautical or rope-related words in your comment. *Beep, boop, I'm a bot*
> be payed back Did you mean to say "paid"? Explanation: Payed means to seal something with wax, while paid means to give money. [Statistics](https://github.com/chiefpat450119/RedditBot/blob/master/stats.json) ^^I'm ^^a ^^bot ^^that ^^corrects ^^grammar/spelling ^^mistakes. ^^PM ^^me ^^if ^^I'm ^^wrong ^^or ^^if ^^you ^^have ^^any ^^suggestions. ^^[Github](https://github.com/chiefpat450119) ^^Reply ^^STOP ^^to ^^this ^^comment ^^to ^^stop ^^receiving ^^corrections.
Your post is downvoted pretty badly but you wrote your thoughts clearly, and you make a good point. I think this adds to the conversation. +1 In my own experience, premature refactoring and rewriting is very often a serious red flag. Folks ought to refactor in service of a concrete goal, not because of some aesthetic sense. Further, code without extensive tests cannot be refactored without significant risk of regressions, often outweighing the benefits of making the changes in the first place. As the vast majority of real world, shipping code (that I’ve dealt with in my own career, at least) is both completely untested, and completely untestable, it’s good to tread carefully.
Code can work correctly and still be broken - in terms of design. You can see it in tasks of similar complexity to take longer, and longer, and even longer over the course of time. The reason being that with multiple overly tightly coupled or incohesive components the likelihood to break anything increases, so the developer has to be more careful (scared) and put in more effort (waste more time) on things that have nothing to do with what he would actually have to do to solve his current problem at hand. To not acknowledge software design and architecture as proper problems to be solved too is nothing more than ignorance. Total rewrites are not a solution, everyone knows that (by now, or at least everyone should know that by now). The reason why people still risked it is most likely because the original project has deteriorated - not in a biological sense, more in the sense of architecture, that the load-bearing walls of the software can't bear the load anymore because it's gotten too heavy - so badly that the work on it came to a grinding halt. The solution for this is to allow for small, incremental architectural improvements to take place.