
Against software development - octosphere
http://www.rntz.net/post/against-software-development.html
======
alexandercrohde
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.

~~~
antoineMoPa
"If you think about it objectively, if it were efficient then most of us
likely wouldn't have jobs."

So programmers should write bad software to keep their jobs? And civil
engineers should build bad bridges to build them again a bit later? And
doctors?

~~~
njarboe
Drug companies look to discover/invent drugs that can treat a symptom forever,
rather than curing people. Probably the main reason people hate drug
companies. That and charging 100k for a treatment when they do find a cure
(Hep C).

~~~
HeyLaughingBoy
Can you cite actual instances of this happening?

~~~
njarboe
It is what is not happening that is the problem. A bit harder to prove but not
researching antibiotics is one case that is widely discussed. A google search
on "why aren't drug companies researching antibiotic drugs" brings up lots of
articles spanning decades. This Business Insider [1] article is quite recent.

Here is a quote from that article:

"The costs to develop a new antibiotic drug are no less expensive compared to
development of drugs for other therapeutic areas, yet the commercial potential
and return on investment for companies developing new antibiotics are
significantly lower than drugs to treat chronic conditions such as diabetes or
heart disease," said Gary Disbrow, deputy director of the Biomedical Advanced
Research and Development Authority, which sits within the U.S. Department of
Health and Human Services.

[1][https://www.businessinsider.com/major-pharmaceutical-
compani...](https://www.businessinsider.com/major-pharmaceutical-companies-
dropping-antibiotic-projects-superbugs-2018-7)

------
beat
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.

~~~
athenot
This really depends on the kind of industry. If we follow the money trail,
software exists to achieve a business goal, either directly or indirectly. As
with most things in business, what matters is "good enough".

Some software exists outside of this environment, usually because it is
beholden to an impeccable level of quality (defined as never caught in a non-
deterministic state, resillient, etc). This can be:

— software used by millions of people, all poking at obscure edge cases;

— software used by lots of other software, for the same reasons;

— software commissioned by high stakes businesses (space, life-support
systems...), where the amount of life or money lost, should the software fail,
is simply unacceptable.

This in turn guides what I decide to work on. If your employer/client views
your software purely as a cost center, you can guarantee the quality you are
allowed to deliver will always remain mediocre. Good enough to support the
business but no more. I learned to stay away from those industries.

~~~
beat
I used to work on a system that moved a hundred billion dollars a day. Yes,
billion. Downtime costed thousands of dollars a minute simply in floating
interest from money not moving, and a serious outage could damage the entire
economy. That's some serious high availability requirements.

 _For purposes of its extreme performance and availability requirements_ , it
barely worked. That doesn't mean it was bad code! It was great code. But it
could have been better. It could have been much better. And it wasn't, because
once it met those requirements, work got applied to expanding its feature set
instead. Which was, in a way, also a requirement.

Pick _any_ "impeccable level of quality" system, and you'll find the same
thing. Heart monitors. Mars launches. Whatever. The software barely works,
given the difficulty of the requirements. I'd argue that it's actually
irresponsible for businesses to try to do any better than that! The cost of
bouncing the rubble with code quality is a resource that could be much better
spent on other things.

Think of it in terms of the 80/20 rule. Dig into that last 20%, and you'll
spend 80% of your effort on it. It's not a good tradeoff. The Pareto Principle
isn't a measure of how bad we are, it's a measure of how good we are. When we
attend to its wisdom, we get the most work done.

edit: Scope is not the only requirement. Schedule is also a requirement!
Pareto Principle again! Taking four times as long to get 20% better code is
failure. We don't just have to create features. We create features with the
resources we have, the technology we have, the people we have, within the
schedule we have. A blown schedule is a failed requirement. Software not
delivered on time is, in fact, broken.

~~~
cleong
By definition wouldn't all bridges "barely work"? Yes it's spec'd to handle X
load, now putting X+1 might cause some damage because it was never tested or
designed for X+1.

~~~
jungler
All bridges follow similar designs, even if their implementations are
original. Digital systems tend to fail in original ways all the time, because
the design is something intentionally new. If it weren't, you'd just copy the
existing software.

Which doesn't mean that we have no reusable or generalizable quality metrics -
we do. But they tend to express things that correlate to an abstract of
quality, and not a failure threshold.

The most honest systems in software are the ones that do not scale, because
they have built in their hard failure point - and from that, tolerance metrics
similar to bridges can be predicted and planned for. It's software that has to
do everything in a multitude of configurations at great speed that runs into
deep architectural issues, because it hypothesizes a bridge that will someday
tolerate an infinite load.

------
jackcosgrove
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.

------
vegetablepotpie
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
This is so true. There is a lost art of software architecture and design.

~~~
folkrav
Shit software architecture/design is nothing new. There always was shit code,
and always will be. The sky is blue.

------
blueadept111
>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
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.

------
crazygringo
> _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
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
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.

------
dkarl
_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.

------
quotemstr
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
> 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.

------
crawfordcomeaux
> 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
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
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
Without framing it in blame then, if one fails even though they are empowered,
what is the implications?

~~~
davemp
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).

~~~
SketchySeaBeast
So empowerment doesn't mean they have the ability to change anything, it's
just a state of being where they are under the belief they can possibly change
something? What exactly is empowerment?

~~~
davemp
Predetermination is not a theological rabbit hole that is necessary to go down
for this conversation. Reducing things to the point where the original ideas
have little tangible meaning ineffective way to discuss ideas. See why
mathematicians reduce complex ideas into a concise syntax.

