15 ms·

Against software development

244 points by octosphere 8y ago

amelius 8y ago
> Beautiful code gets rewritten; ugly code survives. Also: GPL code gets rewritten, BSD/MIT code survives.
- wiz21c 8y ago
  statistics ?
  - beatgammit 8y ago
    I don't have any, but I've rewritten my fair share of GPL code so I could use it both at work and personal projects. I've started using MPL for my projects recently because (L)GPL is just too restrictive.
    - jcelerier 8y ago
      too restrictive for whom ? as a potential user of your software, can I have the guarantee that if I buy a device with your software on it, I can replace it / fix it ?
      - zzzcpan 8y ago
        You are not asking all the questions though. What about buying a device that connects to a remote service running that software underneath? GPL won't protect you from such anti-user behavior. It's perfectly fine with depriving users of their freedoms this way. So (A)GPL is not restrictive enough either.
    - wiz21c 8y ago
      The GPL has some deeply political implications and it doesn't fit everyone's views. That's why people don't like the GPL, because it doesn't fit their view. But as far as its goals are concerned, I think the GPL achieve them very well. (I have the opposite experience, in the beginning I just used the GPL because it seemed fine, but thatnks to some real life experience, I came to realize how my own political views are embodied in it and how wrong I'd feel producing code that it's not GPL) (I don't say the GPL is perfect here, but it's way better than the MIT license for me)
- ken 8y ago
  Huh? Where's the BSD rewrite of Emacs? Is Linux not surviving? Are Hg and Git? GPL programs are category-killers.
  - epicide 8y ago
    It only matters if you're redistributing it. So, libraries not tools. Given the choice between two otherwise similar frameworks/libraries, I would expect most to gravitate towards the non-GPL'd one since there is less friction. i.e. you don't even have to consider things like the GPL linking rules.
    - ken 8y ago
      Are people not redistributing Linux? This seems like an awfully thin hair to split.
      - epicide 8y ago
        I'm not trying to say everything exactly falls into one category or the other. There was a wide sweeping statement about a set that I believe to be generally true for one subset [0] and it was refuted with cherry-picked examples from a disjoint subset. [0]: Of a significant size.
    - klez 8y ago
      But that's exactly the point, isn't it? [a bit oversimplified] You want to use this GPL library? Great! Just release your own software as GPL! It's not complicated, per se, it's just that some people/business are not ok with that condition (which is their prerogative).
      - epicide 8y ago
        > it's just that some people/business are not ok with that condition The point is that if people/businesses are not okay with using it, then that hurts the survival of that thing.
- tannhaeuser 8y ago
  I hope we could bury that old discussion in the 90s. It's just holding us back from tackling today's challenges. Like, do you want to contribute to the ongoing centralization of information? Because if you're publishing your blog on FB (medium.com I don't know), or releasing your software on GitHub, then you're excluding indie search crawlers from access. You maybe shouldn't link to content silos that block non-UA agents (except GoogleBot and Bing) at all, because why would you contribute to non-reciprocal sites that are ruining the 'net?
claydavisss 8y ago
> Refuse to work on systems that profit from digital addictions. > Refuse to work on systems that centralize control of media. > Refuse to work on systems that prop up an unjust status quo. > Refuse to work on systems that require unsustainable tradeoffs. > Refuse to work on systems that weaponize the fabric of society. Rich people can afford to turn their nose up at any kind of work apparently. Also noteworthy that the internet was invented as a result of "weaponizing"...so put that phone down. Oddly enough all of this also invalidates working on most open source code, since the OSI says a license should not discriminate against intended use
- empath75 8y ago
  I think one can simply refuse to work on code that adapts the open source code towards nefarious ends. A screwdriver can build a pipebomb, but surely the person using the screwdriver is more culpable than the person who built the screwdriver.
  - claydavisss 8y ago
    Define "nefarious end". This is why the OSI guidelines are correct to stay out of the tarpit of value judgements. Edit: BTW This is another reason OSI does not discriminate against intended use...to protect otherwise rational people from behaviors like you see on HN...blind downvoting and no responses HN is becoming incredibly anti-intellectual, bordering on reddit
    - wffurr 8y ago
      A good start is anything that works contrary to the Universal Declaration of Human Rights: http://www.un.org/en/universal-declaration-human-rights/ http://www.un.org/en/universal-declaration-human-rights/ How about acting in a way so as to not cause others to suffer or impede their search for happiness? The Dalai Lama makes a case for this as a universal ethic in his Ethics for a New Millennium. Calling making any kind of value judgement a "tarpit" is itself a value judgement in favor of the status quo and ceding any of your own culpability to others.
empath75 8y ago
Given how hot the market is for software developers right now, there's really no excuse to be working on ethically questionable products.
- twoquestions 8y ago
  Even not-great software developers who live in poor areas need to eat.
