5 ms·

To me, that's what the author is saying with "ugly code survives." You have an ugly 20k line codebase that survives because you can't touch it without breaking

To me, that's what the author is saying with "ugly code survives." You have an ugly 20k line codebase that survives because you can't touch it without breaking something.

ams6110 8y ago
And you have it because the elegant, abstracted version exceeded the developer's ability to comprehend.
- wild_preference 8y ago
  In my experience, ugly code is more a product of churn (like moving target business requirements) than incompetence. You may have started with a nice abstraction for one case, but you don't have time to reabstract every step of the way.
  - ams6110 8y ago
    Yes, it can be, but that has not been the only reason in my experience. Smart developers can see the abstractions and organize their code accordingly. Mediocre/poor developers just think about what needs to get done. They will copy code that seems to do something similar and hack on it until it works. I saw this a lot with asp pages back in the day. An entire application, that actually worked and was well liked by its users, was implemented as hundreds of totally stand-alone .asp files. When a new page was needed, the developer copied an old one and modified it. That made it pretty easy to add new features without breaking old ones, but made it very difficult to make cross-cutting changes such as changing the name or type of a field on multiple pages, changing page headers, changing database connections (yes, they were also duplicated in every file) etc. This is also how you end up with a "20k line VB.Net disaster." They are created by developers who know just enough to make something work, but don't know about abstraction and modularization or aren't smart enough or experienced enough to see the abstractions and to keep track of what's going on when the code is split out over a dozen files or modules. Or possibly, just don't care.
    - reidjs 8y ago
      Perhaps a lot of bad code comes from strict time requirements, loose specs, and employee churn. Your customers and your manager/supervisor couldn’t care less about how neat your code is, so I understand the logic to push out something that works ASAP. I personally try my best to write clean code, but I don’t call other developers ‘stupid’ given the reality of ridiculous timelines and low job security.
      - pdimitar 8y ago
        I agree with you but would just add one more nuance: there's a critical minimum of "so-so-okay-ish code" that we should never go below of. The problem with untouchable huge turd piles is borne out of going below that bar. I totally get the low job security and low payment and the "I don't care" parts and have written bad code because of all of those. Still, if you put even a minimal effort, it pays off.
    - smolder 8y ago
      While there are lots of examples out in the wild of people making a mess of things due to lack of experience, hastiness, and not thinking long term, there is a two way street there. Experienced developers sometimes apply too many rules and too rigidly to deliver elegant, well-performing, timely solutions. I see people abstracting and decoupling things, applying highly generalized pessimistic patterns, bickering about how to name things that probably shouldn't even exist, let alone have explicit names. Experience is obviously good but people tend to get inflexible and dogmatic, too.
    - wild_preference 8y ago
      Abstraction isn't free, either. The more you build, the more you're gambling that it abstracts over all future requirements. When you're eventually wrong, someone must pay the incredibly expensive price of deabstraction. Which can become so untenable that it makes more sense to escape-latch out of it for a new business requirement. If you disagree, then shrink the deadline until you do. What happens with technical debt is that every new/changed feature incurs disproportional costs. And all costs, at the end of the day, boil down into time. Even the best developer has the same finite resource of time as everyone else, and they are stuck choosing between the best of suboptimal solutions once bounded by deadlines. This is why, when encountering a mess of a codebase, it's naive to conclude "wow, what a bunch of amateurs." And that's exactly what I thought at my first job out of university. Eventually I realized that software is just hard and there is never enough time. The more experienced you get, the better you are at writing code that can be changed or thrown away. But you're still only minimizing the bad, not eliminating the bad, so on a long enough time scale with enough monkey wrenches of time constraints and requirement churn, technical debt is inevitable.
  - jnurmine 8y ago
    Any nontrivial component, which today does whatever its job is today, but is very brittle and resistant to change and is centrally located in the overall system architecture/structure, certainly can become tomorrow's untouchable 20 k LOC VB.net script. Having something like that is like a pressure point for business risk. A small nudge here, and the whole shaky house of cards violently implodes ejecting all kinds of badness, monetary and otherwise, over those around it. And it is not just the bad component, it is the overall system design which permits this and does not support change within the system ("modifiability", "extensibility", ...). Point: it is not as easy as saying "oh, this is because of that incompetent asshat". The incompetent asshattery is a systemic phenomenon with many actors. Death by a thousand small bad choices; the 20 LOC of untouchable code is just a manifestation of the bigger problems.
jgalentine007 8y ago
It seemed to me that the author was advocating for ugly code. If that wasn't his intention, then he didn't do a very good job of expressing it - the title of the article is 'against software development'. But rather than spend any more time talking about bad code, I'm going to go now and try and write some good code.
- jrochkind1 8y ago
  I think he's advocating (with a "grain of salt") for _minimizing_ software development, because it's so hard to keep it from turning terrible. If we could spend more time on less of it, maybe we could keep it better. I don't think he's advocating for ugly code.
  - jgalentine007 8y ago
    That makes more sense, thanks. RIP my reading comprehension.
gmfawcett 8y ago
This idea is very well explored in the classic article, "Big Ball of Mud" by Foote and Yoder: http://laputan.org/mud/ http://laputan.org/mud/

