Shame-driven development

The real driving force of open-source software quality.

Rafał Pocztarski
λ𝑥.
4 min readOct 27, 2015

--

Burdened by shame by John Hain, Creative Commons Attribution License.

This is a typical thought process:

  1. I have the best idea ever.
  2. I need to write some code.
  3. It works.
  4. I am so amazing.
  5. Oh, wait. I forgot about an obvious problem.
  6. Now I see that this code is useless.
  7. I am so stupid.
  8. Screw it.

And then you forget about it and do more important things. Not much harm is done. But if you carelessly add one little step to this, it suddenly changes everything:

  1. I have the best idea ever.
  2. I need to write some code.
  3. It works.
  4. I am so amazing.
  5. I’ll put it on GitHub and npm.
  6. Oh, wait. I forgot about an obvious problem.
  7. Now I see that this code is useless.
  8. I am so stupid.
  9. I must fix it before they notice!!!

And then you furiously write more code to fix this problem discovering more problems in the process. You take into account all of the weirdest edge cases. Your code is no longer elegant with all those hacks and patches, you no longer enjoy looking at it, but now it’s too late. You can’t unpublish it. Someone might have already cloned your repo. Someone might have already installed it. Your only hope is to fix it before bug reports with outrage and insults start coming your way like crazy, because you know — you know very well — that those eyeballs are watching.

So you write more code, documentation, tests, you improve error handling, you test it in different environments, other operating systems, you work on test coverage, you set up continuous integration, you add a ton of those little icons that must be green no matter what, the more the better. Then you start compulsively refreshing your issues page. And what about more important things? What can be more important than that!

At that time you become a slave of your own code that you once used to love for a very brief moment.

Even if you fix everything, it doesn’t matter. From now on, when you are falling asleep and suddenly realize that you are missing a semicolon in your JavaScript code, you will not be able to sleep until you add it, commit, npm version patch, git push origin master and npm publish. Unless of course you don’t like semicolons, in which case you will not be able to sleep when you realize that you have a semicolon where it is not needed. Either way, you’re screwed.

Based on Shame by Frankieleon, Creative Commons Attribution License.

The high quality of open-source software is usually described like this:

“Given enough eyeballs, all bugs are shallow”

But I argue that this is not the whole truth. If GitHub ever introduces statistics on how many people read every line of your source code (let’s call it eyeball coverage) I suspect everyone will be very disappointed. I bet most of it would be just you and your regular contributors, if you have those.

Additionally, for projects like underscore and lodash there may be people from competing projects who will bend over backwards to show you that your code is crap. But not everyone is fortunate enough to have people like this who do all the hard work, following the principles of hate-driven development (which we will discuss at some other time). Most of us don’t write lodash and underscore. For most of people it’s just you and your own shame.

This is what I think is much closer to the truth:

“Given enough eyeballs, all bugs are shameful”

The shame by Grey World, Creative Commons Attribution License.

And this is the essence of shame-driven development. The real driving force of open-source software quality.

Thanks for your time. Now go fix your code because I saw one line in your GitHub repo that is just pathetic.

--

--

Rafał Pocztarski
λ𝑥.

⭐️ Senior TypeScript/Node.js Developer, Tech Lead at Beesafe by Compensa, Vienna Insurance Group. I build custom backend APIs for the InsurTech industry.