- probably_wrong 8y ago
  I would be cautious about generalisations like that. Sometimes the good jobs are where you aren't. Sometimes the good jobs won't return your calls. Sometimes you have to choose between your morals and your wife, deportation, debt, or all together.
  - ed312 8y ago
    Can you really say you have morals if you sacrifice nothing for them? Are they not merely preferences at that point?
    - IggleSniggle 8y ago
      Participation in community at some level is necessary, and, depending on your morals, may be a moral imperative even when your morals disagree with the products of the community with which you interact. Is it easier to promote change in a community from within or from the outside?
    - deleted 8y ago
      [deleted]
    - probably_wrong 8y ago
      It's a tricky question. I agree that often morals involve making though choices. At the same time, those choices have to balance the magnitude of the evil, the consequences of sticking to your morals, and the consequences of just going with it. To give a concrete example: let's say I have to choose between unemployment and working in a casino (assuming I believe casinos to be evil). I can work there and do nothing. I can work there and donate an X amount of my salary to addiction-recovery ONGs. I can refuse to work there and compromise my (hypothetical) children's well-being. Which one of this is the "moral" choice? I can't say. And I'm willing to bet that you can make a moral argument for each one of those. I'm with you in that sticking to your morals often involve sacrifice. But I wouldn't assume that the weights I add to each aspect of my morals are the same as everybody else's.
alexandercrohde 8y ago
There's something mildly "ranty" about this, to its own detriment. I believe what it is is that it seems to try to connect ideas that have no logical connection, but simply an emotional association. For example, what is the connection between "Beautiful code gets rewritten" and "Refuse to work on systems that profit from digital addictions." ? It comes across as though the author is just vaguely angry at the loose concept of software. It's true that the software ecosystem is incredibly disorganized and inefficient (100s of similar distros, dozens of similar package managers, thousands of redundant tools). But I don't think one should get bent out-of-shape about it. If you think about it objectively, if it were efficient then most of us likely wouldn't have jobs.
- OnlyRepliesToBS 8y ago
  a rant about someone ranting
- jgalentine007 8y ago
  Yeah, I wonder how many 'just works' codebases he/she has had to spar with. It usually ends in tears. I have a 20k line VB.Net disaster that can't be changed without side effects because of the use of global variables, basically needing a whole rethink/rewrite. At least with some beautiful code the author might have put some thought into it beyond what is directly in front of them.
  - phalangion 8y ago
    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.
      - 8y ago
crawfordcomeaux 8y ago
> To those who have a choice: If I think this doesn't apply to me because I don't have a choice, I'm disempowering myself. My choices may be hard to make, but abducted women still try to flee. We know because of the ones who escape. If I think others don't have a choice, I'm disempowering them. I choose to believe we everyone can learn to become more empowered and stand up to those they've been giving power to.
- SketchySeaBeast 8y ago
  That line of thinking can end at victim blaming - the abducted women stayed abducted because she didn't try to run hard enough. That's putting the blame on the wrong person. That being said, many devs CAN make the choice, but I don't think it's fair to blame those who can't. Not everywhere is booming to the same amount, and not everyone's life experience is the same to allow them freedom to move to an area that is.
  - crawfordcomeaux 8y ago
    I'm not assigning blame. I'm choosing who I want as a role model. Blame is nonsense black-and-white thinking. There is shared responsibility in everything. I share in the responsibility of all things that occur after I take my next breath. Abandon blame and it's possible to read what I wrote without finding anything wrong with it.
    - SketchySeaBeast 8y ago
      Without framing it in blame then, if one fails even though they are empowered, what is the implications?
      - davemp 8y ago
        There are two classes of implications that come to me easily. 1) There is a possibility that the empowered person did not make the decision(s) that would have resulted in success. Maybe there was no decision chain leading to success. Good luck deciding. 2) The environment that caused failure, could be poorly optimized to minimize failure over a set of empowered persons. Maybe it is optimized and the individuals paths to success couldn't be increased. Good luck determining this, optimization of complex functions is not easy. The classes are not mutually exclusive. Ignoring the individual's actions (the first class) seems like a poor approach to reducing net failures. These lines of reasoning always remind me of a quote (from an admittedly cheesy source) that I think holds a useful sentiment. "There's always someone who'll try to convince you that they know the answer no matter the question. Be wary of those who believe in a neat little world because it's just fucking crazy, you know that it is." --DMB (I am not accusing the parent of being a person of which to be wary, their comments seem very reasonable).
quotemstr 8y ago
Whiplash. The first two sections are about generic software development truisms; from there, for the last section, the author pivots to arguing for his specific political positions, as if universal truths of software development justify these ideas. Is the author expect to convince anyone who doesn't already agree with him?
- rntz 8y ago
  > Is the author expect to convince anyone who doesn't already agree with him? Not really. If I wanted to convince skeptics, I would have to make it much longer and more precise, and then it be a very different kind of thing. Maybe I'll do that some other day. The connections between the sections are fairly obscure, I admit. But I think many "universal truths of software development" are instances of more general problems to do with collective decision-making and local optimisation processes, which also produce the problems the last section mentions. I don't have a solution, but in the meantime I'd like to avoid making things worse.
