DEV Community

Cover image for On usefulness over accuracy in dev - the broken clock conundrum.
Leo Gopal
Leo Gopal Subscriber

Posted on • Edited on

On usefulness over accuracy in dev - the broken clock conundrum.

Here is a thought experiment. Imagine two clocks; both analogue.

The first clock is broken. But in terms of accuracy its exactly correct twice a day.

The second clock is a minute off; technically, it's the most useful one; but it's never exactly correct. But it's the one thats useful.

I see coding and the technologies we use to be of a similar fashion - and that too the religiosity of "standards" and "best practices".

I think its far better to be more frequently useful, even if we may not yet be doing what is seen as the correct or right way...

Be useful is more important than being right and problematic.

Get it done, then on to the next and do that better.

Top comments (3)

Collapse
 
endy_tj profile image
Endy Tjahjono

Interesting. Do you have any examples?

Collapse
 
leogopal profile image
Leo Gopal

Great question, and what incited this thought was a very broad/general acknowledgement of all of the new tools and trends that are constantly flying past us. The need or pressure to learn these new tools/technologies sometimes means that a lot of us will be adept at using a tool but never truly being an expert at it.

And sometimes, something really needs to get done; and done (even if buggy) I would always consider better than perfect. Purely by having the experience and acknowledgement of the business value of time to working/fixed/released products. There may be a "better", "faster", "more secure", "more robust", "more something..." way to have done it... But getting there is time in which the system is not useful to anyone... and what is the cost of being useful and imperfect or getting to perfection and the customers have moved on.

Though, like everything, there are valid arguments such as technical debt and saving future time time which may be greater to refactor an existing imperfect system, but from experience in many companies this valid argument rarely happens in reality if the version of done is of at least a minimum quality too.

If that balance is there, I would always opt for imperfectly useful sooner than perfectly useful tomorrow.

Collapse
 
endy_tj profile image
Endy Tjahjono

I got what you mean now. Agree. We can improve the codebase later as long as we survive the current problems.