
Simple Software Manifesto - Spakman
https://arewesimpleyet.org/
======
pron
Every new generation of programmers starts a crusade to simplify without first
trying to understand why we're not "simple" despite the previous generation
having done the same. Of course, one possible explanation could be that
without a constant crusade for simplicity we'd be in a far worse place; the
"permanent revolution" explanation. But is this the right explanation? Turing
Award winning computer scientist Fred Brooks had this to say:

> The complexity of software is an essential property, not an accidental one.
> Hence, descriptions of a software entity that abstract away its complexity
> often abstracts away its essence. (No Silver Bullet, 1986)

> Complexity is the business we are in, and complexity is what limits us. (No
> Silver Bullet Refired, 1995)

The reason "complexity is the business we are in" is that software doesn't
live in a vacuum. Like the economy and like bureaucracy, it is built to serve
a certain social purpose. Of course, there needs to be a constant struggle not
to _over_ -complicate, but it should be done with the understanding that over-
simplification is just as problematic.

~~~
gglitch
I think that all else being equal, simplicity is to be preferred over
complexity. You're pointing out that all else is never equal; ok, cool; but
it's hard to imagine anyone finding value in deliberately complicating things.
Simplicity seems to be an inherently valuable trait in system
design/maintenance. Can you oversimplify? Sure. Does that justify not striving
to reduce to the simplest functionally complete, scalable, and maintainable
design? In my opinion, no.

~~~
pron
My points are:

1\. Even software with no "accidental" complexity is necessarily complex (in
fact, that's why it's useful).

2\. If the manifesto's point is that we should stop _over_ -complicating
things, then wouldn't it better to first examine whether, and if so why,
things are overcomplicated now, given that the previous generation also went
on a crusade to abolish (over)complication? If the point is to declare "don't
overcomplicate!" then, if you believe things are overcomplicated now, why is
that declaration useful if it's clearly not effective?

~~~
spion
Yep, now that we have lots of version controls histories publically available
there is no excuse for this.

------
nullspace
> There is only one correct way to do something .... so take great care in
> doing it right the first time.

I hear this a lot, in various contexts, and I even used say it a lot. But this
has actually stopped making sense for me. I don’t think I’ve ever genuinely
seen a case where there is only one obvious way to do something, or that
there’s a way that is obviously the “right” way. Everything non-trivial is
chock full of trade offs and hidden corners that could make it obviously wrong
in hindsight.

Does someone disagree? Can you share your perspective.

~~~
williamdclt
Completely agree. I'd change this whole line to something like:

"There is never only one way to do something. You can't know which is correct,
so go for the simplest option that is easy to change later"

~~~
gerbilly
> go for the simplest option that is easy to change later

And once customers get their hands on your simple thing, management won't let
you change it to something better...

(Also known as, "The demo becomes the product.")

Your simple solution is embedded in a complex social reality. If you're not
taking that into account, it probably won't stay simple for long: i.e. simple
to maintain, simple to operate, simple to build new features on.

------
majewsky
> We target C99 or C11

C is anything but simple. It looks simple on the outside, then beats you to
death with undefined behavior and either overexplicitness (if you don't use
macros) or nested-macros hell (if you do). Their choice of C is routed more in
the authors coming from the Unix community, not in their desire for simple
software.

If anything, they should start with a truly simple programming language.
Something like Go minus huge runtime and maybe plus basic generics.

~~~
dkersten
I was going to say something similar. If you really want a simple system,
maybe avoid C and stick with something memory-safe. Overall, I'm not sure what
to make of this page. C is simple, git overdid it, etc. Oh ok.

------
bitwize
Yet more suckless-style posing. Ho fucking hum.

Software is complex because the real world is messy. That messiness cannot
ever be "abstracted away", it can only be hidden.

You can't derive a better software stack from first principles. What we have
is the tireless work of many people, quite a few of whom are smarter than you.
Rust and LLVM, for instance, are much more fit for purpose than "my pet
compiler backend + my favorite C subset" because even the most disciplined C
subset is still full of UB traps and Rust has had years going on a decade of
work, by many hands, addressing the very cases where C falls flat on its ass.
The same with LLVM vs. whatever brain fart J. Random Hacker thinks up as an
ideal abstract machine,

~~~
naasking
> That messiness cannot ever be "abstracted away", it can only be hidden.

