You don’t want to be fixing bugs

Spend your time creating, learning and innovating instead

Decide what you want to spend your time on

Our goal as developers is to build high-quality software, something that we love to do. On the other hand, we don’t want to be fixing defects that interrupt our great work.

Don’t get me wrong, I‘m not saying that we should shift our attention away from defects. I’m saying that we need to build better software now so that we don’t spend our time fixing avoidable defects in the future.

Let’s have a look at the following facts…

Fact 1: Fixing defects is a must ❗️❗️❗️

There is no software without defects. And fixing them is a high priority. Defects mean low-quality software and dissatisfied users. Therefore, we always need to take care of them.

Fact 2: Developers don’t like fixing defects 🙇🏽‍♀️🙇🏼‍♂️

I didn’t go to college to learn how to fix bugs 🐛, and neither did you. Defects are interruptions to do what we are meant to do, to develop. We want to write new code, learn cool stuff and spend time on innovative ideas.

Fact 3: Time is super valuable ⌛️= 💎

We are always struggling with time. There are so many things to do, build and test new features, keep up to date with technology, think on new ideas, debug and fix defects... It’s critical that we use our time wisely. And we don’t want to spend all this precious time fixing bugs.

Fact 4: Humans make mistakes by nature 😅 😅

We will always make mistakes, it’s human nature and won’t change. Since we are imperfect, we need to get into continuous improvement mode and be less imperfect daily. Defects will always exist but there is a lot under our control. We can improve our software quality consistently to reduce the bug amount.

In short…

We know how important fixing defects is, but still, we don’t like it. It’s the result of low-quality software and an interruption to use our valuable time on creating new things. We are imperfect and we accept it, however, we can get better every day in continuous improvement mode.

Get Carlos Parreño Bonaño’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Now I ask you, what are you going to do? Would you like to spend the rest of your days fixing bugs 🔧🐛 or building high-quality software? 🔮 🧞‍♂.

Get into Continuous Improvement Mode

Defects are just the result of low-quality software. We are software developers and high-quality should mean everything to us (we don’t deliver 💩). If we don’t want to spend the best years of our lives fixing faulty code, we need to build better software.

But what determines high-quality software?

We cannot improve what we can’t measure. Hence, here goes some common factors that determine software quality and have a big impact on the time you will spend fixing defects in the future.

1. Lines of code: There is a correlation between the number of defects and the number of code lines. Less code = less defects. It’s critical to promote code reusability vs duplication.
2. Testable code and test coverage: Sometimes writing a test for a piece of code is a real hassle/impossible due to the code complexity and a symptom of low-quality. Your code must be testable and the test coverage should be as high as possible.
3. Console warnings and errors: Watch out for warnings ⚠️ and errors ❌ in the console. They are indicators that something went/can go wrong.
4. First rendering and response times (Performance): These are key factors in terms of usability and user experience. Measure the performance times.
5. No 3rd party vulnerabilities (Security): Watch out for vulnerabilities on your dependencies. You should also construct an efficient security policy.
6. Responsiveness and platform compatibility 📱🖥: Our apps need to be served to a variety of devices and platforms. We need to make sure they are properly tested across different browsers, screens, O.S, and devices.
7. Accessibility and internationalization: We need to make sure that people with disabilities can use our software and it’s available in different languages based on the user location.
8. Extensibility, maintainability: Having a good architecture 🏰 that allows us to easily maintain and extend our software is crucial for long term projects. Clarity and simplicity are key.

Techniques to build high-quality software