vegetablepotpie 8y ago
The only time I haven't seen shabby code with caked on layers of features has been when I had the fortune of working on a development team that was trained to write software. I've seen new languages and new development methodologies introduced to try to combat code complexity and the only thing I have seen so far that prevents it are people who take a step back and think about what they're creating before implementing it. These people are rare and go unrewarded for their efforts.
- jmarchello 8y ago
  This is so true. There is a lost art of software architecture and design.
  - folkrav 8y ago
    Shit software architecture/design is nothing new. There always was shit code, and always will be. The sky is blue.
- deleted 8y ago
  [deleted]
- lotyrin 8y ago
  I've been wandering from job to job looking for these folks to learn from and have failed so far. Nobody seems to be able to think even two steps ahead, often fail to think one step ahead sufficiently to answer "why" questions about their current task.
vmchale 8y ago
> generic code is replaced by its concrete instances, which are faster If you're using a shitty compiler, yes.
- jstimpfle 8y ago
  By that standard I seem to know only shitty compilers. Sorry to be blunt but you don't have a clue. As a rule of thumb, compilers can make a 10x difference (for example in machine code performance). Programmers can easily make a 1000x difference. Not even looking at algorithmic improvements.
- coldtea 8y ago
  http://wiki.c2.com/?SufficientlySmartCompiler http://wiki.c2.com/?SufficientlySmartCompiler
  - wild_preference 8y ago
    They're referring to monomorphization. Rust, for example: > You might be wondering whether there is a runtime cost when you’re using generic type parameters. The good news is that Rust implements generics in such a way that your code doesn’t run any slower using generic types than it would with concrete types. > Rust accomplishes this by performing monomorphization of the code that is using generics at compile time. Monomorphization is the process of turning generic code into specific code by filling in the concrete types that are used when compiled.
    - jstimpfle 8y ago
      Where do you get that monomorphization reference from? Let's assume for example you have a generic hash map where you just plug the type in, which must be hashable. Now if you plug in an integer type, monomorphization or whatever fancy compilation techniques will make that faster. But the best way to map an integer range is still a plain array. To put it in simple terms, compilers can make shit run faster, but they can't make it not shit.
      - 8y ago
beat 8y ago
I've been meaning to give a lightning talk about a related subject someday, called "Why Software Sucks". Basically, software hovers along the fuzzy line between "barely works" and "doesn't work". When we start a project, it doesn't work. We add code until it barely works. Then we break it, so it doesn't work. So we add enough scaffold that it barely works and can support the new features, until we break it again, and the cycle begins anew. This is actually embedded as principle in TSTTCPW (the simplest thing that could possibly work), but attempts to waterfall our way out by careful planning are generally doomed, due to unintended consequences and such. Eventually, the software becomes broken and no longer worth fixing (and thus gets abandoned), or it hits feature complete while (barely) working. And what happens when it's "complete"? Do we say "Thank goodness, finally I can go fix all those bugs and design flaws!"? No, never. Instead, we drop that blecherous losing piece of crap as fast as we can and go start on the shiny new project that's been cooking in our minds, the one we couldn't work on because we were hacking our way through the wretched ball of mud that is our old code, wasting time in frustration and shame, just to get it off our plate. So we start working on the shiny new thing. And this time, the code will be good. This time, it won't suck. Yeah, right.
- cntlzw 8y ago
  A lightning talk I would love to attend.
- fjsolwmv 8y ago
  The whole world hovers between barely works and doesn't work. That's the theory of evolution that explains the history of life.
  - gglitch 8y ago
    Nice observation. I would enjoy a Tao of System Design that coyly smiles and says, The architecture that can be defined is not the true architecture.
    - gmfawcett 8y ago
      It's not nearly as pithy, but I think that this line from "Big Ball of Mud" captured something essential: > "Architecture is a hypothesis about the future that holds that subsequent change will be confined to that part of the design space encompassed by that architecture." http://laputan.org/mud/mud.html#Forces http://laputan.org/mud/mud.html#Forces