How would you hide something without hiding it behind an abstraction?

> You can't derive a better software stack from first principles.

What do you consider "first principles"?

------
fefe23
I have come to believe that we are dealing not with a domain specific problem
but with the human condition itself. I call this my gradient theory.

Consider human learning as an optimization in the mathematical sense. Note
that humans are good at learning things along a gradient. Now note that this
is not just about how the learning works but also how far we go. For example,
if a human thinks it is too cold, they turn the knob not where they want the
temperature to be but much farther up, and then when the desired temperature
is reached, they turn it back. Or consider how you find a page in a book. You
overshoot and then go back. Or how you choose the speed when driving. You go
as fast as you feel comfortable, and you find that by overshooting and
correcting.

I think this is inherent in humans. Evolution made us this way.

The downside is that humans are bad in environments where there is no clear
limit or where you can't correct after overshooting, for example driving too
fast and then having an accident, or substance abuse.

Now take this thought and apply it to programming.

If you find me a way to work with complexity, for example modularization,
abstracting it away, etc., it will not lead to us writing a good version of
the software we had before. It will lead us to writing larger software that
will then again be at the limit of what we can do with the technology
available.

So far it is just a theory, but I can see in my software selection that all
the programs that I consider good and simple in the sense that this manifesto
describes, all of those are old programs that were written when the
functionality they offer was the limit of what was achievable with technology
back then. The reason they did not metastasize into something unwieldly is
that a) they did but it was still comparatively small or b) they already
contain all the features anyone could think of.

Try comparing two programs of your choice that do essentially the same. You
will find that if there is an old and a new one, the newer one will be bigger
and slower and usually work in less environments and have less features.

It also turns out that no two people have the same idea of what "simple"
means. For me, with software, simple means it does all I really need it to do,
and nothing else. Other people usually need it to do other things and they
don't need some of the stuff I need.

~~~
naasking
> If you find me a way to work with complexity, for example modularization,
> abstracting it away, etc., it will not lead to us writing a good version of
> the software we had before. It will lead us to writing larger software that
> will then again be at the limit of what we can do with the technology
> available.

So basically Parkinson's law applied to complexity rather than time. I think
it's definitely true. More complex software is (ideally) more versatile,
handles more cases of the problem domain, and so there's competitive pressure
to make software as complex as is feasible to solve as many problem as
possible, and thus, provide as much value as possible. The ceiling is exactly
as you said: what level of complexity is manageable given the other
constraints that must be satisfied (performance, robustness, etc.)?

Edit: to be clear, I mean "essential complexity" above, not accidental
complexity from poor designs. Being able to handle more essential complexity
is a good thing.

------
CptMauli
Just from some discussions from the last weeks, I don't think simple is
possible anymore: just Unicode and Font Rendering by themselves have a
complexity which boggles the mind. If you then consider stuff like
authentication/authorization, i18n and support for blind people its clear that
"simple" just doesn't cut it.

~~~
lifthrasiir
A common excuse is that they target "expert users" and not everyone. While I
can imagine a specific set of "expert users" that this excuse will work, not
every "expert user" will agree to that.

------
pcr910303
Every software has a reason to be complex. Often software authors desire to
make simple software by removing such features regarded ‘complex’ without
understanding why those features were introduced (mostly because they don’t
use them). The consequences is that people who are in the minority can’t use
the software.

As a CJK person, the most prominent example is multilingual support in the
FOSS community; I still have not seen any Linux GUI app with proper out-of-
the-box IME support (and that includes DEs, WMs, etc...) mostly because for
some reason (hint, most are from the western world) the devs of Linux
distributions turn off IME support by default. Is it really ‘simple’ to turn
off some features that you don’t use, resulting in total breakage of apps when
the feature is in use? Really?

~~~
AnIdiotOnTheNet
I tihnk that's just a symptom of how FOSS devs think about GUIs. GUI is
largely not something FOSS developers actually use. The design of FOSS GUIs
makes it seem as though "GUI" is something they've read about in text books
and personally only see value in as a fancy tmux. Consequently, the only
mental model they have for someone who actually uses a GUI is the kind of
person who only needs a web kiosk.

------
gerbilly
Ugh, I don't share this sentiment.

Each new generation of programmers creates new tools to replace the 'complex'
ones that came before without even bothering to understand them.