To me, that's what the author is saying with "ugly code survives." You have an ugly 20k line codebase that survives because you can't touch it without breaking something.

ams6110 8y ago

And you have it because the elegant, abstracted version exceeded the developer's ability to comprehend.

wild_preference 8y ago
In my experience, ugly code is more a product of churn (like moving target business requirements) than incompetence. You may have started with a nice abstraction for one case, but you don't have time to reabstract every step of the way.
- ams6110 8y ago
  Yes, it can be, but that has not been the only reason in my experience. Smart developers can see the abstractions and organize their code accordingly. Mediocre/poor developers just think about what needs to get done. They will copy code that seems to do something similar and hack on it until it works. I saw this a lot with asp pages back in the day. An entire application, that actually worked and was well liked by its users, was implemented as hundreds of totally stand-alone .asp files. When a new page was needed, the developer copied an old one and modified it. That made it pretty easy to add new features without breaking old ones, but made it very difficult to make cross-cutting changes such as changing the name or type of a field on multiple pages, changing page headers, changing database connections (yes, they were also duplicated in every file) etc. This is also how you end up with a "20k line VB.Net disaster." They are created by developers who know just enough to make something work, but don't know about abstraction and modularization or aren't smart enough or experienced enough to see the abstractions and to keep track of what's going on when the code is split out over a dozen files or modules. Or possibly, just don't care.
  - reidjs 8y ago
    Perhaps a lot of bad code comes from strict time requirements, loose specs, and employee churn. Your customers and your manager/supervisor couldn’t care less about how neat your code is, so I understand the logic to push out something that works ASAP. I personally try my best to write clean code, but I don’t call other developers ‘stupid’ given the reality of ridiculous timelines and low job security.
    - pdimitar 8y ago
      I agree with you but would just add one more nuance: there's a critical minimum of "so-so-okay-ish code" that we should never go below of. The problem with untouchable huge turd piles is borne out of going below that bar. I totally get the low job security and low payment and the "I don't care" parts and have written bad code because of all of those. Still, if you put even a minimal effort, it pays off.
  - smolder 8y ago
    While there are lots of examples out in the wild of people making a mess of things due to lack of experience, hastiness, and not thinking long term, there is a two way street there. Experienced developers sometimes apply too many rules and too rigidly to deliver elegant, well-performing, timely solutions. I see people abstracting and decoupling things, applying highly generalized pessimistic patterns, bickering about how to name things that probably shouldn't even exist, let alone have explicit names. Experience is obviously good but people tend to get inflexible and dogmatic, too.
  - wild_preference 8y ago
    Abstraction isn't free, either. The more you build, the more you're gambling that it abstracts over all future requirements. When you're eventually wrong, someone must pay the incredibly expensive price of deabstraction. Which can become so untenable that it makes more sense to escape-latch out of it for a new business requirement. If you disagree, then shrink the deadline until you do. What happens with technical debt is that every new/changed feature incurs disproportional costs. And all costs, at the end of the day, boil down into time. Even the best developer has the same finite resource of time as everyone else, and they are stuck choosing between the best of suboptimal solutions once bounded by deadlines. This is why, when encountering a mess of a codebase, it's naive to conclude "wow, what a bunch of amateurs." And that's exactly what I thought at my first job out of university. Eventually I realized that software is just hard and there is never enough time. The more experienced you get, the better you are at writing code that can be changed or thrown away. But you're still only minimizing the bad, not eliminating the bad, so on a long enough time scale with enough monkey wrenches of time constraints and requirement churn, technical debt is inevitable.
- jnurmine 8y ago
  Any nontrivial component, which today does whatever its job is today, but is very brittle and resistant to change and is centrally located in the overall system architecture/structure, certainly can become tomorrow's untouchable 20 k LOC VB.net script. Having something like that is like a pressure point for business risk. A small nudge here, and the whole shaky house of cards violently implodes ejecting all kinds of badness, monetary and otherwise, over those around it. And it is not just the bad component, it is the overall system design which permits this and does not support change within the system ("modifiability", "extensibility", ...). Point: it is not as easy as saying "oh, this is because of that incompetent asshat". The incompetent asshattery is a systemic phenomenon with many actors. Death by a thousand small bad choices; the 20 LOC of untouchable code is just a manifestation of the bigger problems.

jgalentine007 8y ago

It seemed to me that the author was advocating for ugly code. If that wasn't his intention, then he didn't do a very good job of expressing it - the title of the article is 'against software development'. But rather than spend any more time talking about bad code, I'm going to go now and try and write some good code.

jrochkind1 8y ago
I think he's advocating (with a "grain of salt") for _minimizing_ software development, because it's so hard to keep it from turning terrible. If we could spend more time on less of it, maybe we could keep it better. I don't think he's advocating for ugly code.
- jgalentine007 8y ago
  That makes more sense, thanks. RIP my reading comprehension.

gmfawcett 8y ago

This idea is very well explored in the classic article, "Big Ball of Mud" by Foote and Yoder: http://laputan.org/mud/ http://laputan.org/mud/