niftich 8y ago
The purpose of software is to teach a machine perform tasks, even when many of those tasks are to show an interface so that a human can perform a task. Design is nontrivial, but computers are powerful, so we can layer on abstractions to ease the understandability and modularity of the code. This is a creative process that's part engineering, part art: some people choose to take proven components and techniques and apply them in predictable ways, while some choose to experiment with new techniques, and some up with novel solutions. But any tradeoff has a cost, and future maintainers may not appreciate a solution whose meaty details aren't obvious. While the creation of software may be a part-creative process, its maintenance is purely pragmatic: fixes to unforeseen problems need to be delivered quickly above all else, and enhancements along all extension points need to be possible, not just along axes the original authors intended. It's not hard to see that elegant code might be under immense pressure from more pragmatic modifications, any one of which can endanger its status in the eye of a beholder. This is likely why this article's author sees 'ugly' code survive: presumably, small changes are sufficient to make beautiful code ugly, while already-ugly code faces no such aesthetic pressure.
jackcosgrove 8y ago
The author makes some good points about the ethical dubiousness of a lot of software jobs. But I think the author misses the biggest point. Software replaces people with machines and increases capital's share of income. I have heard technology is the biggest driver of growing inequality, and at this point in history technological change is driven by software. I think the old nostrums about creative destruction and labor saving technologies freeing up labor to pursue higher roles are true in the aggregate, but the aggregate obscures a lot of human wreckage left behind by people who were laid off and never rehired at a comparable level. I consider this process inevitable which is why I am trying to get ahead of it. But that's a fundamentally selfish motivation no matter how much you gussy it up. Being honest about this is one thing that keeps my aspirations modest - I simply want to carve out a place for myself where I feel comfortable. I think buying into the creative destruction rhetoric makes it easier to harden your heart.
deleted 8y ago
[deleted]
crazygringo 8y ago
> Beautiful code gets rewritten; ugly code survives. Ever stop to think that maybe this is a good thing? That code doesn't exist to be beautiful -- code exists to get the job done. Beautiful doesn't mean it's not also useless or arbitrary or over-architected, while ugly can be a healthy balance of competing priorities -- maybe not clean, but a good series of necessary real-world compromises. This isn't to defend all (or even most) ugly code as good... but that equating beauty with good comes across as terribly naive.
- erikpukinskis 8y ago
  They didn't say it was a bad thing. Just that it's what happens. I've noticed lately that people seem to assume that if you say something negative, you're trying to make a big existential claim about its place in the universe. Like when people criticize masculinity and then we are all aghast as if they said masculinity needs to be systematically extracted from all aspects of culture. I'm not sure which side of the equation needs to be more careful though. Maybe, in the internet age with the globe as your audience, if people are criticizing things they need to add a bunch of caveats to make it clear what they're not saying.
  - crazygringo 8y ago
    The first sentence literally calls it the "tragedy of software engineering". I don't think I'm making an unwarranted assumption that the author means it's a bad thing.
- yourbandsucks 8y ago
  Not to mention, often times the business requirements themselves are ugly. Ugly but clear is the lowest possible distance between code and purpose. I've spent so many hours obscuring the true purpose of chunks of code just so it can hit some zealous reviewers checklist of patterns they like..
- rntz 8y ago
  "Getting the job done" is a short-term goal that often comes at the expense of long-term well-being. For example, the endless parade of backward compatibility layers on top of backward compatibility layers. Each got the job done at the time. And each makes it just a little bit harder for future programmers to get their jobs done. I think a sense of beauty can let us know that something is amiss with the bigger picture. It can provoke us into stepping back and ask: what is actually necessary? Which jobs really need doing, and at what cost? Certainly, short-termism is not the only failure mode when writing software. Abstraction for abstraction's sake is another.
blueadept111 8y ago
>Software grows until it exceeds our capacity to understand it. This point is well taken, and I think that many organization would benefit from having a CGR role ("chief grim reaper"), who's job would be not to enhance the codebase or its functionality, but to do the opposite: to kill/simplify code and prevent the codebase from exceeding a certain net complexity over time. Simplicity itself need to be treated as a core feature, and the success of the CGR need to be defined by whether that core feature is maintained.
- opwieurposiu 8y ago
  Wow that is a really good idea. Unless a specific individual is in charge of something it will never get done. I am going to propose this to my team.
miguelrochefort 8y ago
Can someone point out to projets or initiatives that are attempting to solve the problems mentioned by the writer of this article? I can't stand the unnecessary complexity, fragmentation and duplication in software. The entire industry is a mess. Very few people seem to care.
erikpukinskis 8y ago
I only wish it was longer.
dkarl 8y ago
Just so, generic code is replaced by its concrete instances, which are faster and (at first) easier to comprehend. Just so, extensible code gets extended and shimmed and customized until under its own sheer weight it collapses, then replaced by a monolith that Just Works. aesthetics alone keep us from the hell Beware of comparing "beautiful" code to subsequent code that deals with 10x the complexity in requirements. Either it's beautiful because it's perfectly suited to the scale and complexity it was written for, in which case it's impossible to preserve that beauty in the later, more complex code, or it's "beautiful" because it has a bunch of premature abstractions built in that somebody fantasized would handle all future complexity, in which case the "beauty" was useless work that later programmers had to undo. When the supposed genericity and extensibility of a system doesn't survive the evolution of the system to meet subsequent requirements, my first suspicion is premature abstraction, not insufficiently tasteful programmers. Even worse, the effort to dismantle this "beauty" is often considerable. Architecture, defined as the set of decisions that are costly to change, needs to anticipate the drastically different needs of the future. You rarely find architecture within the code of a single system early in its development, because code at that stage should be easy to rewrite. Code seen as "beautiful" by its author often violates this rule, creating architecture where architecture shouldn't exist.

