10 ms·

Anti Mediocracy Manifesto for Software Development

110 points by gabordemooij 10y ago

deleted 10y ago
[deleted]
granula 10y ago
At least grammar check your manifest(o)
rnernento 10y ago
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.
- taneq 10y ago
  That depends on how you measure code. If you're talking lines or statements, sure, but if you're talking concepts then the code with fewer concepts expressed must necessarily have less opportunity for bugs, if the number of bugs per concept is held constant.
  - rnernento 10y ago
    " The best code has 0 lines. Because in zero lines of code, there is room for exactly zero bugs." I read it as lines... I agree with what you're getting at, sometimes the concepts are a lot simpler and less prone to bugs when implemented in more lines of code.
    - dalacv 10y ago
      "the only winning move is not to play"?
- SeanDav 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
        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.
- st3v3r 10y ago
  Less code does mean less possibility of bugs.
- liw 10y ago
  The Unix command /bin/true (do nothing, exit with code zero) can be implemented as an empty file. When it's run, the kernel doesn't recognize it as binary code, so it gives it to /bin/sh to run. There's at least two bugs in a zero-byte implementation of /bin/true: it's too slow and it uses too much memory.
DoubleMalt 10y ago
A manifest against mediocracy in software developer by a PHP developer. Start with dropping PHP. SCNR
return0 10y ago
Magnificent, where do i sign?
coldcode 10y ago
Is the proper term "Manifesto"? A Manifest is a list of things included in something, like a bill of lading.
- dalacv 10y ago
  http://bfy.tw/6w16 http://bfy.tw/6w16
sanxiyn 10y ago
"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 10y ago
  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__ 10y ago
    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.
_pmf_ 10y ago
Ctrl+F "customer" -> zero results Did we forget a little detail here?
- vetinari 10y ago
  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).
- deleted 10y ago
  [deleted]
nmalaguti 10y ago
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.
retox 10y ago
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?
- gonzo41 10y ago
  Theres 'building castle from our minds' developing and then there's 'get shit done' developing. I'm kind of sick of so many devs fighting to try and outsmart each other. I'm looking at legacy code basses where people wanted to have a go at a technology and it just became an unmanageable abortion because they move on, support picks up the gig and then rot. Now I'm learning obscure technologies not in use by the majority of the bell curve because someone had a thought bubble. -- end rant. I'm all for the middle ground. Money flows to those who deliver.
- UK-AL 10y ago
  Tbh I know what he is saying. Software that is speced up by BA's and driven by their requirements tends to end up being really bad software. The best software is built up over time as demand arises for those features. Create the feature requests as they are required and implement the requests. I think one of the major causes of why this type of thinking ends up building bad software is that BAs include literally every corner case they can think of. Ends up being extremely complicated right from the start. Then they miss other requirements. If you build by evolving software from a simple beginning just to scratch an itch, you learn the true requirements from experience. Learning about the optimal architecture from experience as they go. Hard to do when your working off a software dev contract. Fairly easy to do if your building a product. It's cathedral vs bazaar.
  - vonmoltke 10y ago
codeulike 10y ago
Some of you seem to be missing the satire here.
- noir_lord 10y ago
  "Any sufficiently advanced satire is indistinguishable from magic" or something. It's certainly brightened up my Wednesday reading the comments on here.
- stronglikedan 10y ago
  I admittedly missed it up until "Never write technical requirements or functional ones." Then I started to re-read, and caught it throughout. Then again, I'm usually not even awake this early.
- pjc50 10y ago
  It's well into Poe's Law territory.
- GrumpyYoungMan 10y ago
  >Some of you seem to be missing the satire here. IMO, you're probably overthinking it. None of the other writings on the rest of the author's site suggests that any of the articles are meant to be satire or even that the author is capable of satire at this level.
kgu87 10y ago
Mediocracy or mediocrity?
- return0 10y ago
  I think he refers to the tyranny of popularity-based development.
