I think a distinction should be noted
between 'doing it right' and 'capturing the business logic correctly'. The latter obviously amounts to meeting the actual project requirements, and usually entails multiple phases of delivery (just typed 'devilry' by mistake, whoops - how Freudian) and testing by the client. Anyone with development experience will tell you that 'meeting the spec correctly' often does little but satisfy a need that was incompletely defined, or has drifted in the interim while you were developing the solution. You might even have enough for sign-off but you are unlikely to have met all the client's actual expectations.
If you ask me, 'doing it right' is a measure of which of the myriad ways you chose to solve the necessary problems as you perceived them at the time. I'm speaking of the age old question of when a piece of software is complete - 'when it compiles' being the classic misinterpretation of this concept. I frequently find I've cobbled together something that compiles and even does the job correctly, but needs rationalising into a properly delineated application.
Whether this means commenting, refactoring, assembling proper classes, or simply tidying your first clumsy attempts to use a new technology or feature after a few months experience, there is much that can be done to improve the efficiency and - dare I say it - elegance of the code. This is what reduces the ongoing support and extension burden for future work.
