Spiria logo.

The three laws of... developers

December 6, 2013.

I’ve been reading Asimov’s book lately and it made me wonder, what those three laws should be for a developer?Here’s what I think : A developer will not write unreadable code, code that break software or, through inaction, allow code to become messy. A developer must meet the requirements given by the client except where such requirements conflict with the First Law A developer must innovate as long as such innovation does not conflict with the First or Second Laws. 

I've been reading Asimov's book lately and it made me wonder, what those three laws should be for a developer?

Here's what I think :

  1. A developer will not write unreadable code, code that break software or, through inaction, allow code to become messy.
  2. A developer must meet the requirements given by the client except where such requirements conflict with the First Law
  3. A developer must innovate as long as such innovation does not conflict with the First or Second Laws.

A little more details

A developer will not write unreadable code, code that break software or, through inaction, allow code to become messy.

We should not produce bug, that obvious. But we also must not write code that only the author understand. When you write code you should ask yourself "The developers around me, will they be able to understand this?". The answer should always be "Yes".

And for the last part, when you update code that is not yours, and you find that it is very hard to understand or you even find a bug that was not filed, you should fix that code. It will be good for you and any other developer that will have to do maintenance on that part of the program.

A developer must meet the requirement givin by the client except where such requirement conflict with the first law

It happens all the time, a client wants a new feature and it is for yesterday. The thing is if you start writing messy code and tell yourself "I will fix it later"... well... chance are that you are not going to fix it later. That is why you should always respect the first law.

You should talk to the client and ask him what part is really important or is there a way to simplify the requirement or why is it so urgent. There will always be a way to deliver functionalities ask by the client without rushing your code.

A developer must innovate as long as such innovation does not conflict with the first or second laws.

There is always place for improvement. Either by learning new framework, new tools, new best practice, new architecture, new language... there is a lot to learn. You can also look at you latest project and ask yourself "How could I build this better?".

But, when you are working for a client, you should not deliver feature not asked by the client just for a testing purpose.

I believe that when starting a new project, you should try new things, but if it's taking to long or if it doesn't work, you should have a backup plan which you know is working and is easy to implement.

Final thought

I don't know if three laws is enough to define a developper, but there's one thing that I'm sure of... I hope were never gonna be replace by robots.