4 ms·

I've seen this way, way more often and with far worse overall cost than any kind of perfectionism. I'm not intending to be some sort of advocate of purportedly

I've seen this way, way more often and with far worse overall cost than any kind of perfectionism. I'm not intending to be some sort of advocate of purportedly bad code, but I find the quoted section to be an interesting statement because, if true (and it likely is true), it simply reinforces the notion that ugly, pragmatic projects endure and succeed: You've seen "way, way more" of that sort because they deliver actual value and end up providing an actual solution for the world, while perfectionists are still busy arguing over trivia. This is the survivorship bias at play. Organizations accumulate "technical debt" because the only code that gives that any assets has such realistic downsides. And while you account for the cost, you say absolutely nothing about the benefit/"earnings", which is a typical analysis of people who work on other people's code. I have created a lot of terrible code in my career, almost always doing greenfield development. This was code that was spun out under incredible conditions, where we had no idea what our product was going to be, the parameters of the data or the conditions that it would be used in, etc. We had changing dev environments and assumptions, libraries getting tossed and new ones added, etc. And those projects built companies. And it was always novel hearing someone ranting about technical debt years later, when they were hired in a position and on a team and in a company that only continued to exist because of that solution. Debt indeed.

mattmanser 13y ago
I've worked with good code and bad code. Where there was good code, programmer turnover was low and the original programmers were still around. Where there was bad code, turnover was high and the original coders were long gone, the impression I often got was they'd coded themselves into a corner and it was too much for them. I honestly think places with bad code just have to keep burning out more and more programmers until someone good enough to dig them out of the hole comes along. The most successful company had the worst code written by incredibly incompetent programmers who didn't even know basic things. One of their products the programmer was so clueless he'd created a new project and DLL for every single class. Every single class. Still made millions. There are very few coders who can write and design a large product from scratch. Hence far more bad code than good. I think that's the more likely explanation.
- romaniv 13y ago
  Your post has many implied dichotomies and correlations that simply aren't true. For example: I find the quoted section to be an interesting statement because, if true (and it likely is true), it simply reinforces the notion that ugly, pragmatic projects endure and succeed Not really. It simply shows that bad software is commonplace and often not important enough factor to kill an entire company. It still costs companies a fortune in maintenance, client dissatisfaction and employee turnover rates. You've seen "way, way more" of that sort because they deliver actual value and end up providing an actual solution for the world Uh, again, no. Bad code often begets bad UI, confusing process for the users, botched transactions and a never-ending stream of database tweaks and patches. I've seen plenty of projects whose overall value to the company was negative. Problem is, that negative was spread throughout large period of time, whereas a proper update or replacement of the system would be concentrated in a much shorter time span. This is where "debt" analogy works very well. Some code is like that credit card you maxed out, but only have enough money to do minimum payments. I have created a lot of terrible code in my career, almost always doing greenfield development. Whether you created horrible code is largely irrelevant. What's important is what is your overall trend. Some developers pull the code quality up over time, and them maintain it at some reasonable level after that. Others slowly turn anything they touch into radioactive waste.
  - corresation 13y ago
    FYI - You replied to the wrong post. I'll just leave it at this -- despite protestations to the contrary, I would wager that the majority of developers, if not the overwhelming majority of developers, claim to do no wrong when coding. They claim to plan and design and develop with best practices, creating clean, maintainable code. And those same developers almost universally declare the majority of code they come in contact with to be toxic waste. Terrible code that brings down companies and kills careers (this whole hilarious discussion began with someone lamenting about the code that Notch burdened Mojang with. The code that is the sole reason for that company existing. What a horrible burden). These claims do not mesh. At all. There is a reality that is profoundly different from what people say.

mattmanser 13y ago

I've worked with good code and bad code. Where there was good code, programmer turnover was low and the original programmers were still around. Where there was bad code, turnover was high and the original coders were long gone, the impression I often got was they'd coded themselves into a corner and it was too much for them. I honestly think places with bad code just have to keep burning out more and more programmers until someone good enough to dig them out of the hole comes along. The most successful company had the worst code written by incredibly incompetent programmers who didn't even know basic things. One of their products the programmer was so clueless he'd created a new project and DLL for every single class. Every single class. Still made millions. There are very few coders who can write and design a large product from scratch. Hence far more bad code than good. I think that's the more likely explanation.

romaniv 13y ago
Your post has many implied dichotomies and correlations that simply aren't true. For example: I find the quoted section to be an interesting statement because, if true (and it likely is true), it simply reinforces the notion that ugly, pragmatic projects endure and succeed Not really. It simply shows that bad software is commonplace and often not important enough factor to kill an entire company. It still costs companies a fortune in maintenance, client dissatisfaction and employee turnover rates. You've seen "way, way more" of that sort because they deliver actual value and end up providing an actual solution for the world Uh, again, no. Bad code often begets bad UI, confusing process for the users, botched transactions and a never-ending stream of database tweaks and patches. I've seen plenty of projects whose overall value to the company was negative. Problem is, that negative was spread throughout large period of time, whereas a proper update or replacement of the system would be concentrated in a much shorter time span. This is where "debt" analogy works very well. Some code is like that credit card you maxed out, but only have enough money to do minimum payments. I have created a lot of terrible code in my career, almost always doing greenfield development. Whether you created horrible code is largely irrelevant. What's important is what is your overall trend. Some developers pull the code quality up over time, and them maintain it at some reasonable level after that. Others slowly turn anything they touch into radioactive waste.
- corresation 13y ago
  FYI - You replied to the wrong post. I'll just leave it at this -- despite protestations to the contrary, I would wager that the majority of developers, if not the overwhelming majority of developers, claim to do no wrong when coding. They claim to plan and design and develop with best practices, creating clean, maintainable code. And those same developers almost universally declare the majority of code they come in contact with to be toxic waste. Terrible code that brings down companies and kills careers (this whole hilarious discussion began with someone lamenting about the code that Notch burdened Mojang with. The code that is the sole reason for that company existing. What a horrible burden). These claims do not mesh. At all. There is a reality that is profoundly different from what people say.