Anti Mediocracy Manifesto for Software Development
gabordemooij.com
gabordemooij.com
No, they don't. Many approximate that curve. Others do not. For examples:
"Bimodal distribution of flowering time in a natural hybrid population of daylily (Hemerocallis fulva) and nightlily (Hemerocallis citrina)" - http://link.springer.com/article/10.1007%2Fs10265-005-0241-3 .
http://psychology.wikia.com/wiki/Bimodal_distribution lists other bimodal distributions: "the time between eruptions of certain geysers, the color of galaxies, the size of worker weaver ants, the age of incidence of Hodgkin's lymphoma, the speed of inactivation of the drug isoniazid in US adults, the absolute magnitude of novae, and the circadian activity patterns of those crepuscular animals that are active both in morning and evening twilight"
A large number of natural distributions follow a power-law distribution. https://en.wikipedia.org/wiki/Power_law#Examples gives many examples.
That said, you do not need that broad claim to make your argument.
This is surprisingly debatable. People like to find power-law/scale-free distributions because it implies a neat generative story, but a lot of the "evidence" for power-law distributions is pretty weak. For example, you cannot just show that a log-log plot is linear--lots of other distributions can produce similar plots.
Clauset, Shalizi, and Newman have a very readable paper where they describe 1) how to properly test for a power-law distribution, and 2) use those tests to assess the validity of some claims from the literature (spoiler: not many have "good" statistical support). Here is the paper: http://arxiv.org/abs/0706.1062 Shalizi has a short blog post describing the main results: http://bactra.org/weblog/491.html
However, the OP was giving a rough approximation in the first place, in saying that all natural distributions follow a Gaussian curve. But Gaussian curves go from -∞ to +∞. Many of the real-world distributions must only have positive values, like heights and weights. Although for real-world purposes, they can usually be approximated as Gaussian.
With that roughness in mind, I think it's okay to say that the Stefan–Boltzmann law, the inverse-square laws of Newtonian gravity and electrostatics, or Kleiber's law, which are all listed in the Wikipedia link are close to a power law to be acceptable counter-examples.
(Stefan–Boltzmann assumes a perfect black body, the inverse-square laws ignore relativity, and Kleiber's law is a rule-of-thumb in the first place.)
For a while though, it was en vogue to find power law distributions in all sorts of weird places (email response times, numbers of friends), and that's what I was attempting to object to!
I think that in pretty much all cases, you'd be better off just taking that architect and telling him to write the code. If you don't think you have enough good people to do the amount of work you need to do with that approach, you're trying to do too much work.
It's about mindfulness towards our own product. "Mediocrity", in this case, is turning a blind eye towards our own limits. All people have the ability to overcome this form of mediocrity.
It's a choice, not a lifestyle.
Full enlightenment, or being a Buddha, is the realization all of this around you is Buddha Nature. Each individual is capable of attaining enlightenment in a single moment, given choice is made in very similar moments throughout the day. When you decide to believe it, you do so in a timeframe that is non-measurable. Like many people I know in SV, I believe we're running in a simulation. This belief could be viewed as equivalent to a type of enlightenment.
On the other hand, saints are beyond this reality and are "holy" in nature. Holiness means they have been re-integrated with the supreme wisdom, or all knowledge. Some call it the fucking oneness. Aldous Huxley called it the "burning brightness of unmitigated Reality". Technically, they are enlightened, but they are outside what we HERE can consider as Buddha Nature.
I liken these two concepts to security through obscurity. We don't know the proper protocols to realize that we are all the same thing and refuse to think about the fact we'll all be reintegrated into the brightness when it comes for us.
And Bodhisattva is a lifestyle by choice.
But then again, what do i know. I barely follow the eightfold path.
>the middle of the gaussian curve is fattest; all natural distributions follow that curve
>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?
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.
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.
Never mind that thoughtfulness of design is a requirement to understanding complex distributed systems. And before we go off saying that few developers need to know how to program distributed systems consider that even a modern processor is a tiny distributed system.
This idea that genius will spout forth from the hands of the programmer in the spur of the moment is hogwash. If you believe this then let's make a wager. We'll pick a simple, standard algorithm. I'll give you the requirements, you implement it. I'll model your solution and run it in a model checker. I bet you that the checker will find an error in your implementation. Simple, right?
A colleague of mine did this to his students. They had to implement binary search. The majority of their solutions had bugs. These weren't under-grads.
Programming is hard because thinking is hard and we deserve the best tools we can find to help us think clearly and precisely. In the real-world we can always just add a fudge-factor to make up for our uncertainty while computers are infuriatingly discrete systems.
This flow of "thinking in code," is simple-minded ignorance. Think in code all you want. You won't be able to solve the hard problems that way. You'll just write sloppy code.
... </rant>
Requirements analysis is also critical when the software is coupled to particular hardware or a particular process.
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.
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.
http://www.smashcompany.com/business/the-agile-process-of-so...
What that requirements document is is a license to withhold payment until the contract obligations are met, no matter how ruinous those obligations are because of inattention to detail and the customer's complete lack of ability to state clearly what they want.
I think one of the biggest things us developers misunderstand about Agile is that it involves a contract that says you pay me every month for a month's worth of work. If 8 months into a 12 month project, the customer decides they don't like us, we've already cashed 8 checks and are free to pursue other projects. At worst I have 8 months of money and I have to scramble to find new projects for my team.
With the typical up front big design the customer just refuses to write a check until you've fulfilled their handwavy interpretation of the requirements, which mean whatever they want them to mean this week. We could easily be on month 20 still hoping to get our second check for 6 months' of pay. Essentially we're chewing people up and bankrupting the company in the process. It's a sucker's bet.
Lately I've gotten even more cynical. My new thesis is that companies that know how to ask for what they need and can break problems down into reasonable and measurable parts don't usually hire out work. They have all the necessary skills to just open job reqs and get their code written. The people who hire contractors seem to almost universally do it because they don't have the faintest clue how to spec and write a piece of software. Including doing the requirements. Especially the requirements. Be sure to quote them a rate that represents hazard pay, because there's gonna be drama.
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.
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.
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.
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.
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.
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.
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.
"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.
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.
However I don't believe the statement was meant to be taken entirely literally.
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.
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.
There's at least two bugs in a zero-byte implementation of /bin/true: it's too slow and it uses too much memory.
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.
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.
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.
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).
No True Scotsman at its finest.
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 :)
It's certainly brightened up my Wednesday reading the comments on 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.
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.
Trolling at its finest.
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
The power of peer review!
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!
Does failing the acceptance tests count as a "bug"?
Stopped reading right there
Did we forget a little detail 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).