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 TweetBuilding 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.
Think about that. When your costs go down, profits increase. When you are focused on building the solution and not just the act of building it, then you have more time to focus on the solution as well as testing. You reduce the costs throughout the project’s lifecycle while maximizing the solution for the client.
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 TweetStop 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 TweetWhat matters is that:
- you pick the tools, develop the processes, and build a library that supports the way you work, helps you to build faster, and makes you better;
- you are proficient in the entire process;
- you develop both your technical and business mindsets, expertise, and processes;
- you identify, build, and deliver the right solution that maximizes your client’s and company’s ROI.
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
This is an incredible piece, Tonya! I can so relate to a lot of it. Perfection is a curse and innovation is messy. I still fight with this every day.
Hello Ahmad,
I was talking with Carl on Facebook earlier today about this too.
The engineer in me struggles with this too, just like you and all other technical professionals. We are wired to analyze, solve, refine, and refine some more. We want it to be as perfect as possible.
But the business woman in me knows that there is a sliding point where we step over the ledge. There really is such a thing as “good enough” while being high quality, innovative, and achieving the objectives. There is a sweet spot.
Many times though, we go too far before any actionable work is ready. It stalls out the process as we sit and spin.
In a team, the manager or team lead is charged to see it and then help to get the team moving forward again. But when you work alone, there is no one to recognize it and then take action to move you forward.
Many people in WordPress work alone or on very small teams. The article is to help us to recognize the signs and it’s impact.
Here’s a little secret: I do it too. We all do. Sometimes I’m late to stop myself. But when that happens, I stop and note what happened and why. I use it as a learning experience to fine-tune my processes.
Great piece! However, there is a danger in caving into the “you are trying to build the perfect solution” argument.
I had a PM who helped me see that “cost matters” – but in a bad way. At first, we were in the good pattern you mention, where he would tell me “don’t try to develop the perfect solution, we don’t have time for that”. The usual “we’ll fix it later / add it to the technical debt” argument prevailed. Initially that was useful, as it helped me keep focused and out of the rabbit hole. But I think that also sent him a wrong message.
I think he understood that I could develop whatever he wanted at whatever cost he wanted. He started becoming more and more aggressive with his estimates. No matter what estimates I gave him, he would just impose his own overly optimistic time estimates (he still does that, to everyone on the team; he asks us how long it will take (to pretend he’s actually considering our input) and then says “I think you can do it in X, what do you think?” [X being 1/2 or 1/3 of the time you said] and I always say that it’s optimistic and he always says “let’s just keep the estimate as X and see how it goes”, and then when X is around the corner he just tells us to wrap things up and push what’s left to the “technical debt” backlog). So I started feeling like I had no choice but to deliver poor quality, in order to meet his insane deadlines. Every time I tried to suggest a quality solution, the answer was always “we don’t have time” or “you are trying to build the perfect solution”. The message I received was “there is no time for/ we don’t care about quality”.
It was very hard for me to fight against his attitude. First, because he is the PM, so I really have no control over the deadlines. Second, because I had found this job (which pays me minimum wage btw – despite my 16 years of experience in the software industry) after being unemployed for almost a year, so I couldn’t afford to cause too much rift between us.
With time, I got tired of arguing that “we need to do design and architecture before jumping into coding” (and other basic quality things like that), because the response was always “don’t try to be perfect”/”we don’t have time for design/architecture”. I eventually let his “cost matters” argument to dominate in detriment of software quality. Now their application is a Frankensetin full of bugs and falling to pieces. They’ve tried (unsuccessfully) to push it to production for more than a year now, but something always breaks. My motivation is at its lowest, which has been dropping my productivity and quality even more.
I’ve had similar experiences in other companies too (but not as bad, in terms of poor quality software developed by my team). For me, when a manager says “don’t try to build the perfect solution”, what I hear is “we don’t care about quality”. So I stop caring too.
I am not proud of my attitude, but I honestly don’t know what to do. I don’t don’t know how to stand up for quality when the counter argument is always “we don’t have time, I’m the boss and I will tell you what we will build”. And being paid minimum wage doesn’t really encourage me to care.
Anyway, I just wanted to vent and show you guys that the “don’t try to build the perfect software” argument can have its downsides too.
There are those who will push costs over everything else. It’s a balance. If costs dictate everything, then there will be no return-on-investment as innovation, quality, and solving the right problem all suffer. That’s why I said “quality matters.”
Before one single line of code comes out of your fingertips, the first step is to think and architect. Without this step, costs increase as the design can suffer, bugs get introduced, and then maintenance costs increase. Balance.
Lastly, PMs should work with the technical staff to seek input for work breakdowns, estimates, and buy-in for the project. It’s a team effort that requires all cogs in the wheel to turn together.
I’m sorry that you have a PM with no regard for quality or an understanding of how costs actually increase in the environment and culture you’ve described. I’ve fought that battle myself before too. Luckily I was able to have my voice heard as soon as we talked about the rising costs factor.
Thank you for sharing.