6 ms·

Sorry but there's no excuse for crap code. If it's hard to understand then time is lost every time you have to work with it. You shouldn't defend it by trying

Sorry but there's no excuse for crap code. If it's hard to understand then time is lost every time you have to work with it. You shouldn't defend it by trying to assign positive attributes to it (its effecient. ...yeah). Maybe there's nothing good about bad code and we should use being called out on it as an opportunity for improvement. No, lets double down on our delusions of superiority by telling ourselves that crap we wrote is somehow effecient in some way. Im tired of it. Its not effecient. Its bad and you should feel bad.

dionian 7y ago
Often true, but often 'beautiful code' does not impact the bottom line - even in the long term.
- afpx 7y ago
  It does if it’s a requirement for keeping employees from quitting.
  - vkou 7y ago
    I can't imagine quitting because the code I work on sucks. It's not like I'm getting paid by the feature I ship. If it takes 20 hours to ship an 8-hour feature, it doesn't matter, I still get the same paycheque every two weeks. My job is to show up, and work with the situation that exists. I can, however, imagine quitting if my manager is a shitty person. People don't quit work - they quit managers.
    - wpietri 7y ago
      I think this is a fine attitude in the short term, and an absolutely terrible one in the long. It's certainly bad for the business; companies that (by your numbers) are happy paying 150% extra in costs will have a hard time competing over time with companies that keep their costs low. But I think it's also bad for the developer. Giving up and accepting bad code and low productivity means we develop habits and attitudes appropriate to that environment. It keeps us from getting better at our jobs, from keeping up with new technologies and new approaches. And given how our industry keeps changing, I think that's a recipe for disaster.
      - deleted 7y ago
        [deleted]
      - vkou 7y ago
        > It's certainly bad for the business; companies that (by your numbers) are happy paying 150% extra in costs will have a hard time competing over time with companies that keep their costs low. If most of my income derived from being an owner of a company, I would care deeply about this problem. Since it doesn't, its really no sweat off my back, either way. > It keeps us from getting better at our jobs, from keeping up with new technologies and new approaches. In my experience, tech churn is one of the top reasons for why code has gone to shit. "It's been three years since the last re-write, let's rebuild the product again, in a framework that nobody here knows how to use!" On the bright side, both the re-write, and the cleanup of the resulting mess means steady employment.
        wpietri 7y ago
        > Since it doesn't, its really no sweat off my back, either way. Again, only in the short term. A failing company is not a fun place to be, and a failed one even worse. And if you end up with a resume that has a long string of losers as your employers, it's going to get harder to get good jobs.
        vkou 7y ago
        Do you think so? If you do, and you hire people, you should seriously consider not thinking in that way. Any manager who can put two and two together should be well aware that the impact that an average IC has on the success of a failing company that's bigger than 100 people is near-zero. It's just pedigree snobbery, to look at a resume, and go: "Oh, well, he worked for losers, he must be a loser, reject."
    - smabie 7y ago
      So would you work the rest of your life before retirement to dig a hole and then fill it up again, over and over. Let’s say you get to make 10x whatever you are earning now. Oh, and, the manager is a nice guy, he gives you lemonade and stuff on breaks.
      - vkou 7y ago
        Sure. Most people do exactly that for a living. I don't let my 9-5 define my life. It means I'll retire in two years, and be able to work for a cause that I deeply care about - or, better yet, for myself. A better thought experiment is to ask yourself how many of your co-workers will come in tomorrow, if all your code became the most beautiful code ever written, with rainbows, and unicorns... but on the flipside, that they stopped receiving paycheques.
