4 ms·

Agreed - nobody is arguing that throwing together sloppy code is always a good thing. Mostly I'm just saying that some amount of sloppy code isn't necessary a

Agreed - nobody is arguing that throwing together sloppy code is always a good thing. Mostly I'm just saying that some amount of sloppy code isn't necessary a bad thing. Like you say, the amount of sloppy code that you can get away with depends on what you are doing. There are vast discussions about this both online and in books, referring to "sloppy code" as "technical debt". Just like monetary debt, sometimes it is worth taking on a significant debt, while there are other times that it is best to avoid debt. It's a judgement call either way, and I've found that I tend to err on the side of being too scared of technical debt.

romaniv 13y ago
Software engineers have an unfortunate tendency to accumulate technical debt and then run away from paying it. I've seen this way, way more often and with far worse overall cost than any kind of perfectionism. The dichotomy between quality and speed of development is often an illusion anyway.
- willismichael 13y ago
  I find it fascinating that elsewhere on this thread somebody expressed the opinion that "overengineering ... kills more projects than anything else" and here you express the opinion that a much worse problem is engineers bailing out after running up technical debt. To be honest, I really can't say which is worse, I've had to cope with both of them from other people. All I can say is that my tendency is to overengineer.
  - romaniv 13y ago
    Like I said, I think it's a false dichotomy. Most over-engineered projects I've seen also had ridiculously sloppy code. Over-engineering usually concerns design. Sloppy coding usually concerns implementation. The code at a different stage of development, so it's possible to have both or neither.
- corresation 13y ago
  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.
    - 13y ago

romaniv 13y ago

Software engineers have an unfortunate tendency to accumulate technical debt and then run away from paying it. I've seen this way, way more often and with far worse overall cost than any kind of perfectionism. The dichotomy between quality and speed of development is often an illusion anyway.

willismichael 13y ago
I find it fascinating that elsewhere on this thread somebody expressed the opinion that "overengineering ... kills more projects than anything else" and here you express the opinion that a much worse problem is engineers bailing out after running up technical debt. To be honest, I really can't say which is worse, I've had to cope with both of them from other people. All I can say is that my tendency is to overengineer.
- romaniv 13y ago
  Like I said, I think it's a false dichotomy. Most over-engineered projects I've seen also had ridiculously sloppy code. Over-engineering usually concerns design. Sloppy coding usually concerns implementation. The code at a different stage of development, so it's possible to have both or neither.
corresation 13y ago
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.
  - 13y ago