[gitonthescene]

All good decisions are a product of the particular circumstances in which they arise. This post seemed to be about generalizing that process which I would guess comes out of a supposition of fungiblity.

As much as one can use a given style for a personal project so can one for a professional one so long as it fills the given need. Too often (in my view) fungibility is seen as a preeminent requirement and layers and layers of self justifying processes are built on top of that. I’m only saying that’s a choice and the costs and benefits are not as obvious as most suppose.

Also you can minimize risks with redundancy but most presume those costs to be too high. But again this quickly becomes about politics.

[jacquesm]

I think the main question is whether or not you want to reach your goal and see programming as a means to an end or as the end itself. Usually, even when working on my own projects I have a goal, and the software is just a means to an end. So I tend to work on my own as though I am a team of one rather than that I am working 'just for myself'. This means I set up a whole pile of superstructure that isn't strictly a requirement, force myself to try to abstract as cleanly as I can think of and even refactor my code (when there is no project lead telling me to do so), write tests and abstain from trying to be too clever because it gives me better and faster results.

I'd imagine a chef or a competent musician would still use their hard won skill when cooking for themselves or making music for their own enjoyment.

[gitonthescene]

Who said code written in this style is lazy?