Quality is non-linear

A friend of mine, a hard-worker who had very high standards for his own work, told me a few years ago: “I don’t understand why people don’t polish the details of their projects, it only takes a few hours more to go from decent to good”.

I think I fall in the set of people who try to get a working version of what they’re doing as fast as possible and not spend a lot of time after that refining things (if it’s “presentable” then it’s usually good enough for me). Sometimes it’s pure lazyness because it’s true than a couple hours more would take the work on a whole different level, but from my experience that’s not typically the case.

I’m looking at this from a programmer perspective, but I would say there’s a kind of 80-20 rule at work here: if you already know what you’re doing, it usually doesn’t take much time to get a very basic version, but from there to a “presentable” version it can take a lot more time. You need to be much more intentional in finding bugs, things that don’t look good, unexpected user input and behaviour, and so on.

This is not big news: another way to put it is “The devil hides in the details”. I think this is true for pretty much any creative endeavour, but if you’re working in software development and you need to estimate the amount of work that you need to put into some project, this is my advice: think of how much time you need to get to a basic version and then triple it. This will take you closer to the real development time for the “final” version of the product.

 
0
Kudos
 
0
Kudos

Now read this

Design for errors

I’ve been recently working on the frontend of a web application, basically I had to add a tab to a tab panel and do some stuff there. One of the requirements was, of course, “be careful not to break the other tabs because they’ve been in... Continue →