Begin with a clear goal

I started the project with a simple goal: Clean out the garage

Now that I’m done, I realize there is a better word for it than ‘clean’. I refactored my garage. From Wikipedia:

Code refactoring is the process of restructuring existing computer code — changing the factoring — without changing its external behavior. Refactoring improves nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve source code maintainability, and create a more expressive internal architecture or object model to improve extensibility.

I didn’t change its external behavior or its key ability-tos (storing things including 2 cars), but I reduced complexity, improved maintainability and made it more extensible (freed up or created more storage space).

The why

Over the years the garage had become disorganized, marginally usable and the cruft was visible wherever you looked. I’m sure you’ll find no relationship whatsoever to any applications or code you’ve worked on.

There were bugs. Literal bugs and a healthy ecosystem of black-widow spiders to eat the bugs. While I’m all in support of the circle of life, I prefer it to be on the outside, rather than the inside of my house.

This is Part 1. Other parts are here: Introduction, Part 1, Part 2, Part 3, Part 4, Part 5, Conclusion,Epilogue

The plan

The plan was to take everything out of the garage and sort it into 3 piles Clean Sweep style:

• Keep
• Toss
• Sell/Donate

The way I generally describe a garage cleanout is that I’m “voting everything off the island.” If something wants to come back, it has to fight its way in by proving it is useful.

Incidentally, that’s the approach I take for rewrites of features or modules as well, but that is an article for another day.

I had my plan and at that point I was just going to work the plan. Some decisions to make along the way, but mostly just work.

Finding inspiration

A few weeks ago I was at a friend’s house and he’d recently cleaned out his garage and installed shelves over his garage doors. For most garages this is just wasted space, and my garage was no different. Seeing his completed project inspired me to do the same thing with my garage. I realized that adding shelves fit nicely with my overall goal of having a clean garage. Even though it would add scope to the project, the payoff would be worth it.

Sometimes all you need is to see someone else solve a problem similar to yours to get the creativity flowing. For me, had I not seen the shelves, I still would have cleaned out the garage, but wouldn’t have had enough space for all the big, bulky, seldom-used items like tents and tarps.

This is a key point for software development. My goal was to clean out my garage. Without the new “feature” of the overhead shelves, I would have still accomplished my goal of cleaning the garage, but it would have been a less complete solution. My solution may have been acceptable in the short term, but in terms of maintainability and future flexibility (I’ve now got 2 empty shelves for later), I’m glad I was inspired to do it differently.

This is why it is critical in software development to expose yourself to new ideas. Most of the time you can achieve your goals with the tools and ideas you already have. But often the addition of a new idea or concept will enable you to achieve your goals and produce a better solution.

And although new ideas are important, it is critical is to keep your main goal in mind. This prevents you from getting distracted by the shiny new idea and causing your project manager (or in my case wife) to worry if the original goal will be completed on time. And, keeping an eye on the main goal helps you know when to call “done” on the new idea.

Again, thanks for reading. Next time I’ll get into the planning and analysis for the shelves.