244 points by octosphere 8y ago

amelius 8y ago

> Beautiful code gets rewritten; ugly code survives. Also: GPL code gets rewritten, BSD/MIT code survives.

wiz21c 8y ago
statistics ?
- beatgammit 8y ago
  I don't have any, but I've rewritten my fair share of GPL code so I could use it both at work and personal projects. I've started using MPL for my projects recently because (L)GPL is just too restrictive.
  - jcelerier 8y ago
    too restrictive for whom ? as a potential user of your software, can I have the guarantee that if I buy a device with your software on it, I can replace it / fix it ?
    - zzzcpan 8y ago
      You are not asking all the questions though. What about buying a device that connects to a remote service running that software underneath? GPL won't protect you from such anti-user behavior. It's perfectly fine with depriving users of their freedoms this way. So (A)GPL is not restrictive enough either.
  - wiz21c 8y ago
    The GPL has some deeply political implications and it doesn't fit everyone's views. That's why people don't like the GPL, because it doesn't fit their view. But as far as its goals are concerned, I think the GPL achieve them very well. (I have the opposite experience, in the beginning I just used the GPL because it seemed fine, but thatnks to some real life experience, I came to realize how my own political views are embodied in it and how wrong I'd feel producing code that it's not GPL) (I don't say the GPL is perfect here, but it's way better than the MIT license for me)
ken 8y ago
Huh? Where's the BSD rewrite of Emacs? Is Linux not surviving? Are Hg and Git? GPL programs are category-killers.
- epicide 8y ago
  It only matters if you're redistributing it. So, libraries not tools. Given the choice between two otherwise similar frameworks/libraries, I would expect most to gravitate towards the non-GPL'd one since there is less friction. i.e. you don't even have to consider things like the GPL linking rules.
  - ken 8y ago
    Are people not redistributing Linux? This seems like an awfully thin hair to split.
    - epicide 8y ago
      I'm not trying to say everything exactly falls into one category or the other. There was a wide sweeping statement about a set that I believe to be generally true for one subset [0] and it was refuted with cherry-picked examples from a disjoint subset. [0]: Of a significant size.
  - klez 8y ago
    But that's exactly the point, isn't it? [a bit oversimplified] You want to use this GPL library? Great! Just release your own software as GPL! It's not complicated, per se, it's just that some people/business are not ok with that condition (which is their prerogative).
    - epicide 8y ago
      > it's just that some people/business are not ok with that condition The point is that if people/businesses are not okay with using it, then that hurts the survival of that thing.
tannhaeuser 8y ago
I hope we could bury that old discussion in the 90s. It's just holding us back from tackling today's challenges. Like, do you want to contribute to the ongoing centralization of information? Because if you're publishing your blog on FB (medium.com I don't know), or releasing your software on GitHub, then you're excluding indie search crawlers from access. You maybe shouldn't link to content silos that block non-UA agents (except GoogleBot and Bing) at all, because why would you contribute to non-reciprocal sites that are ruining the 'net?

claydavisss 8y ago

> Refuse to work on systems that profit from digital addictions. > Refuse to work on systems that centralize control of media. > Refuse to work on systems that prop up an unjust status quo. > Refuse to work on systems that require unsustainable tradeoffs. > Refuse to work on systems that weaponize the fabric of society. Rich people can afford to turn their nose up at any kind of work apparently. Also noteworthy that the internet was invented as a result of "weaponizing"...so put that phone down. Oddly enough all of this also invalidates working on most open source code, since the OSI says a license should not discriminate against intended use

empath75 8y ago
I think one can simply refuse to work on code that adapts the open source code towards nefarious ends. A screwdriver can build a pipebomb, but surely the person using the screwdriver is more culpable than the person who built the screwdriver.
- claydavisss 8y ago
  Define "nefarious end". This is why the OSI guidelines are correct to stay out of the tarpit of value judgements. Edit: BTW This is another reason OSI does not discriminate against intended use...to protect otherwise rational people from behaviors like you see on HN...blind downvoting and no responses HN is becoming incredibly anti-intellectual, bordering on reddit
  - wffurr 8y ago
    A good start is anything that works contrary to the Universal Declaration of Human Rights: http://www.un.org/en/universal-declaration-human-rights/ http://www.un.org/en/universal-declaration-human-rights/ How about acting in a way so as to not cause others to suffer or impede their search for happiness? The Dalai Lama makes a case for this as a universal ethic in his Ethics for a New Millennium. Calling making any kind of value judgement a "tarpit" is itself a value judgement in favor of the status quo and ceding any of your own culpability to others.

empath75 8y ago

Given how hot the market is for software developers right now, there's really no excuse to be working on ethically questionable products.

