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 propping things up in ugly ways.
Take the extra time. You’ll thank yourself later.
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 propping things up in ugly ways.
Take the extra time. You’ll thank yourself later.
If I estimate 100hrs on a job, I plan on spending 15-20 hrs of that spec’ing out the database, protoyping/laying out the main functions and then re-evaluating it all. Thats all before any hard core coding.
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. 😉
Development Tip: Alex King
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…
I hear that…although I suppose you are reaping some benefits of my follies in that arena, given our move to Tasks Pro. 😉
Good advice. However I’ve found that I can’t always forecast where a piece of software is going to go.
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.
This is also why I (and others who have done extreme programming) advocate having automated test suites. It makes it far easier and more practical to make sweeping changes, because you know you’ll be able to get everything working again.
I don’t disagree, but I don’t understand how you’re tying that in to this post. What is the “this” in “This is why…”
Sorry for the belated reply here. I just stumbled across this post again.
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.