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.
What's your opinion?
The post On usefulness over accuracy in dev – the broken clock conundrum. appeared first on Leo Gopal.
Top comments (1)
This reference comes to mind:
en.wikipedia.org/wiki/Perfect_is_t...
which frequently applies to software where there is always some other way to achieve a goal, and knowing when to look again at how things are done is hard (hint - use an external property / fitness function like cost of ownership aka return on investment or happiness of the team maintaining stuff!)