twoquestions 8y ago
Even not-great software developers who live in poor areas need to eat.
probably_wrong 8y ago
I would be cautious about generalisations like that. Sometimes the good jobs are where you aren't. Sometimes the good jobs won't return your calls. Sometimes you have to choose between your morals and your wife, deportation, debt, or all together.
- ed312 8y ago
  Can you really say you have morals if you sacrifice nothing for them? Are they not merely preferences at that point?
  - IggleSniggle 8y ago
    Participation in community at some level is necessary, and, depending on your morals, may be a moral imperative even when your morals disagree with the products of the community with which you interact. Is it easier to promote change in a community from within or from the outside?
  - deleted 8y ago
    [deleted]
  - probably_wrong 8y ago
    It's a tricky question. I agree that often morals involve making though choices. At the same time, those choices have to balance the magnitude of the evil, the consequences of sticking to your morals, and the consequences of just going with it. To give a concrete example: let's say I have to choose between unemployment and working in a casino (assuming I believe casinos to be evil). I can work there and do nothing. I can work there and donate an X amount of my salary to addiction-recovery ONGs. I can refuse to work there and compromise my (hypothetical) children's well-being. Which one of this is the "moral" choice? I can't say. And I'm willing to bet that you can make a moral argument for each one of those. I'm with you in that sticking to your morals often involve sacrifice. But I wouldn't assume that the weights I add to each aspect of my morals are the same as everybody else's.

alexandercrohde 8y ago

There's something mildly "ranty" about this, to its own detriment. I believe what it is is that it seems to try to connect ideas that have no logical connection, but simply an emotional association. For example, what is the connection between "Beautiful code gets rewritten" and "Refuse to work on systems that profit from digital addictions." ? It comes across as though the author is just vaguely angry at the loose concept of software. It's true that the software ecosystem is incredibly disorganized and inefficient (100s of similar distros, dozens of similar package managers, thousands of redundant tools). But I don't think one should get bent out-of-shape about it. If you think about it objectively, if it were efficient then most of us likely wouldn't have jobs.

OnlyRepliesToBS 8y ago
a rant about someone ranting
jgalentine007 8y ago
Yeah, I wonder how many 'just works' codebases he/she has had to spar with. It usually ends in tears. I have a 20k line VB.Net disaster that can't be changed without side effects because of the use of global variables, basically needing a whole rethink/rewrite. At least with some beautiful code the author might have put some thought into it beyond what is directly in front of them.
- phalangion 8y ago
  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.
    - 8y ago

crawfordcomeaux 8y ago

> To those who have a choice: If I think this doesn't apply to me because I don't have a choice, I'm disempowering myself. My choices may be hard to make, but abducted women still try to flee. We know because of the ones who escape. If I think others don't have a choice, I'm disempowering them. I choose to believe we everyone can learn to become more empowered and stand up to those they've been giving power to.

SketchySeaBeast 8y ago
That line of thinking can end at victim blaming - the abducted women stayed abducted because she didn't try to run hard enough. That's putting the blame on the wrong person. That being said, many devs CAN make the choice, but I don't think it's fair to blame those who can't. Not everywhere is booming to the same amount, and not everyone's life experience is the same to allow them freedom to move to an area that is.
- crawfordcomeaux 8y ago
  I'm not assigning blame. I'm choosing who I want as a role model. Blame is nonsense black-and-white thinking. There is shared responsibility in everything. I share in the responsibility of all things that occur after I take my next breath. Abandon blame and it's possible to read what I wrote without finding anything wrong with it.
  - SketchySeaBeast 8y ago
    Without framing it in blame then, if one fails even though they are empowered, what is the implications?
    - davemp 8y ago
      There are two classes of implications that come to me easily. 1) There is a possibility that the empowered person did not make the decision(s) that would have resulted in success. Maybe there was no decision chain leading to success. Good luck deciding. 2) The environment that caused failure, could be poorly optimized to minimize failure over a set of empowered persons. Maybe it is optimized and the individuals paths to success couldn't be increased. Good luck determining this, optimization of complex functions is not easy. The classes are not mutually exclusive. Ignoring the individual's actions (the first class) seems like a poor approach to reducing net failures. These lines of reasoning always remind me of a quote (from an admittedly cheesy source) that I think holds a useful sentiment. "There's always someone who'll try to convince you that they know the answer no matter the question. Be wary of those who believe in a neat little world because it's just fucking crazy, you know that it is." --DMB (I am not accusing the parent of being a person of which to be wary, their comments seem very reasonable).

quotemstr 8y ago

Whiplash. The first two sections are about generic software development truisms; from there, for the last section, the author pivots to arguing for his specific political positions, as if universal truths of software development justify these ideas. Is the author expect to convince anyone who doesn't already agree with him?

rntz 8y ago
> Is the author expect to convince anyone who doesn't already agree with him? Not really. If I wanted to convince skeptics, I would have to make it much longer and more precise, and then it be a very different kind of thing. Maybe I'll do that some other day. The connections between the sections are fairly obscure, I admit. But I think many "universal truths of software development" are instances of more general problems to do with collective decision-making and local optimisation processes, which also produce the problems the last section mentions. I don't have a solution, but in the meantime I'd like to avoid making things worse.