vintageseltzer 10y ago
> ... 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.
- GrumpyNl 10y ago
  You dont get it do you?
- scottious 10y ago
  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.
- deleted 10y ago
  [deleted]
mathgeek 10y ago
> Anyone not recognizing this is an inferior software developer... No True Scotsman at its finest.
- sleepychu 10y ago
  We can all agree that real programmers don't eat quiche though, right?
arpa 10y ago
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 10y ago
  But surely the purpose of the manifesto is to skew that curve to the right.
  - arpa 10y ago
    One might as well try to skew global IQ stats to the right. And please, don't call me shirley.
    - CSMastermind 10y ago
      This has been happening over the last 100 years. That's why IQ tests need periodically recalibrated.
      - arpa 10y ago
        thing is, the curve remains the same. Fat in the middle.
        jackmott 10y ago
        But shifted right. This is good. Praise science.
        10y ago
hknd 10y ago
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.
keithb- 10y ago
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.
qwertyuiop924 10y ago
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.
Mimu 10y ago
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 10y ago
  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.
- ktRolster 10y ago
  There is (almost?) always a best way to do a piece of code. Nah....we can't even decide on a 'best' language to use. Or how to best indent, or where to put the braces, or what variable names to use. The code you write is a reflection of what's inside your mind, just like art.
kyleblarson 10y ago
I picture him glowing with a strong sense of superiority while sitting in his bedroom in his parents' house writing this.
king_magic 10y ago
This reads like it was written by someone without much experience in building real-life, large-scale systems.
oldmanjay 10y ago
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 10y ago
  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.
hoangtg 10y ago
In part Five: '...If it's init system is systemd, oh well...'. what's wrong with systemd?
BasDirks 10y ago
Nonsense and wisdom are so well balanced in this piece that I can't decide whether this is a joke or not.
daveloyall 10y ago
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 10y ago
  ...and mediocrity != mediocracy.
  - DonaldFisk 10y ago
    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 10y ago
      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!
neogodless 10y ago
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.
Ace17 10y ago
"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"?
nice_byte 10y ago
> No, it's using tools to craft a work of art. Stopped reading right there
- angersock 10y ago
  Then you did yourself a disservice, and now have trumpeted your laziness and ignorance.
gravypod 10y ago
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).
crpatino 10y ago
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.
british_india 10y ago
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
JohnLeTigre 10y ago
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 :)

110 points by gabordemooij 10y ago

deleted 10y ago

[deleted]

granula 10y ago

At least grammar check your manifest(o)

rnernento 10y ago

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.

taneq 10y ago
That depends on how you measure code. If you're talking lines or statements, sure, but if you're talking concepts then the code with fewer concepts expressed must necessarily have less opportunity for bugs, if the number of bugs per concept is held constant.
- rnernento 10y ago
  " The best code has 0 lines. Because in zero lines of code, there is room for exactly zero bugs." I read it as lines... I agree with what you're getting at, sometimes the concepts are a lot simpler and less prone to bugs when implemented in more lines of code.
  - dalacv 10y ago
    "the only winning move is not to play"?
SeanDav 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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.
st3v3r 10y ago
Less code does mean less possibility of bugs.
liw 10y ago
The Unix command /bin/true (do nothing, exit with code zero) can be implemented as an empty file. When it's run, the kernel doesn't recognize it as binary code, so it gives it to /bin/sh to run. There's at least two bugs in a zero-byte implementation of /bin/true: it's too slow and it uses too much memory.

DoubleMalt 10y ago

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

return0 10y ago

Magnificent, where do i sign?

coldcode 10y ago

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

dalacv 10y ago
http://bfy.tw/6w16 http://bfy.tw/6w16

sanxiyn 10y ago

"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 10y ago
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__ 10y ago
  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.

_pmf_ 10y ago

Ctrl+F "customer" -> zero results Did we forget a little detail here?

