Down the Rabbit Hole to Build Perfectly Designed Software

I am a software craftsman. I teach and advocate building high-quality solutions using the techniques of readability, reusability, and maintainability. But there is a point of no return. There is a ledge that we walk on where the act of building perfectly designed software solutions can sacrifice the objectives of the project. If we are not careful, we can fall deeply into the rabbit hole.

The Quest for Perfection as a Young Craftsman Apprentice

When I was thirteen, my stepfather and I built our home together. Well, he did most of the work and I helped him the best I could as he taught me about architecture, carpentry, and electrical. We spent months and countless hours together cutting each board, framing the two-story A-frame home, and crafting each substructure. Even in the winter, with the heat generator blasting hot air out at us, we worked away, hammers in hand, building, laughing, and learning.

I especially remember one day when he asked me to cut about 50 boards to a particular length. I wanted so much to impress him and show that his young apprentice was learning. I set up the table saw, measuring, remeasuring, and remeasuring again and again. Board after board, I measured and wasn’t satisfied with the result, as it wasn’t precisely the measurement he wanted. I was paralyzed seeking the elusive perfect cut.

After a long while, he came over. He asked me what was taking so long. He saw the frustration on my face and pile of cut boards on the floor. I was so defeated as I had wasted all of that lumber and time. I knew I had failed him.

He walked over and measured a few of the boards in the pile. He started laughing. He said: “These are good enough. Why are you so frustrated?” I explained that they were not perfect. He shook his head and said “Why do you think they’re not perfect? All of these are the dimensions we need.” I was puzzled.

First Software Lessons on the Quest for Perfection

Years later, I was building some code for a new inspection machine that was going into the ceiling plant assembly line. I had spent a week working on this code as I wanted to get it right and impress my mentor and the engineering team. I spent days studying their code and reading books on software construction and code quality. I was consumed by the quest for perfection in the design patterns that I became paralyzed, unable to move forward with the task at hand.

Linda, my mentor, finally put me out of my misery. She said to stop looking for the perfect design. Sit down and map out the process. Figure out the steps and flowchart it out. Then take the boilerplate we have and change it for the machine’s flowchart.

Stop being paralyzed searching for the perfect solution.

I followed her advice. The machine’s flowchart was done by the end of the day. I reviewed it with her. Then I wrote the code the next day.

Had I realized that they already had a standard and boilerplate for me to follow, the project would have been done in a day and a half. I didn’t need to reinvent the wheel. I wasted so many days.

These lessons in my young life and career stayed with me. I learned early on the perils of seeking perfection, as the quest reaches a point of no return.

Passing the Lessons On To My Team

Many years later, I was evaluating efficiencies, looking for patterns as to why my team’s project costs and timelines were so high.

Meetings quickly moved away from project tasks and progression to design patterns and code reviews of said patterns. Each person had a differing interpretation of what quality meant and how best to implement the goals of reusability and maintainability. Meetings became an exercise in mental muscle and posturing rather than resolution and project-centric innovation.

Hmmm, there’s the pattern. Our team was stuck on the architecture and code design. They were stuck in “analysis paralysis.”

The perils of perfection will waste your time and increase costs.

The next meeting started with a story from me. That day, we talked about the perils of perfection and how it wastes time and costs at the expense of the project and team.

As a team, we sat down and selected the beginning stages of our standards. We picked a direction and then moved forward with the project.

Analysis Paralysis. Stop spending so much time seeking the absolute perfect way to do something. Click To Tweet

Building Our Standards, Libraries, and Processes

Over the coming months, we tasked ourselves to develop our standards as a team, separate from our project workload. We removed the paralysis. We moved the mental exercises from the project-level and to a Committee tasked with a single objective.

We focused on identifying how our team works, our culture, how we build and test, and how we maintain it. We built our standards, processes, and libraries to fit the way we work. We built them in a such a way to augment and support us.

Build processes, systems, and workflows to support the way you work and make you more efficient and effective.

We built a library of well-tested modules, each of which we could plop into our projects, reconfigure, and move on to the next task. And as we built a new module for a project, we added it to our library.

We refocused ourselves away from seeking the theoretical and elusive perfect design pattern that is completely reusable in all situations to one that fit the way we work. We worked together, pulling our expertise and history, to develop what we needed to build our projects.

What Was the Result?

All projects started with our standards and boilerplates. We actively used our libraries and processes. As a result, our costs significantly decreased.

We spent our time solving the problems of the project and building and testing the solution. And in doing so, we spent our time focused on maximizing the needs of the client to build the right solution.

