
Anti Mediocracy Manifesto for Software Development - gabordemooij
http://gabordemooij.com/index.php?p=/manifest
======
arpa
While very idealistic and beautiful in a way as all manifests tend to be, we
(along the author) tend to forget certain truths - the middle of the gaussian
curve is fattest; all natural distributions follow that curve, and developers
are no exception. Most of us, by definition, are mediocre. There's nothing
that can be done about it. We should not shun, but rather embrace that. Not by
deluding ourselves that if we follow some idealistic manifesto we somehow rise
above our limited skills and minds. We will not. We will suck. Our tech will
suck. Other peoples' tech will suck. There is no ideal that can be attained.
This is not the profession of saints and Buddhas. But by knowing this, by
accepting this, we can start working on raising the standard for mediocracy...

~~~
smackay
But surely the purpose of the manifesto is to skew that curve to the right.

~~~
arpa
One might as well try to skew global IQ stats to the right. And please, don't
call me shirley.

~~~
CSMastermind
This has been happening over the last 100 years. That's why IQ tests need
periodically recalibrated.

~~~
arpa
thing is, the curve remains the same. Fat in the middle.

~~~
majewsky
Of course the curve will remain centered about 100, because that's how IQ is
defined.

------
retox
These lines sound like a recipe for scope/feature creep and never ending
development process.

>Never do requirement analysis. Never write technical requirements or
functional ones. If you do, you have already failed.

In that case, how do you know when the software is finished and your contract
has been fulfilled?

>Creative solutions are often holistic in nature, driven by first-hand
experience, discussion, interaction and... thinking. If you want a developer
to write a great piece of code, let him or her scratch the itch you're trying
to scratch.

So, you do all your thinking, without capturing anything, and then the
software is finished when the developer is bored?

~~~
qwertyuiop924
you missed the point: The point is, if the requirements for a piece of code
are so complex that you NEED to write a requirement analysis, that you NEED to
do anything other than plan out your code, and write it, than your software is
already too complicated. You need to narrow the scope. Lots of small systems
is better than one large system.

~~~
king_magic
Yeah, sorry, but real life software doesn't work that way. Real life software
is often inherently complex.

~~~
qwertyuiop924
I disagree. Complexity can arise through interactions between simple pieces of
software. Given, planning that out may be complex, but certainly less complex
than writing it all in one go.

~~~
king_magic
And I disagree right back at you :)

All you're doing is shifting complexity around. Don't want one big piece of
complex software? Fine. Break it up - now you have a bunch of simple pieces of
software that all need to work together in a complex manner. You still need to
plan for how all that works, and that often requires complex requirements.

It's not "certainly less complex". The total complexity of the system is still
the same.

~~~
qwertyuiop924
And I... Kind of agree? :).

You do have to plan out your software, I guess I kind of de ied that. I was
wrong. You were right. Take your victory dance, then sit down, I'm not quite
done yet.

>It's not "certainly less complex". The total complexity of the system is
still the same.

The total complexity of the system is the same, yes, but the GLOBAL complexity
of the system is significantly reduced: A lot of complexity is isolated, and
if the components interact through well-defined interfaces, you can treat each
as a black box (theoretically, once they work), and use them as building
blocks to build your system. Every programming paradigm, language, and system
in the last 60+ years is based around this idea, from structural, to OO, to
Unix, to Lisp, to Microservices, and on to the next craze.

So, I assume that this something you agree with. In which case, congrats,
you've convinced me.

~~~
collyw
How is it reduced if you have everything needing to communicate back and
forward? Sounds like more complexity to me.

~~~
qwertyuiop924
The components aren't necessarily separate apps, but even if they are, that
problem has been solved many times over. Take your pick: HTTP, raw sockets
(TCP or unix domain), ZeroMQ, RabbitMQ for larger projects, Shared Memory,
pipe(2) (and friends), hell, even message queues and semaphores, if you hate
yourself...

------
vintageseltzer
> ... it's not about gobbling together the right tools and do some plumbing to
> make it work. No, it's using tools to craft a work of art. Anyone not
> recognizing this is an inferior software developer by definition ...

So — if you don't prioritize your ego and personal sense of artistry over
accomplishing the task, you are an inferior developer? I would never want a
person like this on my team.

~~~
scottious
I mean, I guess that's one way to interpret what he's saying... I interpret it
as "have an eye for design and creativity to solve your problems, don't just
be mindless and glue together frameworks and libraries". I personally think
this is compatible with working on a team.

I've far too often seen code that does look like it's just a bunch of
libraries glued together and if you really teased it apart you'd end up with
something that's a lot less code and a lot fewer dependencies. And I
definitely know people who wouldn't think twice about just adding another
dependency to a codebase just so they could use one function. Sometimes that's
justified, sometimes it's the result of lazy thinking.

------
Mimu
I'll never understand comparing code to art. Not the first time I'm seeing it
but for me it couldn't be further apart.

There is no best way to make a drawing. There is no best way to make a movie.
There is no best way to tell a story. There is no best way to make a painting.
There is no best way to create a song. ... There is (almost?) always a best
way to do a piece of code. Code has nothing to do with emotions. I'm not
trolling I truly don't get it, like at all.

