[TikiTDO]

Having multiple modes of work is critical in the field. It's an unfortunate reality that the theoretical complexity of programming projects is limitless. Unfortunately that means you simply can not have sufficient resources to do things correctly. This is where the balance of not just approaches, but also development methodologies comes in to play.

Whenever I'm working on my personal project I do things that many modern developers would balk at. I'll design and redesign components left and right, I'll leave components in a half completed state, and I'll write the bare minimum of tests to ensure the system works. This is the risk that comes from approaching programming as an art-form. However, as any other artist, I will not go out there to show off my project until it's done, so I don't have to worry too much about pissing people off with my erratic style and questionable intermediate decisions.

On the other hand programming as a profession must be wholly different. If I am getting money for code the expectation is that people want to see whatever they're paying money for. In this case I don't have the opportunity to screw around and try to match the perfect set of ideas to the problem set. Instead I will give myself two or three iterations to do what I've been paid to do, and then I'll clean it up so it satisfies the technical requirements.

Fortunately the latter style of programming tends to lend itself a lot better to TDD, agile, responsiveness and all those other terms we love to throw around until our clients give us that blank stare. At the very least projects you get paid for should have some sort of spec, so you'll be able to say for certain whether you have or have not done what's expected of you.

[Chris_Newton]

Whenever I'm working on my personal project I do things that many modern developers would balk at. ... On the other hand programming as a profession must be wholly different.

Even when working professionally, different approaches fit projects of different scales. Processes and tools that keep you sane and productive if you’ve got multiple small teams to co-ordinate over a multi-year project could be absurdly over-managed and inefficient for a couple of developers at adjacent desks who are spending a month writing a bit of in-house automation software.

(Insert obligatory citation of The Mythical Man Month here. It’s about more than just why adding people can make late projects later.)