vegetablepotpie 8y ago

The only time I haven't seen shabby code with caked on layers of features has been when I had the fortune of working on a development team that was trained to write software. I've seen new languages and new development methodologies introduced to try to combat code complexity and the only thing I have seen so far that prevents it are people who take a step back and think about what they're creating before implementing it. These people are rare and go unrewarded for their efforts.

jmarchello 8y ago
This is so true. There is a lost art of software architecture and design.
- folkrav 8y ago
  Shit software architecture/design is nothing new. There always was shit code, and always will be. The sky is blue.
deleted 8y ago
[deleted]
lotyrin 8y ago
I've been wandering from job to job looking for these folks to learn from and have failed so far. Nobody seems to be able to think even two steps ahead, often fail to think one step ahead sufficiently to answer "why" questions about their current task.

vmchale 8y ago

> generic code is replaced by its concrete instances, which are faster If you're using a shitty compiler, yes.

jstimpfle 8y ago
By that standard I seem to know only shitty compilers. Sorry to be blunt but you don't have a clue. As a rule of thumb, compilers can make a 10x difference (for example in machine code performance). Programmers can easily make a 1000x difference. Not even looking at algorithmic improvements.
coldtea 8y ago
http://wiki.c2.com/?SufficientlySmartCompiler http://wiki.c2.com/?SufficientlySmartCompiler
- wild_preference 8y ago
  They're referring to monomorphization. Rust, for example: > You might be wondering whether there is a runtime cost when you’re using generic type parameters. The good news is that Rust implements generics in such a way that your code doesn’t run any slower using generic types than it would with concrete types. > Rust accomplishes this by performing monomorphization of the code that is using generics at compile time. Monomorphization is the process of turning generic code into specific code by filling in the concrete types that are used when compiled.
  - jstimpfle 8y ago
    Where do you get that monomorphization reference from? Let's assume for example you have a generic hash map where you just plug the type in, which must be hashable. Now if you plug in an integer type, monomorphization or whatever fancy compilation techniques will make that faster. But the best way to map an integer range is still a plain array. To put it in simple terms, compilers can make shit run faster, but they can't make it not shit.
    - 8y ago

beat 8y ago

I've been meaning to give a lightning talk about a related subject someday, called "Why Software Sucks". Basically, software hovers along the fuzzy line between "barely works" and "doesn't work". When we start a project, it doesn't work. We add code until it barely works. Then we break it, so it doesn't work. So we add enough scaffold that it barely works and can support the new features, until we break it again, and the cycle begins anew. This is actually embedded as principle in TSTTCPW (the simplest thing that could possibly work), but attempts to waterfall our way out by careful planning are generally doomed, due to unintended consequences and such. Eventually, the software becomes broken and no longer worth fixing (and thus gets abandoned), or it hits feature complete while (barely) working. And what happens when it's "complete"? Do we say "Thank goodness, finally I can go fix all those bugs and design flaws!"? No, never. Instead, we drop that blecherous losing piece of crap as fast as we can and go start on the shiny new project that's been cooking in our minds, the one we couldn't work on because we were hacking our way through the wretched ball of mud that is our old code, wasting time in frustration and shame, just to get it off our plate. So we start working on the shiny new thing. And this time, the code will be good. This time, it won't suck. Yeah, right.

cntlzw 8y ago
A lightning talk I would love to attend.
fjsolwmv 8y ago
The whole world hovers between barely works and doesn't work. That's the theory of evolution that explains the history of life.
- gglitch 8y ago
  Nice observation. I would enjoy a Tao of System Design that coyly smiles and says, The architecture that can be defined is not the true architecture.
  - gmfawcett 8y ago
    It's not nearly as pithy, but I think that this line from "Big Ball of Mud" captured something essential: > "Architecture is a hypothesis about the future that holds that subsequent change will be confined to that part of the design space encompassed by that architecture." http://laputan.org/mud/mud.html#Forces http://laputan.org/mud/mud.html#Forces

niftich 8y ago

The purpose of software is to teach a machine perform tasks, even when many of those tasks are to show an interface so that a human can perform a task. Design is nontrivial, but computers are powerful, so we can layer on abstractions to ease the understandability and modularity of the code. This is a creative process that's part engineering, part art: some people choose to take proven components and techniques and apply them in predictable ways, while some choose to experiment with new techniques, and some up with novel solutions. But any tradeoff has a cost, and future maintainers may not appreciate a solution whose meaty details aren't obvious. While the creation of software may be a part-creative process, its maintenance is purely pragmatic: fixes to unforeseen problems need to be delivered quickly above all else, and enhancements along all extension points need to be possible, not just along axes the original authors intended. It's not hard to see that elegant code might be under immense pressure from more pragmatic modifications, any one of which can endanger its status in the eye of a beholder. This is likely why this article's author sees 'ugly' code survive: presumably, small changes are sufficient to make beautiful code ugly, while already-ugly code faces no such aesthetic pressure.