~~~
Neener54
This is a dubious assertion. Best is fundamentally a subjective metric. Code
is only the best for a given set of criteria. What's best code for rapid
development isn't best for maintainability. Sometimes you have to break
maintainability for speed bottlenecks. Saying there's a best way to code
something is a very contextual claim.

------
oldmanjay
I don't mean to be purely negative but this is so wrong as to be harmful. My
one solace is that my marketplace competition may read this and thereby make
themselves less effective pursuing some silly ideal of purity while I'm busy
getting shit done.

~~~
btilly
Absolutely.

This looks to me like a developer who is frustrated that nobody listens to
him, who wrote a manifesto saying that everyone should do things in the way
that HE thinks they should be done. Reading through the manifesto, it is
obvious to me why nobody is listening to said developer.

------
keithb-
This is fantastic; the perfect example of tilting at windmills. So, I'll take
up the role of Sancho.

Using tools to craft a work of art? I'm sure some projects deserve our
collective accolades, but no one should consider them art. The only projects
that should end up in a museum are those that are no longer in use.

Risk of bugs increases with each piece of code? I'm sure this is impossible.
The risk is already 100%: there will be bugs. They only increase in volume.

Always be wary of fancy websites? I'm sure the rant preceding this nugget has
a point (e.g. maybe "never compromise on code quality), but let's be honest: a
fancy website is a work of art, See #1.

Withstood the tooth of time? I'm sure these mixed metaphors are meant to be
poetic, but when you lead with a statement followed by an exception, then your
whiskey spigot can engender an acreage of Hidalgo.

------
nmalaguti
Software Engineering is an exercise in compromise. How does the risk of a bug
compare with the benefits of the code?

I think it's fair to say that there is more code being written today, by a
more diverse group of people, than ever before. It would be a real shame to
tell them the amount of code they should be writing is 0 since that's the only
way to prevent bugs.

------
rnernento
Lost me here:

"Therefore, our true purpose is to express the intentions of our clients using
as little code as reasonably possible, accompanied with lots of documentation
and lots of tests (testing code and unit tests don't count as LOC). We should
distrust every line of code written by ourselves as well as those written by
others. The best code has 0 lines. Because in zero lines of code, there is
room for exactly zero bugs."

Less code does not necessarily mean less bugs.

~~~
SeanDav
Less code does absolutely mean less bugs, _in the majority of cases_. Of
course it is not an absolute rule and can be gamed, but simple logic dictates
that since it is not possible to always write 100% bug free code, the more
code one writes, the more chance there is to introduce bugs.

However I don't believe the statement was meant to be taken entirely
literally.

~~~
rnernento
Then why do I spend so much time fixing bugs in code where the concept was
complicated to the nth degree so it could be written in five lines instead of
ten?

I agree that fewer lines of code is better, unfortunately if you hold that
concept in too high a regard it's easy to make a mess. Some programming
challenges are complex and the complexity can't be avoided. Sometimes solving
that problem in fewer lines of code makes the problem even more complex. Just
because the complexity is moving from the code itself into the developers head
doesn't NECESSARILY mean that it will be less prone to bugs.

~~~
mordocai
Those 5 lines probably had 100s if not thousands of lines backing them. Maybe
best to say 'fewer lines of code executed' as it doesn't really matter whether
those lines are in a library or in your project, they still have a chance for
bugs.

~~~
rnernento
You're missing the point, it's not about executed code it's about concepts and
simplicity.

Sometimes people work too hard to make two functions with slightly different
objectives into a single complicated function. This can save lines of code
since you aren't writing two similar functions. In general this is good
practice but it's VERY common to take this too far, and it's very likely that
the resulting complicated function will be MORE prone to bugs than the two
simpler functions would have been.

------
sanxiyn
"It does not matter how many people use framework X."

Unfortunately, it does. It sort of makes sense Manifest Against Mediocracy
includes such statement, since this is the large impediment in fight against
mediocracy, but simply asserting it doesn't make it true.

~~~
codingdave
It was not simply asserted. It was supported with an example of a security
problem that would be experienced by everyone using a framework. We've seen it
in reality, with the left-pad fiasco.

~~~
k__
This really was a fiasco.

We went from big frameworks to a bunch of libs.

Many people got into extreme and even used stuff like left-pad.

I try to only include third party software for stuff I don't have the time or
skills to implement. This makes my utils directory a bit bigger, but that's
it.

------
neogodless
I really think you mean "mediocrity" or "the quality or state of being
mediocre" rather than "mediocracy" or "a dominant class consisting of mediocre
people, or a system in which mediocrity is rewarded."

I say this because you're trying to "give developers a code to live by that
will increase the quality of code and coders." However, you're not talking
about a "dominant class" or a "reward system." So I think the word choice is
off.

------
gravypod
I personally don't think this is the correct way of looking at this situation.

Good code as it stands is code that produces an application that fulfills the
requirements without breaking until someone naturally thinks to replace it. If
you can achieve that you can achieve something better then most "good code"
I've seen in my lifetime.

Good code is something that isn't obtrusive to the end user (the most
important user of the code).

I don't know of another way of putting this but "easy to maintain" code is a
different thing. Some small piece of software could have been messily globed
together and thrown into production. This piece of software could have been
running for 15 years+. I still think that's good code, but it is not
inherently "easy to maintain."

We shouldn't be striving for 1 goal, we have two that are close to similarly
important. We have maintainability by a programmer, and you have ease of use
from the client.

To make the small fraction of people who are software devs live's better, we
focus on "easy to maintain' code. To make everyone's life better we need to
focus on that and making functionally sufficient code.

Very few projects I've seen do both. They either aim to be 100% clean code
while sacrificing features that greatly improve UX or either 100% functional
while being globed together unorganized messes.

I think we need to think of good code as a project that fulfills it's entire
reason for existence while being documented and maintainable (on both the UX
and maintaining side of things).

------
BasDirks
Nonsense and wisdom are so well balanced in this piece that I can't decide
whether this is a joke or not.

------
qwertyuiop924
This is either brilliant, or excellent satire. Which one it is depends on how
you define the terms. There is good advice here, but if you take it literally,
and don't pay attention to context, and use common sense, you'll end up with
some really bad advice.

------
mathgeek
> Anyone not recognizing this is an inferior software developer...

No True Scotsman at its finest.

~~~
sleepychu
We can all agree that real programmers don't eat quiche though, right?

------
JohnLeTigre
Personally, I would have gone further.

Somehow people forgot the old Ethos of being a programmer working on slow
machines that had only 8k of ram or so. This would train humility, the art of
writing small and efficient code, etc.

Now kids implement factories all over the place when they are not needed
(amongst other patterns), it's a pattern galore really. As if they used fancy
data structures regardless if they are needed or not just to float their ego;
reassuring themselves that they do know tons of stuff.

ah well... Sorry for that rant :)