In my 25 year career I've seen it multiple times. We are all going downhill.

Attention spans in the smartphone era might be preventing people from reading
the f*ing manual.

This means that any system or library which has an operating model that must
be understood before it can be effectively used¹ simply can't be understood by
the majority of programmers today.

1: The currently popular things in software world are mostly the type of
system that lack such a model and which can be 'mastered' by asking discrete
questions on stack overflow. This lack of complexity causes a loss of
expressive power.

~~~
phendrenad2
And no one even writes the manual anymore. Software project documentation is a
disaster.

------
cocktailpeanuts
Don't #2 and #3 contradict?

> Constraining the user to simple tools encourages creativity and allows the
> system to be more quickly understood

> There is only one correct way to do something, because two ways would be
> more complex

When you encourage creativity with combinations of simple tools, creative
people will come up with multiple ways of doing things.

~~~
Jwarder
I read the "only one correct way" to be a per-tool guideline. When looking a
tool to do a specific task then (ideally) the tool should just process input
with minimal futzing with configuration options. If you need to do something
special then you should have a special tool.

~~~
OrderlyTiamat
That seems reasonable. Though in the context of packages etc, i would like to
then introduce the term "toolset". Just because a piece of software is a
single package doesn't mean it has to be a single tool. It is much more
_simple_ to have a bunch of tools for related tasks collected in a single
toolset rather then making seperate apps for each one- never mind the overhead
that the last approach would create.

------
frou_dh
My related observation is that the phrase _" simple yet powerful"_ is the
biggest cliché in developer/techie-facing marketing of software:

[https://github.com/search?q=%22simple+yet+powerful%22&type=C...](https://github.com/search?q=%22simple+yet+powerful%22&type=Code)

Is there any camp that DOESN'T consider their preferred way of doing thing to
be simple yet powerful?

------
Koshkin
It shouldn't be just about software. Hardware has become astonishingly complex
as well. Forget about a high quality superhet radio containing 15 transistors,
or a CPU with a manageable instruction set and an assembler that is a pleasure
for a human to write in. No doubt modern systems are better than old ones, but
I miss those times somehow...

~~~
no_flags
Is that a bad thing though? Modern CPUs seem to be incredibly reliable. I
think much of the complexity has to do with the the fact that all the low
hanging performance improvements have long since been implemented. To continue
to get faster, sometimes the only option is to increase the complexity of the
design.

------
GR-O-ND
This also reminds me of OpenBSD, in particular Ted Unangst. He's famous for
deleting features that add complexity without any significant benefit or are
only useful in a small number of edge cases. For instance, the replacement of
sudo (with its massively complicated configuration syntax) with doas.

------
stiray
My proposals, under high level programming something derived from:

\- thou shall learn how to use the wheel, thou shell not reimplement it
instead

\- best software barely satisfies task it was made for

\- antipasta statement: no lasignas, no spaghetti and no raviolli

\- the code forming interface will be at max 20% of actual code written

\- no interface will be designed to solve all humanity problems for next
millenia

I think that all those were hugest pains I had within 23+ years of
development.

What were yours?

------
adamfeldman
"Simple Made Easy", a talk by Rich Hickey
[https://news.ycombinator.com/item?id=4173854](https://news.ycombinator.com/item?id=4173854)

------
AlexandrB
What’s wrong with Perl?

Also, with no C macros there are no C generics. I wish the author luck in
maintaining that mess.

~~~
etripe
> What’s wrong with Perl?

Looking at their central axioms, I would guess:

1 - simple software breaks in simple ways: weak, dynamic typing means a lot of
problems trivially solved by static and/or strong typing.

2 - simple tools: no idea. I remember cpan being fairly great and perldoc
being excellent.

3 - one correct way to do thing versus perl's TMTOWTDI central theme

4 - dependencies are part of the system: lots of CPAN modules, so there's a
tendency to import black box modules instead of writing it yourself and
retaining ownership.

5 - standards are useful but full of cruft: perl has a much larger standard
lib than, say, Go or Python as far as I understand.

As to why it would be what's wrong with git: after a cursory glance at the git
repo (0), I would guess the problem is that it still contains .perl files?

[0]:
[https://github.com/git/git/search?l=Perl](https://github.com/git/git/search?l=Perl)

------
HelloNurse
Simplistic software manifesto.

1\. All software breaks, so let's avoid failure by not even trying.

2\. Constraining the user to simple tools, because the user is an idiot.

3\. There is only one correct way to do something, and it's mine. Coming up
with one mediocre way to do things is already a great accomplishment; thinking
about design tradeoffs is unthinkable. YOLO!

4\. The dependencies of a system are not fun, so they are your responsibility.
Good luck.

5\. Standards are a source of inspiration, idiots (see #2 above) aren't going
to run into interoperability problems, missing features, and other
consequences of implementing only the "simple" parts of the standard.

The cproc missing features list is a brief but very insightful example of this
way of thinking (I mean, this way of _not_ thinking).

------
Porthos9K
This reminds me of suckless.

[https://suckless.org/philosophy/](https://suckless.org/philosophy/)

~~~
Koshkin
There is something weird about trying to put a layer of simple software on top
of an astonishingly complex system kernel. (RiscOS, for example, looks more
balanced in that regard.)

~~~
Porthos9K
I'm tempted to suggest that the suckless people are on Linux because they
can't handle OpenBSD or Plan 9, but that would be cruel.

------
0x445442
I suggest the biggest problem we have in the industry is a laziness towards
engineering and an unwillingness by business to accept the law of fast, good
and cheap.

Very few organizations use real data and the scientific method to make
decisions on architectures and design. Most rely on anecdotes, gut feel,
politics and software cults to make these decisions.

Consequently, there's rarely real proof on the advantages of one approach over
another. The rigor, and thus cost, needed to make those determinations is
perceived to be too great but the reality is, those perceptions are often
unfounded when considering the total cost of software.

This all hit me years ago when working for company that had to go through CMMI
certification. As part of the effort, a consultant would come out quarterly to
coach us along and monitor our progress. During that time period I noticed a
significant portion of my time was now spent on the implementation of the
process. When the consultant was out for a visit I told him I had concerns
because we did not have a charge number for the extra time it was taking to
implement the process. He asked why that would be necessary and I asked, how
else could you make an objective determination on the benefit/cost ratio of
implementing the process being greater than one. Disappointingly, the blank
stare ensued.

------
btbuildem
I believe the complexity is inherent, and we haven't yet found a way to handle
it gracefully.

I'd like to note that "simple software" means a different thing to the
developer, and to the user. And in the grand scheme of things, the developer
and all the code he wrote is highly irrelevant. We'd like to think we are, but
how much does it really matter what kind of trowel the mason used, and how
clean he kept it? What matters is the cathedral he built, the feel of the
space within, the durability of the walls.

In my view, the complexity is closely related to scale. I'd like to draw a
parallel with nature, where things scale linearly up to some critical point,
at which a system goes through reorganization and only then continues to grow.
I think mimicking this phenomenon can be a path towards software simplicity.

------
blackbrokkoli
> Constraining the user to simple tools encourages creativity and allows the
> system to be more quickly understood. This supports the removal of
> complicated features.

Oh god, no. This horrible idea escalated so far that there is now a billion
dollar industry (RPA) automating braindead tasks just because software can not
be arsed any more to include API, code/CLI based access or, to steal the
wording, complex tools at all.

IMO this is another round of weirdly religious adherence to "UX" schemes which
ends in massive damage, like the unconditional love for whitespace everywhere.

Please stop using "simplicity" as a cop out to prevent having to build
software that, for example, has basic things like stack deletion. The result
will just suck.

------
als0
> POSIX should probably be replaced when the time is right.

Everyone loves to bash POSIX. The idea of replacing it lingers on, but has
anyone considered the idea of updating POSIX to remove the gnarly parts? This
is a somewhat incompatible change and would have to be versioned
appropriately.

------
ptah
simple for developers != simple for users

------
Pete_D
I would suggest sinit for init / supervisor:
[https://core.suckless.org/sinit/](https://core.suckless.org/sinit/)

------
bachmeier
> Simple software manifesto

Excellent!

> There is only one correct way to do something

!!! The correct way to do something depends on what else you're doing at the
same time.

> Simple software in practice > C

Dear God

------
faisalhackshah
Why use C? Constrained with no macros? What about undefined behavior?

Rewrite in Zig!

------
jagger27
apk truly is a great package manager. Glad to see it mentioned here. It’s such
a bummer going back to aptitude after using it in my lighter weight VMs.