From that point forward, our team kept adding to our libraries, standards, and boilerplates. We worked together to improve how we build software and adapting it to how we work.

We refocused ourselves on innovation and our clients. We increased the return on investment (ROI) for our company and our clients.

It’s a win-win for everyone.

Changing Your Mindset

As engineers, architects, and programmers, we are not wired to think about costs or return on investment (ROI). Rather, we think about all things technical without thinking about that we cost money and how we do our job costs money too.

I’ve met very few engineers and software professionals who balance their focus on building profitable solutions.

We go so deep into the rabbit hole that we blind ourselves to its true costs.

I can still hear the bellows of my teammates complaining about the budget and timeline. They see these metrics as a restriction to limit their creative work. I can hear them cursing the Project Managers and Account Managers. Technical people want to focus on the technical.

When someone talks to you about a project, I bet your mind immediately starts sorting through the possible technical solutions. Am I right?

Your job is to build the right solution that maximizes your client’s and company’s ROI.

But the technical is only part of this profession and our responsibilities. We go so deep into the rabbit hole that we blind ourselves to its true costs to ourselves and our team, project, company, and client.

Listen to me. Your job is to build the right solution. But it’s also your job to build cost-effective solutions that maximize the return investment (ROI) for the client and your company.

Software is costly to build and maintain. It is. We have to think about the costs of what we build as well as how we build it. Our entire process needs to be fine-tuned to support these objectives.

Costs and ROI Matter

Costs matter. ROI matter. Why? I have stories to share with you about teams who have built amazing products and systems that could not be supported, maintained, or find a market because they were too costly. I’ll share those at another time. For now, let me share a few insights with you.

Here is where I typically can lose a few technical people. Stick with me. Ready? Ours is a profession and a business. Costs and ROI Matter. Quality Matters. Seek balance.

Ours is a profession. We are paid to do our work. Therefore, it is also a business. The business needs to make money. Cost reductions are important. Money, time, and value are critical components that we are responsible for building into our systems. It matters.

Quality Matters. But Perfection is a Myth

Over the years, I learned there is a point of no return. We, technical professionals, reach a point where we limit our ability to move forward. It’s not a matter of accepting subpar code or performance. No, quality matters.

But the quest for perfection is a myth. It’s not achievable. The act of working to achieve it is fruitless and costly.

There is no perfect design pattern. There is no perfect project. There is no perfect code.

Instead, we need to change our mindset and think about the costs of what and how we build. We need to build processes and workflows that support our work and help us to do it better and faster.

You need to become a profitable developer. In doing so, you will make yourself invaluable and highly marketable.

Become a profitable developer to make yourself invaluable and highly marketable. Click To Tweet

Stop Spinning Your Wheels and Move Forward

How often do you spin your wheels stuck on the layout of a web page? I bet you’re chuckling right now because you know it’s true. How much time have you wasted trying to figure out which local web server appliance to use? I bet you’ve spent time researching and stuck on whether to use Grunt or Gulp. How much time have you spent dissecting the perfect workflow and pipeline?

Listen up. Stop spinning your wheels. Stop and look at what you’re doing and how you are doing it.

Stop spinning your wheels and wasting time. Build your processes to support the way you work.

Ask yourself what processes you have in place to support your workflow and the way you work. Tools are meant to save you time and money. They speed you up. And it doesn’t matter which ones you pick, as long as they support you and help you to be better and faster.

I can’t tell you how many lengthy discussions I’ve had with people about the so-called proper way to build code.

It doesn’t matter if you build it with Ruby, PHP, or Python. It doesn’t matter if you build using functional, procedural, or object-oriented programming design paradigms.

The choice of language or tools doesn't matter, as long as each makes you faster & better. Click To Tweet

Wrap it Up

I am not suggesting that you stop learning or seeking to improve your codebase. I am in no way saying that quality or craftsmanship don’t matter. If you think that, then you’ve missed my point.

You can build high-quality, well-tested solutions that maximize ROI for all. Quality does matter. Absolutely. But so do costs and ROI. You have to balance the technical and business objectives.

Stop and analyze how you work. Seek ways to improve your efficiency and effectiveness. Develop your workflow, processes, tools, and libraries to support you and make you better. Keep growing your expertise and proficiencies. And watch out for paralysis and wheel spinning.

Perfection is not possible. But you can build high-quality, well-tested solutions that maximize ROI for all.

Seek to build the right solution that maximizes your client's & company's ROI. Click To Tweet