------
codeulike
Some of you seem to be missing the satire here.

~~~
noir_lord
"Any sufficiently advanced satire is indistinguishable from magic" or
something.

It's certainly brightened up my Wednesday reading the comments on here.

------
crpatino
I could write a toughtful response to that... but given the quality of the
original, this will suffice:

Eight

Be skeptical to any advice from a developer that is not old enough to have
grown some white hair. If the advicer is male, gray beard preempts other white
hair.

Nine

Be actively hostile to any advice by male developers that ar not old enough to
have grown a beard at all.

------
DoubleMalt
A manifest against mediocracy in software developer by a PHP developer. Start
with dropping PHP. SCNR

------
british_india
There is a typo in the link. The corrected link has a 'o' added to the end, as
in:

[http://gabordemooij.com/index.php?p=/manifesto](http://gabordemooij.com/index.php?p=/manifesto)

------
hknd
php developer talking about "It does not matter how many people use framework
X." and "Never do requirement analysis. Never write technical requirements or
functional ones. If you do, you have already failed."

Trolling at its finest.

------
daveloyall
I stopped reading 14 words in because gobbling != globbing.

For that matter, manifest != manifesto.

Probably English isn't the author's first language. I should forgive him and
carry on, but a quick scroll reveals the words idiot and whiskey. TL;DR

~~~
neogodless
...and mediocrity != mediocracy.

~~~
DonaldFisk
Corrections to the article have been made, and it is now at
[http://gabordemooij.com/index.php?p=/manifesto](http://gabordemooij.com/index.php?p=/manifesto)

The power of peer review!

~~~
daveloyall
Nice. Peer review continues: wortless.

Uh, I kinda like the tone, but this guy might not be familiar with the decades
of math and engineering that back something like Haskell.

It's true, there's an art to writing software, but...

Tools (practices, ideas) that have been honed and refined to the point that
they are reflections of physics and logic aren't to be dismissed.

Those tools are to be wielded by artists!

------
kgu87
Mediocracy or mediocrity?

~~~
return0
I think he refers to the tyranny of popularity-based development.

------
Ace17
"The best code has 0 lines. Because in zero lines of code, there is room for
exactly zero bugs."

Does failing the acceptance tests count as a "bug"?

------
kyleblarson
I picture him glowing with a strong sense of superiority while sitting in his
bedroom in his parents' house writing this.

------
coldcode
Is the proper term "Manifesto"? A Manifest is a list of things included in
something, like a bill of lading.

~~~
dalacv
[http://bfy.tw/6w16](http://bfy.tw/6w16)

------
hoangtg
In part Five: '...If it's init system is systemd, oh well...'. what's wrong
with systemd?

------
king_magic
This reads like it was written by someone without much experience in building
real-life, large-scale systems.

------
nice_byte
> No, it's using tools to craft a work of art.

Stopped reading right there

~~~
angersock
Then you did yourself a disservice, and now have trumpeted your laziness and
ignorance.

------
return0
Magnificent, where do i sign?

------
_pmf_
Ctrl+F "customer" -> zero results

Did we forget a little detail here?

~~~
vetinari
The term "client" is being used (once):

> Therefore, our true purpose is to express the intentions of our clients
> using as little code as reasonably possible, accompanied with lots of
> documentation and lots of tests (testing code and unit tests don't count as
> LOC).

