6 ms·

I would go even further and say that if the result is good enough for the requirements, it's not half-arsing, even if the result could be made better with more

I would go even further and say that if the result is good enough for the requirements, it's not half-arsing, even if the result could be made better with more time and effort. In other words an outcome will be judged based on expectations and consequences, and not compared to "the best it could be" (unless someone expects it to be the best it could be). This highlights the importance of naming and terminology: if I say I will "prepare a report" people will expect one thing versus "throw together a few visualizations". Of course if it's the CEO it's inappropriate to just throw together a few visualizations. This shifts the issue from execution to alignment of expectations, which for me has the benefit of not feeling I'm doing a half-arsed job.

kqr 6y ago
> I would go even further and say that if the result is good enough for the requirements, it's not half-arsing, even if the result could be made better with more time and effort. Ooh, both I and professor Deming would disagree with you there. It is not enough to just meet requirements. The thing you're building is going to become a component in a very complex system, and all the nuances that matter there are impossible to capture in a specification. If it just conforms to specification, someone will need to file it down to be able to slot it into the right place, and it'll still only go with excess friction and thorny edges. To create something that actually works and makes users happy, one has to go beyond the specification, understand and optimise for the system it is going into.