Building A Software Toolbox
We’ve found that looking for parallels between web development and other industries can be a great way to clarify our processes or best practices. We create websites; tradespeople create buildings. In either case experience, skills, tools, and raw materials are used to build something that meets certain needs. So what can we learn from the trades?
One key to success as a tradesperson is choosing the right tools and building a standard toolbox. Expert carpenters have well-worn hammers, saws, and drills in their toolbox. Ours just happen to be code snippets, libraries, and software packages instead of hammers, saws, and drills.
Working with the same tools and building mastery with those over time allows us to:
- Implement and build sites efficiently.
- Predict potential problems and know the solutions to mitigate those problems in advance.
- Manage sites in a more standard manner.
- Develop in-house expertise that’s easy to replicate on future projects.
Just as a carpenter wouldn’t buy a new saw every time he cuts a piece of wood there isn’t a good reason to arbitrarily change our software toolbox. We consider changes if the needs of a project won’t be met well with our standard tools. Typically these cases involve:
- Technical requirements our standard tools don’t meet.
- Availability of a new tool that’s substantially better than what we’ve been using (cheaper, faster, better).
The key for us is working to attain mastery with our standard tools. We’re proud of our work and understand that it reflects who we are, so we strive to do the best job we can on each site we build. Knowing our tools and using them to the fullest is one way we realize this goal.



March 17th, 2007 at 6:30 pm
Good points. As far back as my first Powerbuilder and Visual Basic class, it was always stressed that you shouldn’t try to rebuild the wheel. Re-using existing code not only saves time, but avoids erroneous errors from miskeying if you’re in a rush. In addition to using a few open source solutions for various solutions (database abstraction, for example) I also keep my own custom library of functions that I tend to use in all of my projects, plus a set of starter template pages (html, css and js files along with some php include files) that allow me to start plugging in content right away. In the case of my own common files, I’ve found that it’s a good idea to synchronize the files back into my common source folder at the end of every project. This way, any changes that I made to the common files (new functions, better documentation or just bug fixes) will be available the next time I start a project using them. If the changes are significant enough, I’ll also synchronize the changed files to any old projects that used them (with a fair amount of regression testing of course).
March 23rd, 2007 at 5:22 pm
I’ve seen Eric’s tool box, it’s all HyperCard!!!
April 20th, 2007 at 11:24 pm
Ha!
HyperCard used to be my toolbox. But after it hadn’t been updated in 12 years I finally put the ‘ol HyperCard down for some ClarisWorks love.
Now where’s my Commodore 64 tape drive…?