Every business today is a technology business. Whether it supports your business model or itself is the business model, your technology stack plays a key role. What your engineering team ships, and how they ship, has direct and measurable consequences for your business, even if they traditionally prefer to think otherwise. Engineering goals are now closer than ever to business goals, and understanding that will help companies thrive in the business technology world today.
The idea of software craftsmanship dictates that the profession of software engineer should be analogous to that of civil engineer. Increased professionalism (in the style of Uncle Bob) suggests that software engineers' work should carry the same weight, and their failures the same consequences, as physicians and civil engineers.
These are noble goals for software engineers, especially if you are building software to operate a bascule (draw) bridge! Unfortunately, they are challenged daily by business managers who just want functionality, but may not care about the underlying mess supporting it; they think that engineers who constantly try to clean up that mess are wasting time chasing after esoteric technical standards. Engineers, on the other hand, want to always deliver and maintain quality work, and they are less concerned about the business and the end users. This lack of communication and alignment creates distrust and inefficiencies — it just doesn't work.
Code quality as a means to further your business
A better approach that more and more organizations — including GitLab — have embraced is lending a greater business voice to your engineering organization, and of course demanding greater responsibility. Have your engineering team communicate the benefits of maintaining quality code, and why the costs of increased engineering resources (people and time, typically) are justified by tangible business outcomes. Along with a clean and adaptable codebase, quality code allows you to:
- Add new features quickly
- Remove existing features since it's relatively easy to identify which code contributes to those features, and which does not
- Change existing features, for reasons similar to above
- Have a more stable platform with fewer defects and security problems, again due to predictability of your code
- Deploy code quickly, with fewer manual configuration steps, reducing the time from decision to when you go live
Note that all the benefits above are business benefits! Your software engineers already know these are possible and goals that they themselves already aspire to achieve.
Can you ever skimp on code quality?
The short answer is: it depends on the company. For mature organizations shipping well-established products, it's likely the market cannot absorb shocks or big changes in the product. Performance, security, and privacy are very important, especially for highly regulated industries. Code quality is crucial for these companies, and luckily, they typically have more resources to easily handle the cost of maintaining that quality. Code quality should always be the rule, with very little exceptions, and engineering and business should communicate along those lines.
In either a small startup or a large organization shipping a product quickly to compete, I'd argue that you can and should skimp on code quality. Engineers may not be a fan when reading this, but this draws on the concept of technical debt or tech debt. Sometimes a startup has to strategically incur tech debt to push out a product or feature update more quickly, to get the timing just right.
If you instead choose to maintain that 100 percent quality code, you lose out on the opportunity, and don't even have a business in 2 months, totally defeating the purpose of your software development in the first place. You'd have gained a beautiful codebase, but lost a viable business. Just as any healthy business regularly pays back old debt and takes on new, you need to clean up previously incurred tech debt so that your codebase doesn't slow down your business.
Engineering goals are business goals
In the past, engineers were often removed from business discussions. Business managers established requirements, and threw those over the wall to engineering managers who would reciprocate with delivery timelines. In today's technology-driven business landscape, that's no longer a viable option for success. Both parties need to work closely together in order to survive in a competitive software world.
Maintaining code quality is a great bridge in this effort, since engineers can easily articulate its practical benefits that are readily translated into positive business outcomes. You should continually analyze your business and take advantage of new tech debt as the need arises. There is a lot of technical nuance to this delicate balance, and so your engineering team should be presenting the options and offering a strong recommendation. Your engineers need to be strong business leaders.
Watch our webcast Code Review: A Business Imperative on demand. Watch here!