1. Think long term from day 1: Establishing a good foundation will determine the quality of your code in the future. We need to think about reusability, extensibility, and maintainability. It’s important to have the CI pipeline in place asap so that we build software in the right direction. Sometimes things such as performance, accessibility, testing are postponed until the project is stable, which is not a good idea. The more you postpone these things the harder it will get and, even worse, the longer you will be fixing defects 😩😩😩.
2. TDD — Test Driven Development: Here is your best friend 🐶. You write your tests first, which must fail. Then, you implement your code to meet the test requirements and pass the tests. We all are sceptical 🤨 about it because it’s a 180-degree switch and seems very expensive. However, you will see the rewards in the long term. Your code will be testable and 100% tested, you will have a better architecture 🤩 and less code 😍. You might be concerned about investing so much time with this approach, but you should know that in the medium/long term TDD will overcome the traditional approach by far. Here there is an experiment.
3. Effective code reviews with checklists: An effective code review is the responsibility of both, the developer and the reviewer. Developers 🧞‍♂️🧞‍♂️ should ensure that pull requests are small (as the code increases, complexity does as well and the review efficiency will decrease). It’s also important to self-review your code changes before submitting them for review, as well as adding an explanation to your changes and how to test them. The reviewer 👀 should understand the code logic and look for defects and possible enhancements. Using checklists 📝 ✅ will ensure the quality steps are taken (E.g. unit tests/a11y tests/documentation have been added, no console errors, tested on all supported browsers, etc.) It’s very important to be respectful and understanding when giving/receiving feedback. We are all on the same boat 🚢, and we all own the team's mistakes, failures, and successes.
4. Automate and improve your CI pipeline as much as possible: Your CI pipeline is an automated checklist that will ensure quality. Automate, automate and automate, your time is so valuable and anything that can be automated will save you hours/days. Things such as checking the style of your code (linting), adding quality tools, run unit, integration, acceptance, visual and regression tests, security scans, and much more can be automated. Continuously improve your pipeline so that low-quality code does not pass through 🛑✋.
5. Retrospective and feedback: There is no continous improvement mode without retrospective. In self-directed and team retrospectives we analyze ways to improve. It’s also important to point out and recognize the good work. Feedback can help the team improve since they add a new perspective. Ask feedback to users, designers, managers, and other developers. Then, use it well 🤔, meaning that you should consider their point of view and decide if it has value to you.
6. Continuous learning: The fundamentals of continuous improvement. Learn from articles, books, courses, colleagues or conferences, and most importantly, learn from your mistakes. Remember, Continuous Improvement = Continuous Learning.

The final results

So, let’s assume that we started a new project and we did the following…

• We thought long term from day 1 and worked well in our foundations. That is, architecture, testing, a11y, security, and performance were taken immediately into consideration.
• We used TDD to write code that we delivered in small pull requests. Code that was properly reviewed and followed a checkpoint list to make sure that we met our quality standards (for example, we checked that the new front-end code is responsive and works on all supported platforms).
• A CI pipeline was in place and enabled with the very first piece of code. We then continued extending our project, which remained compliant with our quality standards.
• We learned from others, gathered feedback and carried out retrospective sessions that helped us to continuously improve the quality of our software.

The results we get:

• We thought at a very early stage about having good foundations and a strong CI pipeline, so we end up with less code and a better architecture easier to maintain and extend as a result. Our code is accessible, internationalized, secure, and we took care of the performance times at the right time. 😌😌
• We did TDD, so our code is 100% tested and of course testable (there will be no hassle to write tests in the future ). 😍😍
• We delivered small pull requests, properly reviewed and following our checklist, so we have no console warning/errors, and the new code works well across different browsers, screens, O.S, and devices. 👏👏
• We learned from ourselves and from others, which helped us keep improving and build higher-quality software which of course turns into fewer defects. 🎉 🎉

Also, some of the results that we don’t get:

• Defects from non-tested code or code that is impossible to test.
• Fixing the same thing in tones of different files due to duplicated code.
• Full sprints fixing a bunch of accessibility defects.
• Sluggish software, the result of an accumulation of performance issues.
• No time to learn anything new.
• A job that we don’t like 😞.
• “I could keep going all day 😂.”

Conclusion

All the above sounds good, doesn’t it? And more important even, we are also investing our precious time doing what we like, building high-quality software, learning and thinking on innovative ideas to keep improving. Along the way we will encounter defects, it’s the downside of being human (we make mistakes), but all we can do is to accept that and try to get better.

In my last words, I’m going to repeat this, “You don’t want to be fixing bugs”. With this work philosophy, I moved from saying “work is work” to “I’m passionate about my work”.

“You may say I’m a dreamer, but I’m not the only one. I hope someday you will join us, and the world will live as one.” John Lennon.