- pizzaparty2 7y ago
  I agree, beautiful code is often the other extreme. Plus it's often only beautiful to the person that wrote it.
  - soup10 7y ago
    Code that is easy to work with is usually that way because the author went out of their way to make it easy to work with, often this takes 2-3x as long to write as normal code that just works. Publicly exposed api's typically get this special attention and internal things get the normal spaghetti treatment.
  - xpe 7y ago
    > Plus it's often only beautiful to the person that wrote it. From what I've seen, this may be true in some particular cases, but this is not a general pattern. I've found that beauty, in software (as in art and design in general) very often has common elements. People certainly have different preferences in how the elements are put together, but I think many people can appreciate the underlying principles. Here are some examples of the principles behind beauty in software: * A component obeying the principle of least surprise * A function having a clear purpose * A function using a small (perhaps minimum) number of arguments for its purpose * A codebase cleanly separating concerns * A codebase reusing standard components * A codebase having appropriate documentation suited to the team working with it * A codebase having good testability * An algorithm (e.g., one based on a published paper) solving a problem by doing less work * A function having fewer lines of code None of these are absolute. (For example, the last two may sometimes exist in tension with one other.) I see the concept of beauty as relative to a set of goals and values. Beauty almost always often involves a sense of balance and proportion: trading-off principles that are not perfectly orthogonal. Of course, there are different perspectives on how to achieve a particular balance for a particular situation. I'd like to add an unsupported claim (that I happen to believe, given a set of mostly rational people working together in a healthy work environment): If you get these people together and say "is codebase X beautiful for purpose Y?" I think you'll find a lot of consensus. In areas where they disagree, I think the resulting discussion will likely be constructive. I would bet that the discussion will lead to a better design in the end -- as perceived by the participants. This assumes that the people learn from each other; e.g. proponents who tend to favor one principle are willing to listen to proponents of other principles.
TeMPOraL 7y ago
When applying this article to code, I don't think it has anything to do with spaghetti being good. It could be viewed instead as an argument against "architecture astronautics", the "15 layers of abstraction to print 'hello world'" school of software design.
- wpietri 7y ago
  Exactly. I remember being called into consult on an accounting system for microfinance; the target audience was small to medium-sized. The code had an absurd amount of layering; one path I traced copied the data 8 times from fetch to render, each time into a different set of objects that had basically the same fields, but that were conceptually different. When I asked about this, I was told it was "best practice" and that if they ever needed to scale, there were now many places they could separate things. I pointed out that for the target audience, they probably wouldn't need to scale. But that if they did, it would be because they were doing 7x the work necessary. The code was certainly "tidy" from the perspective of the guy who got paid a lot of money to produce architecture diagrams. But it was a nightmare from the perspective of an individual programmer trying to add a feature. They would have been way better off without a lot of quasi-religious design theory slowing them down.
  - TeMPOraL 7y ago
    I used to write code like that - architecting whole application up front, creating layers upon layers of abstractions. Experience taught me to do the reverse now - start with the simplest version that works, keep going until writing code gets tough, and then switch to whiteboard and use what I learned along the way to design a proper solution (and if any part of the design process starts getting tough, I switch back to writing the simplest thing that works). Rinse, repeat. It's not about rushing to release barely working pile of spaghetti, but recognizing that programming is an exploratory activity, and you don't know enough to do complete design up front. And really, it turns out most of the time that not only you don't need the complex abstractions designed early on, you actually need a set of different ones. That's why keeping the design process continuously grounded in reality is important. My solution for not producing spaghetti code with this method? I don't release the first version that works. I don't mark the ticket as "done", and I don't even push it out of my local repo. Instead, I clean it, or even straight up rewrite it, until it reaches a sleek and acceptably elegant state. It's the responsibility of a programmer to decide when the code is ready, and it doesn't have to be at the first moment it passes all the tests.
matthewaveryusa 7y ago
I disagree with such a blanket statement. Interfaces must remain simple, while implementations are free to be as complex as needed. Take a look at this article -- clearly the SIMD code is dense to get through, but it's very-much-so worth it for the performance gains. https://lemire.me/blog/2017/01/20/how-quickly-can-you-remove-spaces-from-a-string/ https://lemire.me/blog/2017/01/20/how-quickly-can-you-remove...
- chrisweekly 7y ago
  "Interfaces must remain simple, while implementations are free to be as complex as needed." IOW, local complexity in exchange for global simplicity is often a good tradeoff.
- smabie 7y ago
  What you’re talking about is the MIT school vs New Jersey school. See Richard Gabriel’s essay: Worse is Better. http://dreamsongs.com/WorseIsBetter.html http://dreamsongs.com/WorseIsBetter.html
andy_ppp 7y ago
I actually think having business people who have control over what programmers do is the mistake very often. It leads to very bad decisions for the codebase as a whole and the programmers often don’t know the best way to fit in the random business needs because they are never told why the feature should exist. I think we need a better method to be able to make the right decisions for the code while still achieving the desired outcomes without making quite such a mess. Maybe something like sessions where the business has to persuade the developers to build the features in detail rather than throwing random unclear solutions over the fence and saying we need this.
- BlueTemplar 7y ago
  Huh, the part about software developers having to understand client's needs and work with them is what I've been taught. I'm guessing that in big enough companies, management starts to mess with processes that they should not touch?
