There is a wrong & there is a right. Something either works or it doesn’t. Every issue I can see _must_ be fixed before I could even begin to imagine I’ve achieved acceptable, let alone perfect! I’d like to say I used to think like this but the truth is a still do. I see issues in everything I look at, I see problems with everything I’ve built, I see flaws in every solution I’ve dreamt up. So how did I end up achieving perfection? It was more I realised that no matter how good my answer, I was simply answering the wrong exam question. I realised that perfection is not something the engineer gauges quantitatively, but rather, it is a word that is used to sum-up the subjective experience of something being truely fit-for-propose.
For instance, your hammer at home isn’t perfect. It may have blemishes, it may be a little wonky, it may be old, it may be a bit short, bit long, bit heavy, bit light, <whatever>, but is it fit-for-purpose! It is very useful if you need to put a nail into a piece of wood & you may well quite like it in general as you value that utility - it is truely fit-for-purpose.
This concept (fit-for-purpose) refers to solutions that are suitable to be integrated into someone’s / a business’s task flow. This implies that the solution has sufficient:
robustness (works in a broad gambit of cases),
reliability (works the same way & at the same level of performance regardless of the extrinsic factors), &
simplicity (easy, seamless, frictionless, ID-10T user proof, etc to use).
We get into return-on-investment / utility-of-use type territory here. The path of least effort = the path of maximum potential benefit = the path of the least / zero new risk = the path to get the ‘best’ job done = _must use_ products / solutions / technologies.
The next level down, fit-for-purpose is matched with a understanding of:
use-case (how, when, where, why people need to use it?),
user-needs / problems (what is the problem, what could they use help with? What could be easier to do? Surely there is a better way!),
user-preferences (how do they want to be able to interact with, control, set-up, etc it),
user-reactions (if it does something odd how do the users react? To bin it? To give it a second chance? Can we foresee possible adverse reactions and mitigate our solution’s behaviour so that we are more likely to get a user’s shoulder shrug than the bin?),
business-realities (What is the most adoptable technology out there? What is already ubiquitous? What singular points of failure do we have with our component selection? We should aim to minimise existing ones & not introduce new ones. For instance, incorporating a sensor that is only available from one specific supplier adds dependency to that supplier / technology; when that is altered we must do more work just to keep our legacy system running), &
application space factors (Operating temperature range, times of day, indoor / outdoor / mixed, clear-dusty, still-vibrating, etc.) determines a tangible spec.
This takes some breathing and acceptance. Yes, I believe tech is very very important & that solutions need to be build on a solid base of substantive solution. I also accept that the gauge of value in a solution belongs to the recipients of that solution; it needs to work-for-them in order to work-for-them.
<the ubiquitous 'honest question'> ‘How do you look past all the issues you can see & seriously think your solution is perfect just because someone uses it?’. The only way I can explain this is that I have accepted, perhaps embraced, the associated cognitive dissonance. I can see the issues. I most often struggle to believe my solutions even work, let alone that they are perfect, I don’t think they are perfect - but - I can accept that when it is ‘do’, ‘build’, ‘create’ time my voice matters most, but when it is ‘end use’, ‘value’, ‘appreciate’ time my voice matters considerably less than the users in the target group & I can accept their call on it as the ground truth.
<the insight> Clearly there is a lot of tech-user-business strategy wrapped up in that simple phrase; fit-for-purpose. This is what I am pointing at, something that took me a long time to realise, something vital that helped me understand why I could never measure something and consider it ‘perfect’; I was measuring the wrong thing. What am I trying to achieve, to meet my own impossibly high standards? To make sure I lose every single hair and grind my teeth down to the gums? No, I am an engineer. After much reflection I can clearly & confidently say I am trying to make something useful. I achieve perfect by focusing on the right exam question - there is no higher prize than to hear in no uncertain terms from the person I made it for that it is useful!
(Don’t worry, I can’t let it go, there is no perfect, I tend to take the win above but to use my list of the faults I see as a to do list for the next iteration)