\---

Empower:

* To invest with power, especially legal power or official authority.

* To equip or supply with an ability.

Give to individuals:

Legal power over their persons (liberty), as much as is possible without
infringing on the legal power of other persons.

The ability and knowledge to wield this power to maximize their individual
outcomes.

\---

These concepts are well defined by the founders of the USA in a really
beautiful and rigorous fashion. Read them thoroughly and you will learn more
than I can convey.

I'm not sure why you would trust me, a stranger on the internet to define
these concepts to you. Would you write off the foundational ideas of liberty
if I were not able to convey these concepts with the fluency they deserve?

I'm picking up a really ineffective and/or deceptive argument strategy from
you. The guidelines of this cite states:

> Please respond to the strongest plausible interpretation of what someone
> says, not a weaker one that's easier to criticize. Assume good faith.

If your plan is to ask de-constructive questions until I slip up, know that
you are abusing the Socratic method. [1] It is a cooperative argument exercise
used to promote critical thinking. I did not consent, nor have the time for a
critical thinking exercise. Refuting a sub-hypothesis says little about the
school of thought that may have spawned it.

I am only writing this reply because I have seen similar threads spread
throughout internet boards since I started browsing. The strategy (not you) is
an evil cancer that degrades effective discussions, brow beats posters into
submission, and kill communities. If I were to host a discussion platform I
would do my best to cull this practice (without consent). I believe that is
the spirit of that point in Paul's guideline. Please do better.

[1]:
[https://en.wikipedia.org/wiki/Socratic_method](https://en.wikipedia.org/wiki/Socratic_method)

------
niftich
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.

------
miguelrochefort
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.

------
vmchale
> generic code is replaced by its concrete instances, which are faster

If you're using a shitty compiler, yes.

~~~
coldtea
[http://wiki.c2.com/?SufficientlySmartCompiler](http://wiki.c2.com/?SufficientlySmartCompiler)

~~~
wild_preference
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
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.

~~~
alexhutcheson
> But the best way to map an integer range is still a plain array.

Eh, only if you know in advance that:

1\. Your integer keys can only ever come from a contiguous range of values

2\. Once populated, your map will have values for at least 25-50% of the
integers in that range.

If either of these assumptions are false, using an array will force you to
allocate way more memory than you need to hold the elements in your map, and
the resulting map will be sparse, and therefore cache-unfriendly.

Arrays are not better than hash maps that use integer keys in the general
case.

~~~
jstimpfle
Which is my point. Compilers can't help here.

~~~
vmchale
Yes, that is correct, you missed the point. You don't understand what generics
are.

~~~
jstimpfle
I think you are confusing "generic code" (which is a pretty generic term) with
"Generics", which has a somewhat more defined meaning in programming
languages.

We could agree that the latter can be implemented relatively efficiently
(given a few concrete examples to clarify what that means). But that does not
mean that their use, or more generally, the use of generic code, is always the
best and most efficient to do. It is not, by far.

------
erikpukinskis
I only wish it was longer.

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

~~~
probably_wrong
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
Can you really say you have morals if you sacrifice nothing for them? Are they
not merely preferences at that point?

~~~
probably_wrong
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.

------
claydavisss
> 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

~~~
niftich
The OSI model of licensing has its philosophical roots in a very classical
notion of universal rights and freedoms. As with all absolutist points-of-
view, this frustrates some pragmatic people, and/or irks those developers who
want to benefit from the publication of their work without large corporations
then profiting monetarily from the same work.

That's fair, but there's an entire, centuries-old legal apparatus designed to
protect the rights of that kind of developer: they should engage a lawyer,
craft a license with the correct balance they seek, and pursue to reap the
concrete or abstract rewards from their work.

But instead, it's en vogue to complain about open source licenses and wonder
why the cake can't also be eaten, because developers have a marketshare-
scaling problem: they want their software distributed to a wide audience such
that it gains usage and mindshare, but not wide enough where AWS is selling
their work as a managed service at prices they couldn't by themselves.
Attempts by rightholders of software that suffered this fate always try to
split the offering into a libre core and a proprietary set of enhancements
with various levels of success, while some go down a nonsensical and legally-
dubious path of trying to force libre licensing onto proprietary companion
software within a larger offering. These demonstrate that giving away libre
software may not be a sound business model on its own.

Unfortunate for this article's author, the ethical stands he wants other
developers to make are quite often _good_ business models. That's to the
detriment of all of us. Some amount of people will make a stand, but there
will be others who won't, and they'll reap the rewards, and we'll suffer the
consequences of their work nonetheless.

~~~
beat
It's very easy to derive a good business model from bad ethics. All business
models derive from friction, right? We make money doing things for others that
they find difficult or unpleasant to do for themselves. The more
difficult/unpleasant it is, the greater the potential value.

Something that can make a task difficult or unpleasant is that task being
unethical. Take for example an investment scheme that bilks the elderly out of
their retirement savings. Technically, it's not difficult to do. Ethically,
it's awful. So it's profitable because it's unethical. If robbing the elderly
was ethical, a lot more people would do it, and there'd be a lot less money in
it.

------
amelius
> Beautiful code gets rewritten; ugly code survives.

Also: GPL code gets rewritten, BSD/MIT code survives.

~~~
ken
Huh? Where's the BSD rewrite of Emacs? Is Linux not surviving? Are Hg and Git?
GPL programs are category-killers.

~~~
epicide
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.

~~~
klez
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
> 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.

