Development Tip

7 Replies

1. damonp adds this Comment:

   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.

   June 29th, 2005 at 7:38 pm

2. microISV adds this Trackback:

   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…

   June 30th, 2005 at 5:44 am

3. Elaine Nelson adds this Comment:

   I hear that…although I suppose you are reaping some benefits of my follies in that arena, given our move to Tasks Pro.

   June 30th, 2005 at 9:14 am

4. Andrew adds this Comment:

   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.

   June 30th, 2005 at 5:27 pm

5. Kevin Dangoor adds this Comment:

   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.

   July 3rd, 2005 at 12:44 pm

6. Alex adds this Comment:

   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…”

   July 3rd, 2005 at 10:07 pm

7. Kevin Dangoor adds this Comment:

   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.

   August 27th, 2005 at 4:37 am

Add a Comment

Please note: Use of a non-personal web site or blog in the field below and/or comments that are off-topic, personal attacks, or support requests will likely be removed at my discretion.