jackcosgrove 8y ago

The author makes some good points about the ethical dubiousness of a lot of software jobs. But I think the author misses the biggest point. Software replaces people with machines and increases capital's share of income. I have heard technology is the biggest driver of growing inequality, and at this point in history technological change is driven by software. I think the old nostrums about creative destruction and labor saving technologies freeing up labor to pursue higher roles are true in the aggregate, but the aggregate obscures a lot of human wreckage left behind by people who were laid off and never rehired at a comparable level. I consider this process inevitable which is why I am trying to get ahead of it. But that's a fundamentally selfish motivation no matter how much you gussy it up. Being honest about this is one thing that keeps my aspirations modest - I simply want to carve out a place for myself where I feel comfortable. I think buying into the creative destruction rhetoric makes it easier to harden your heart.

deleted 8y ago

[deleted]

crazygringo 8y ago

> Beautiful code gets rewritten; ugly code survives. Ever stop to think that maybe this is a good thing? That code doesn't exist to be beautiful -- code exists to get the job done. Beautiful doesn't mean it's not also useless or arbitrary or over-architected, while ugly can be a healthy balance of competing priorities -- maybe not clean, but a good series of necessary real-world compromises. This isn't to defend all (or even most) ugly code as good... but that equating beauty with good comes across as terribly naive.

erikpukinskis 8y ago
They didn't say it was a bad thing. Just that it's what happens. I've noticed lately that people seem to assume that if you say something negative, you're trying to make a big existential claim about its place in the universe. Like when people criticize masculinity and then we are all aghast as if they said masculinity needs to be systematically extracted from all aspects of culture. I'm not sure which side of the equation needs to be more careful though. Maybe, in the internet age with the globe as your audience, if people are criticizing things they need to add a bunch of caveats to make it clear what they're not saying.
- crazygringo 8y ago
  The first sentence literally calls it the "tragedy of software engineering". I don't think I'm making an unwarranted assumption that the author means it's a bad thing.
yourbandsucks 8y ago
Not to mention, often times the business requirements themselves are ugly. Ugly but clear is the lowest possible distance between code and purpose. I've spent so many hours obscuring the true purpose of chunks of code just so it can hit some zealous reviewers checklist of patterns they like..
rntz 8y ago
"Getting the job done" is a short-term goal that often comes at the expense of long-term well-being. For example, the endless parade of backward compatibility layers on top of backward compatibility layers. Each got the job done at the time. And each makes it just a little bit harder for future programmers to get their jobs done. I think a sense of beauty can let us know that something is amiss with the bigger picture. It can provoke us into stepping back and ask: what is actually necessary? Which jobs really need doing, and at what cost? Certainly, short-termism is not the only failure mode when writing software. Abstraction for abstraction's sake is another.

blueadept111 8y ago

>Software grows until it exceeds our capacity to understand it. This point is well taken, and I think that many organization would benefit from having a CGR role ("chief grim reaper"), who's job would be not to enhance the codebase or its functionality, but to do the opposite: to kill/simplify code and prevent the codebase from exceeding a certain net complexity over time. Simplicity itself need to be treated as a core feature, and the success of the CGR need to be defined by whether that core feature is maintained.

opwieurposiu 8y ago
Wow that is a really good idea. Unless a specific individual is in charge of something it will never get done. I am going to propose this to my team.

miguelrochefort 8y ago

Can someone point out to projets or initiatives that are attempting to solve the problems mentioned by the writer of this article? I can't stand the unnecessary complexity, fragmentation and duplication in software. The entire industry is a mess. Very few people seem to care.

erikpukinskis 8y ago

I only wish it was longer.

dkarl 8y ago

Just so, generic code is replaced by its concrete instances, which are faster and (at first) easier to comprehend. Just so, extensible code gets extended and shimmed and customized until under its own sheer weight it collapses, then replaced by a monolith that Just Works. aesthetics alone keep us from the hell Beware of comparing "beautiful" code to subsequent code that deals with 10x the complexity in requirements. Either it's beautiful because it's perfectly suited to the scale and complexity it was written for, in which case it's impossible to preserve that beauty in the later, more complex code, or it's "beautiful" because it has a bunch of premature abstractions built in that somebody fantasized would handle all future complexity, in which case the "beauty" was useless work that later programmers had to undo. When the supposed genericity and extensibility of a system doesn't survive the evolution of the system to meet subsequent requirements, my first suspicion is premature abstraction, not insufficiently tasteful programmers. Even worse, the effort to dismantle this "beauty" is often considerable. Architecture, defined as the set of decisions that are costly to change, needs to anticipate the drastically different needs of the future. You rarely find architecture within the code of a single system early in its development, because code at that stage should be easy to rewrite. Code seen as "beautiful" by its author often violates this rule, creating architecture where architecture shouldn't exist.