vetinari 10y ago
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).
deleted 10y ago
[deleted]

nmalaguti 10y ago

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.

retox 10y ago

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?

gonzo41 10y ago
Theres 'building castle from our minds' developing and then there's 'get shit done' developing. I'm kind of sick of so many devs fighting to try and outsmart each other. I'm looking at legacy code basses where people wanted to have a go at a technology and it just became an unmanageable abortion because they move on, support picks up the gig and then rot. Now I'm learning obscure technologies not in use by the majority of the bell curve because someone had a thought bubble. -- end rant. I'm all for the middle ground. Money flows to those who deliver.
UK-AL 10y ago
Tbh I know what he is saying. Software that is speced up by BA's and driven by their requirements tends to end up being really bad software. The best software is built up over time as demand arises for those features. Create the feature requests as they are required and implement the requests. I think one of the major causes of why this type of thinking ends up building bad software is that BAs include literally every corner case they can think of. Ends up being extremely complicated right from the start. Then they miss other requirements. If you build by evolving software from a simple beginning just to scratch an itch, you learn the true requirements from experience. Learning about the optimal architecture from experience as they go. Hard to do when your working off a software dev contract. Fairly easy to do if your building a product. It's cathedral vs bazaar.
- vonmoltke 10y ago

codeulike 10y ago

Some of you seem to be missing the satire here.

noir_lord 10y ago
"Any sufficiently advanced satire is indistinguishable from magic" or something. It's certainly brightened up my Wednesday reading the comments on here.
stronglikedan 10y ago
I admittedly missed it up until "Never write technical requirements or functional ones." Then I started to re-read, and caught it throughout. Then again, I'm usually not even awake this early.
pjc50 10y ago
It's well into Poe's Law territory.
GrumpyYoungMan 10y ago
>Some of you seem to be missing the satire here. IMO, you're probably overthinking it. None of the other writings on the rest of the author's site suggests that any of the articles are meant to be satire or even that the author is capable of satire at this level.

kgu87 10y ago

Mediocracy or mediocrity?

return0 10y ago
I think he refers to the tyranny of popularity-based development.

vintageseltzer 10y ago

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

GrumpyNl 10y ago
You dont get it do you?
scottious 10y ago
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.
deleted 10y ago
[deleted]

mathgeek 10y ago

> Anyone not recognizing this is an inferior software developer... No True Scotsman at its finest.

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

arpa 10y ago

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 10y ago
But surely the purpose of the manifesto is to skew that curve to the right.
- arpa 10y ago
  One might as well try to skew global IQ stats to the right. And please, don't call me shirley.
  - CSMastermind 10y ago
    This has been happening over the last 100 years. That's why IQ tests need periodically recalibrated.
    - arpa 10y ago
      thing is, the curve remains the same. Fat in the middle.
      - jackmott 10y ago
        But shifted right. This is good. Praise science.
      - 10y ago

hknd 10y ago

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.

keithb- 10y ago

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.

qwertyuiop924 10y ago

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.

Mimu 10y ago

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 10y ago
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.
ktRolster 10y ago
There is (almost?) always a best way to do a piece of code. Nah....we can't even decide on a 'best' language to use. Or how to best indent, or where to put the braces, or what variable names to use. The code you write is a reflection of what's inside your mind, just like art.

kyleblarson 10y ago

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

king_magic 10y ago

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

oldmanjay 10y ago

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 10y ago
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.

hoangtg 10y ago

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

BasDirks 10y ago

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

daveloyall 10y ago

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 10y ago
...and mediocrity != mediocracy.
- DonaldFisk 10y ago
  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 10y ago
    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!

neogodless 10y ago

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.

Ace17 10y ago

"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"?

nice_byte 10y ago

> No, it's using tools to craft a work of art. Stopped reading right there

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

gravypod 10y ago

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

crpatino 10y ago

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.

british_india 10y ago

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

JohnLeTigre 10y ago

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 :)