You’re right that my “this” was a bit vague. My point about automated testing was specifically in response to “propping things up in ugly ways”. If you have automated tests and refactor well as new needs arise, then the code won’t get ugly.

“Tak[ing] the extra time to lay a good foundation” could be interpreted as “big design up front”. It could also be interpreted as “put in lots of good tests, so that you can change the code as needed”.

I don’t go for trying to lay a foundation that can handle every possibility… I’ve worked with code bases like that, and it’s a nightmare. Every little change needs to support a myriad of possible options.

I’d rather have a foundation built on solid testability than one built on anticipation of expected future needs.

At times I’ve found that my planned designs don’t match well. Hence I tend to build a good core for the current functionality and leave the rest to tend itself when required. Thats not to say that you don’t plan ahead if you have a solid idea of where next.

Note this is specific custom software for clients. But I have had the benefit of several iterations of the same functionality. Budget, resources and time constraints varied each time.

It amazing how often this is not done but this tip is right on the money.

When you’re building something (not just prototyping), take the extra time to lay a good foundation. If you don’t, you’ll spend waste a lot of time in the future proppin…

Smaller jobs I find usually don’t require the same percentage of time in pre-coding work. Small jobs you only have to think a day or two ahead.