uulu 7y ago
Strange, how did you come to the conclusion that this is a defense of "crap code"? For one thing - crappy code is most often less efficient than elegant code.
- dimino 7y ago
  The example of the child being asked to clean his room reminds me a great deal of a bad engineer being asked to clean up his code.
  - chubbyrabbit 7y ago
    "His room" and "his code" is not comparable in the context. "His code" is part of a business's product and can impact the livelihood of many people involved in the product including customers. "His room" is a private space that doesn't affect other people. I don't tell my co-worker to clean up his side-project on github.
    - dimino 7y ago
      You could tell your coworker (or your direct report if we're taking this analogy seriously) to clean up his work area. A child's room isn't a completely private space, and it's where they do their "work" (getting dressed, homework, play time, etc.).
detaro 7y ago
There is no globally applicable standard for what's crap code, so there's plenty of reason to excuse code some people might label "crap". "Don't write crap code" is a terribly empty statement. Trying to "tidy up" "crap code" is also a great way to screw things up further if you turn out to be wrong about it.
mewpmewp2 7y ago
What about a mvp scenario? Many successful businesses have crap legacy code, but maybe they would not have been able to become successful ever had they not rushed with the code? Are you saying taking tech debt is never good? To me it seems like a failure to take a look at the bigger picture. In the end it is all about the value provided. You are creating a start up that has 10 percent chance of succeeding and only if it gets to market fast. Also it is never binary. It is always time invested vs quality of the code. It is a spectrum. From what point can you call code crap? The closer you get to perfect code the more time it takes to get it better as you are closing near perfect.
cryptozeus 7y ago
Agree but this can also become subjective very quickly. Oh this code is crap according to “me” so lets re write it the way “I” think is better without understanding why it was written that way to begin with. If you apply this article to code then I would say it argues that find out the reason before just removing it.
MaxBarraclough 7y ago
> its effecient. ...yeah > Im tired of it. Its not effecient. Its bad and you should feel bad. You're ignoring that sometimes, measurably more efficient code is less readable, possibly much less readable. If this weren't the case, there'd be no such thing as sophisticated data-structures and algorithms. This doesn't mean anyone should make an uncommented ball of mud with no comments, of course. > No, lets double down on our delusions of superiority by telling ourselves that crap we wrote is somehow effecient in some way. The usual wisdom about efficient code, answers this: if you aren't measuring performance, that means you don't really care about performance. If you're going to great efforts, and writing less readable code, on the hunch that this is more efficient, then sure, you're doing it wrong.
mc3 7y ago
Yes using the 'city' analogy - the 'city' might be the entire of the AWS stack, where as the 'building' might be what is produced by the 2-pizza team. And the code produce by that team (like the building) should be tidy as much as possible, except where there is a genuine need to get performance and that requires making things a bit messy.
jerf 7y ago
Most of the reasons why code is hard to understand will be on a fairly small scale. It is possible to yank that out and replace it, while honoring and respecting any underlying chaotic organization that may have occurred despite the crap quality of the code. (As the article says, this sort of chaotic adaptation requires flexibility and crap code only inhibits that.) That's pretty much what I've done in this last calendar year, taken two messy systems chaotically (in this article's sense) interfaced with the rest of the company, and upgraded them. I gave them new, hopefully-non-crap code, certainly better documented code, documentation on the system structure, better operational deployment, massive upgrades to security, general speed improvements, and in one case, a fundamental architectural change at the most foundational level even though the surface that the users interacted with hardly appeared to change. And yet... despite all that, I would not say I "rewrote them from scratch", because I did not simply start with a blank sheet of paper and start scribbling what I think the ideal solution would be. I took the underlying adaptations, respected them, assumed that they likely had a reason even if I didn't know what they were, and built systems that largely dropped into place on top of the old ones rather than being totally foreign bodies that cause cascading requirements for other systems to also be significantly rewritten. If, in the future, those other systems do get rewritten, I even have some paths prepared (but not yet written) in the code for true architectural upgrades to occur in the future. But in the meantime, I have improved systems that work now. It's a much better approach to replacing a system that denying the chaotic adaptations. Even "crap code" can be mined for them, and they are not generally the crappiness itself.
cookiecaper 7y ago
Code, at least the way we currently write it, is a fundamentally lossy transfer. The coder has the context in their head; they understand what's happening up to that point, what they want to happen now, and what needs to happen later. Writing code is translating those concepts and ideas into a specialized step-by-step list of machine instructions. In the course of writing the concepts in a dumbed-down format for an instruction machine, context is inevitably lost. You can say "write comments" until you're blue in the face, but it doesn't solve the problem. Then, someone new comes along, and they don't understand the context, they never knew anything about it before, and you quit 8 months ago. This person must infer the context and determine an accurate conception of the context from the pieces left behind. The approach taken when one finds themselves in that position is one of the key tells of their skill and experience IMO. Regardless, it seems that if the software got out of the loose demo/messing around phase, it deserves at least some consideration before it's dismissed out of hand as "bad code".
- jeroennoels 7y ago
  Upvoted. See also: "Programming as theory building" by Peter Naur.
jariel 7y ago
The article does not imply that chaos is inherently good or efficient. When I look at big, 'good', codebases, I'm always amazed at how much complexity there is at every level, and wonder why it can't all just be clean and orderly. The trade off between performance, bureaucratic code and leaky abstractions seems to be ever-present. I can never make an API 'fit' that elusive ideal of what it should be, there are always bits of dangling weirdness. Try for example doing anything in Unicode; it's as though there are permanent grey areas and ambiguities. There's always the corner case that someone, somewhere in some corner of the world will either break it, or be without the ability to 'spell their name' or whatever. I don't think this is about arbitrarily crap code.
Forge36 7y ago
I'm a big fan of design two systems. If timelines permit, ship the second, else ship the first. The first code will almost always be crap code because it takes designing the system to better see how the system should have been designed. Problems arise when the first system gets left in place for too long. It starts to grow developers sometimes whole teams arise, and many people ask why, but are too afraid to touch it
GuB-42 7y ago
The more I code, the more I like messiness. By that I don't mean bad code. I mean code where all techniques in and out of books are used together. For example, a mix of exception and error returns, direct access to class members combined with accessors, etc... I like to see best practice rules being broken when there is a good reason for that. Rule of the thumb: good code is short code. If your "tidying up" makes the code longer, then it is probably better to leave it as it is. What you are going to do is most likely add useless layers of abstraction or try make it abide by some made-up rule that shouldn't apply here. As for "efficient" code. Most efficient code I see is actually quite good and readable. The worst code I see usually gives no fucks to efficiency. At least premature optimizers show some love to their code.

dionian 7y ago

Often true, but often 'beautiful code' does not impact the bottom line - even in the long term.

afpx 7y ago
It does if it’s a requirement for keeping employees from quitting.
- vkou 7y ago
  I can't imagine quitting because the code I work on sucks. It's not like I'm getting paid by the feature I ship. If it takes 20 hours to ship an 8-hour feature, it doesn't matter, I still get the same paycheque every two weeks. My job is to show up, and work with the situation that exists. I can, however, imagine quitting if my manager is a shitty person. People don't quit work - they quit managers.
  - wpietri 7y ago
    I think this is a fine attitude in the short term, and an absolutely terrible one in the long. It's certainly bad for the business; companies that (by your numbers) are happy paying 150% extra in costs will have a hard time competing over time with companies that keep their costs low. But I think it's also bad for the developer. Giving up and accepting bad code and low productivity means we develop habits and attitudes appropriate to that environment. It keeps us from getting better at our jobs, from keeping up with new technologies and new approaches. And given how our industry keeps changing, I think that's a recipe for disaster.
    - deleted 7y ago
      [deleted]
    - vkou 7y ago
      > It's certainly bad for the business; companies that (by your numbers) are happy paying 150% extra in costs will have a hard time competing over time with companies that keep their costs low. If most of my income derived from being an owner of a company, I would care deeply about this problem. Since it doesn't, its really no sweat off my back, either way. > It keeps us from getting better at our jobs, from keeping up with new technologies and new approaches. In my experience, tech churn is one of the top reasons for why code has gone to shit. "It's been three years since the last re-write, let's rebuild the product again, in a framework that nobody here knows how to use!" On the bright side, both the re-write, and the cleanup of the resulting mess means steady employment.
      - wpietri 7y ago
        > Since it doesn't, its really no sweat off my back, either way. Again, only in the short term. A failing company is not a fun place to be, and a failed one even worse. And if you end up with a resume that has a long string of losers as your employers, it's going to get harder to get good jobs.
        vkou 7y ago
        Do you think so? If you do, and you hire people, you should seriously consider not thinking in that way. Any manager who can put two and two together should be well aware that the impact that an average IC has on the success of a failing company that's bigger than 100 people is near-zero. It's just pedigree snobbery, to look at a resume, and go: "Oh, well, he worked for losers, he must be a loser, reject."
  - smabie 7y ago
    So would you work the rest of your life before retirement to dig a hole and then fill it up again, over and over. Let’s say you get to make 10x whatever you are earning now. Oh, and, the manager is a nice guy, he gives you lemonade and stuff on breaks.
    - vkou 7y ago
      Sure. Most people do exactly that for a living. I don't let my 9-5 define my life. It means I'll retire in two years, and be able to work for a cause that I deeply care about - or, better yet, for myself. A better thought experiment is to ask yourself how many of your co-workers will come in tomorrow, if all your code became the most beautiful code ever written, with rainbows, and unicorns... but on the flipside, that they stopped receiving paycheques.
pizzaparty2 7y ago
I agree, beautiful code is often the other extreme. Plus it's often only beautiful to the person that wrote it.
- soup10 7y ago
  Code that is easy to work with is usually that way because the author went out of their way to make it easy to work with, often this takes 2-3x as long to write as normal code that just works. Publicly exposed api's typically get this special attention and internal things get the normal spaghetti treatment.
- xpe 7y ago
  > Plus it's often only beautiful to the person that wrote it. From what I've seen, this may be true in some particular cases, but this is not a general pattern. I've found that beauty, in software (as in art and design in general) very often has common elements. People certainly have different preferences in how the elements are put together, but I think many people can appreciate the underlying principles. Here are some examples of the principles behind beauty in software: * A component obeying the principle of least surprise * A function having a clear purpose * A function using a small (perhaps minimum) number of arguments for its purpose * A codebase cleanly separating concerns * A codebase reusing standard components * A codebase having appropriate documentation suited to the team working with it * A codebase having good testability * An algorithm (e.g., one based on a published paper) solving a problem by doing less work * A function having fewer lines of code None of these are absolute. (For example, the last two may sometimes exist in tension with one other.) I see the concept of beauty as relative to a set of goals and values. Beauty almost always often involves a sense of balance and proportion: trading-off principles that are not perfectly orthogonal. Of course, there are different perspectives on how to achieve a particular balance for a particular situation. I'd like to add an unsupported claim (that I happen to believe, given a set of mostly rational people working together in a healthy work environment): If you get these people together and say "is codebase X beautiful for purpose Y?" I think you'll find a lot of consensus. In areas where they disagree, I think the resulting discussion will likely be constructive. I would bet that the discussion will lead to a better design in the end -- as perceived by the participants. This assumes that the people learn from each other; e.g. proponents who tend to favor one principle are willing to listen to proponents of other principles.

TeMPOraL 7y ago

When applying this article to code, I don't think it has anything to do with spaghetti being good. It could be viewed instead as an argument against "architecture astronautics", the "15 layers of abstraction to print 'hello world'" school of software design.

wpietri 7y ago
Exactly. I remember being called into consult on an accounting system for microfinance; the target audience was small to medium-sized. The code had an absurd amount of layering; one path I traced copied the data 8 times from fetch to render, each time into a different set of objects that had basically the same fields, but that were conceptually different. When I asked about this, I was told it was "best practice" and that if they ever needed to scale, there were now many places they could separate things. I pointed out that for the target audience, they probably wouldn't need to scale. But that if they did, it would be because they were doing 7x the work necessary. The code was certainly "tidy" from the perspective of the guy who got paid a lot of money to produce architecture diagrams. But it was a nightmare from the perspective of an individual programmer trying to add a feature. They would have been way better off without a lot of quasi-religious design theory slowing them down.
- TeMPOraL 7y ago
  I used to write code like that - architecting whole application up front, creating layers upon layers of abstractions. Experience taught me to do the reverse now - start with the simplest version that works, keep going until writing code gets tough, and then switch to whiteboard and use what I learned along the way to design a proper solution (and if any part of the design process starts getting tough, I switch back to writing the simplest thing that works). Rinse, repeat. It's not about rushing to release barely working pile of spaghetti, but recognizing that programming is an exploratory activity, and you don't know enough to do complete design up front. And really, it turns out most of the time that not only you don't need the complex abstractions designed early on, you actually need a set of different ones. That's why keeping the design process continuously grounded in reality is important. My solution for not producing spaghetti code with this method? I don't release the first version that works. I don't mark the ticket as "done", and I don't even push it out of my local repo. Instead, I clean it, or even straight up rewrite it, until it reaches a sleek and acceptably elegant state. It's the responsibility of a programmer to decide when the code is ready, and it doesn't have to be at the first moment it passes all the tests.

matthewaveryusa 7y ago

I disagree with such a blanket statement. Interfaces must remain simple, while implementations are free to be as complex as needed. Take a look at this article -- clearly the SIMD code is dense to get through, but it's very-much-so worth it for the performance gains. https://lemire.me/blog/2017/01/20/how-quickly-can-you-remove-spaces-from-a-string/ https://lemire.me/blog/2017/01/20/how-quickly-can-you-remove...

chrisweekly 7y ago
"Interfaces must remain simple, while implementations are free to be as complex as needed." IOW, local complexity in exchange for global simplicity is often a good tradeoff.
smabie 7y ago
What you’re talking about is the MIT school vs New Jersey school. See Richard Gabriel’s essay: Worse is Better. http://dreamsongs.com/WorseIsBetter.html http://dreamsongs.com/WorseIsBetter.html

andy_ppp 7y ago

I actually think having business people who have control over what programmers do is the mistake very often. It leads to very bad decisions for the codebase as a whole and the programmers often don’t know the best way to fit in the random business needs because they are never told why the feature should exist. I think we need a better method to be able to make the right decisions for the code while still achieving the desired outcomes without making quite such a mess. Maybe something like sessions where the business has to persuade the developers to build the features in detail rather than throwing random unclear solutions over the fence and saying we need this.

BlueTemplar 7y ago
Huh, the part about software developers having to understand client's needs and work with them is what I've been taught. I'm guessing that in big enough companies, management starts to mess with processes that they should not touch?

uulu 7y ago

Strange, how did you come to the conclusion that this is a defense of "crap code"? For one thing - crappy code is most often less efficient than elegant code.

dimino 7y ago
The example of the child being asked to clean his room reminds me a great deal of a bad engineer being asked to clean up his code.
- chubbyrabbit 7y ago
  "His room" and "his code" is not comparable in the context. "His code" is part of a business's product and can impact the livelihood of many people involved in the product including customers. "His room" is a private space that doesn't affect other people. I don't tell my co-worker to clean up his side-project on github.
  - dimino 7y ago
    You could tell your coworker (or your direct report if we're taking this analogy seriously) to clean up his work area. A child's room isn't a completely private space, and it's where they do their "work" (getting dressed, homework, play time, etc.).

detaro 7y ago

There is no globally applicable standard for what's crap code, so there's plenty of reason to excuse code some people might label "crap". "Don't write crap code" is a terribly empty statement. Trying to "tidy up" "crap code" is also a great way to screw things up further if you turn out to be wrong about it.

mewpmewp2 7y ago

What about a mvp scenario? Many successful businesses have crap legacy code, but maybe they would not have been able to become successful ever had they not rushed with the code? Are you saying taking tech debt is never good? To me it seems like a failure to take a look at the bigger picture. In the end it is all about the value provided. You are creating a start up that has 10 percent chance of succeeding and only if it gets to market fast. Also it is never binary. It is always time invested vs quality of the code. It is a spectrum. From what point can you call code crap? The closer you get to perfect code the more time it takes to get it better as you are closing near perfect.

cryptozeus 7y ago

Agree but this can also become subjective very quickly. Oh this code is crap according to “me” so lets re write it the way “I” think is better without understanding why it was written that way to begin with. If you apply this article to code then I would say it argues that find out the reason before just removing it.

MaxBarraclough 7y ago

> its effecient. ...yeah > Im tired of it. Its not effecient. Its bad and you should feel bad. You're ignoring that sometimes, measurably more efficient code is less readable, possibly much less readable. If this weren't the case, there'd be no such thing as sophisticated data-structures and algorithms. This doesn't mean anyone should make an uncommented ball of mud with no comments, of course. > No, lets double down on our delusions of superiority by telling ourselves that crap we wrote is somehow effecient in some way. The usual wisdom about efficient code, answers this: if you aren't measuring performance, that means you don't really care about performance. If you're going to great efforts, and writing less readable code, on the hunch that this is more efficient, then sure, you're doing it wrong.

mc3 7y ago

Yes using the 'city' analogy - the 'city' might be the entire of the AWS stack, where as the 'building' might be what is produced by the 2-pizza team. And the code produce by that team (like the building) should be tidy as much as possible, except where there is a genuine need to get performance and that requires making things a bit messy.

jerf 7y ago

Most of the reasons why code is hard to understand will be on a fairly small scale. It is possible to yank that out and replace it, while honoring and respecting any underlying chaotic organization that may have occurred despite the crap quality of the code. (As the article says, this sort of chaotic adaptation requires flexibility and crap code only inhibits that.) That's pretty much what I've done in this last calendar year, taken two messy systems chaotically (in this article's sense) interfaced with the rest of the company, and upgraded them. I gave them new, hopefully-non-crap code, certainly better documented code, documentation on the system structure, better operational deployment, massive upgrades to security, general speed improvements, and in one case, a fundamental architectural change at the most foundational level even though the surface that the users interacted with hardly appeared to change. And yet... despite all that, I would not say I "rewrote them from scratch", because I did not simply start with a blank sheet of paper and start scribbling what I think the ideal solution would be. I took the underlying adaptations, respected them, assumed that they likely had a reason even if I didn't know what they were, and built systems that largely dropped into place on top of the old ones rather than being totally foreign bodies that cause cascading requirements for other systems to also be significantly rewritten. If, in the future, those other systems do get rewritten, I even have some paths prepared (but not yet written) in the code for true architectural upgrades to occur in the future. But in the meantime, I have improved systems that work now. It's a much better approach to replacing a system that denying the chaotic adaptations. Even "crap code" can be mined for them, and they are not generally the crappiness itself.

cookiecaper 7y ago

Code, at least the way we currently write it, is a fundamentally lossy transfer. The coder has the context in their head; they understand what's happening up to that point, what they want to happen now, and what needs to happen later. Writing code is translating those concepts and ideas into a specialized step-by-step list of machine instructions. In the course of writing the concepts in a dumbed-down format for an instruction machine, context is inevitably lost. You can say "write comments" until you're blue in the face, but it doesn't solve the problem. Then, someone new comes along, and they don't understand the context, they never knew anything about it before, and you quit 8 months ago. This person must infer the context and determine an accurate conception of the context from the pieces left behind. The approach taken when one finds themselves in that position is one of the key tells of their skill and experience IMO. Regardless, it seems that if the software got out of the loose demo/messing around phase, it deserves at least some consideration before it's dismissed out of hand as "bad code".

jeroennoels 7y ago
Upvoted. See also: "Programming as theory building" by Peter Naur.

jariel 7y ago

The article does not imply that chaos is inherently good or efficient. When I look at big, 'good', codebases, I'm always amazed at how much complexity there is at every level, and wonder why it can't all just be clean and orderly. The trade off between performance, bureaucratic code and leaky abstractions seems to be ever-present. I can never make an API 'fit' that elusive ideal of what it should be, there are always bits of dangling weirdness. Try for example doing anything in Unicode; it's as though there are permanent grey areas and ambiguities. There's always the corner case that someone, somewhere in some corner of the world will either break it, or be without the ability to 'spell their name' or whatever. I don't think this is about arbitrarily crap code.

Forge36 7y ago

I'm a big fan of design two systems. If timelines permit, ship the second, else ship the first. The first code will almost always be crap code because it takes designing the system to better see how the system should have been designed. Problems arise when the first system gets left in place for too long. It starts to grow developers sometimes whole teams arise, and many people ask why, but are too afraid to touch it

GuB-42 7y ago

The more I code, the more I like messiness. By that I don't mean bad code. I mean code where all techniques in and out of books are used together. For example, a mix of exception and error returns, direct access to class members combined with accessors, etc... I like to see best practice rules being broken when there is a good reason for that. Rule of the thumb: good code is short code. If your "tidying up" makes the code longer, then it is probably better to leave it as it is. What you are going to do is most likely add useless layers of abstraction or try make it abide by some made-up rule that shouldn't apply here. As for "efficient" code. Most efficient code I see is actually quite good and readable. The worst code I see usually gives no fucks to efficiency. At least premature optimizers show some love to their code.