We recently decided that we were going to rip out our 4 foot high picket fence and replace it with a 6 foot privacy fence. The biggest challenge through the whole process lay in removing the concrete encased fence posts for the existing fence. If you have ever tried to remove an irregularly poured chunk of cement from the ground, you’ll be able to attest to the backbreaking difficulty in doing this with only a shovel and muscle. I really wasn’t looking forward to hours of arduous work so I decided to work smart instead of hard.
I decided to build a contraption to help me out and remove much of the physical exertion from the process. The basic design (not fully depicted below) was using pressure treated 4×4’s so that I could reuse them for the new fence. The uprights are 8 feet tall, each foot is 4 feet long, and the top cross beam is 2 feet wide and the whole structure is held together with 1/2 inch lag bolts. I then placed a 1/2 inch eye bolt through the cross beam so that I could attach a come-along. Add a matching eye bolt in the fence post and I had a great way to wench the posts right out of the ground. I simply rocked the posts a bit to loosen them up then used the contraption to rip them out of the ground.
My contraption. I forgot to take the picture…
Turns out I was working smart, but not as smart as I could have been. I neglected to take the weight of the contraption into account and how I was going to move it from post to post. So I had this great mechanism that would save my back from the exertion of ripping out posts, only to strain my back by having to move it. I estimate it at around 100 pounds, which isn’t too bad in itself, however the unwieldy nature of such a large structure posed balance problems in addition to weight problems. Had I thought the entire process through, instead of focusing on just the main problem, I would have come up with a better design. Perhaps casters, handles, or even a bottom cross support so that I could use a dolly were in order.
The same paradigm rings true for business in general but it resonates especially loud in the software industry. We often design features, applications, and bug fixes with the intention of solving the problem at hand. While our approach may be smart in that it solves a large problem, keeps the problem from coming back, or takes into account the possible future needs, it isn’t always the smartest solution.
A great example comes from a small contracting business I once ran. Many of my clients wanted much of the same functionality as each other. So instead of rewriting or even copy and pasting code from one client to the next I decided to write a modular based system. This system was ant based and simply took a properties file as a build argument. The properties file would list the images to be generated for the site, the style sheets to use, the modules to be built, and even the scripts to run against the database during deployment. This system allowed me to write modules that were self referencing with respect to their dependencies. So I could drop in the users module and the client site would now have full support for user management, complete with authentication code. This users module would understand that it was dependent upon the security module and the security module was dependent upon the core module. All would then be included in the final build simply by including the users module.
The solution was smart. It kept me from duplicating a lot of work, but it wasn’t smarter. I finally realized a problem in that the system allowed no room for conflicting options. If client A and client B wanted different and conflicting things from the same module, which eventually happened, I was back to square one. In order to accommodate such disparities I would either need to copy and paste modules or build in very complex configuration functionality. Had I worked smarter from the beginning I could have foreseen some of these problems and taken steps to circumvent them. I won’t go into details on how, as most of them would require a deep understanding of the module based system’s inner workings. Instead, it is sufficient to note that there were other design options that would have yielded the same scalability without the technical nightmare of conflicting demands.
Always work smart. Strive to work smarter.
