Live data from Hacker News

Anti Mediocracy Manifesto for Software Development

gabordemooij.com

91–100 of 110 posts

Re: Anti Mediocracy Manifesto for Software Development

#91
post #8

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, interactio…

Somewhat related, "The Agile process of software development is often perverted by sick politics"

http://www.smashcompany.com/business/the-agile-process-of-so...

Re: Anti Mediocracy Manifesto for Software Development

#92

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

...and mediocrity != mediocracy.

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

The power of peer review!

Re: Anti Mediocracy Manifesto for Software Development

#93
post #15

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 fol…

> This is not the profession of saints and Buddhas. 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…

There lies a difference between Bodhisattva and Buddha. What you described while explaining the difference between Buddhas and saints is essentially the difference between Bodhisattvas and Buddhas :)

And Bodhisattva is a lifestyle by choice.

But then again, what do i know. I barely follow the eightfold path.

Re: Anti Mediocracy Manifesto for Software Development

#94
post #15

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 fol…

Being mediocre is a choice. It's the choice of the lazy and unemployed.

Sir, may I please look at your horse? It seems pretty high, would you step off it, please, and face the reality?

Re: Anti Mediocracy Manifesto for Software Development

#96
post #30
post #15

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 fol…

> all natural distributions follow that curve 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…

>A large number of natural distributions follow a power-law distribution.

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

Re: Anti Mediocracy Manifesto for Software Development

#97
post #8

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, interactio…

I've yet to meet a requirements document that was good enough for both parties to agree that the contract had been fulfilled. It's almost always come down to browbeating or going unpaid.

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.

Re: Anti Mediocracy Manifesto for Software Development

#98
post #42

Earlier quoted context omitted.

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.

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 m…

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.

Re: Anti Mediocracy Manifesto for Software Development

#99

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 ze…

Less code does mean less possibility of bugs.

Re: Anti Mediocracy Manifesto for Software Development

#100
post #30

Earlier quoted context omitted.

> all natural distributions follow that curve 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…

>A large number of natural distributions follow a power-law distribution. 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 N…

Agreed. The old saying is "anything looks linear when plotted on a log-log graph."

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

Post reply on HN