Engineering Best Practices Are Good for Business
Estimated 4 min reading time
A few months ago, I met the owner of another software development agency. He needed help getting a project over the line. "I just need to get the frontend done," he said. "I’ve got a great backend developer, but now the frontend is lagging behind the API."
Reluctantly, I agreed to provide one of Orbn DIGITAL's developers to assist. A week later, they got to work.
Fast forward to a recent 1:1 with my developer, where I checked in on the project’s progress. While I heard the usual complaints ("Angular is bad," etc.), something else stood out. My developer had been brought in solely as a “frontend developer,” tasked with implementing an API written months earlier. The lack of coordination between the backend and frontend caused avoidable delays.
For example, missing response data, limited query methods, and absent PUT endpoints meant raising tickets for backend changes. Features that should have taken a day or two instead dragged on for 5 or 6 days, burdened by context switching and communication overhead.
Here’s the kicker: this agency was billed a day rate. Poor engineering practices directly resulted in a 2-3x increase in costs.
This situation highlights the value ofvertical slicing. In software development, vertical slicing involves building features as a complete slice of functionality across all layers—database, API, and UI. Think of it like a slice of cake, with each layer (data, logic, UI) working together.
Vertical slicing minimizes inefficiencies like context switching and back-and-forth communication. It’s not just good engineering; it’s good business.
This experience got me thinking: what other engineering practices are both “good for business” and worth discussing with your technical teams? Here are three key ones:
Automated Testing
Automated testing—whether unit, end-to-end, or acceptance testing—involves writing code to test your code. Think of it as code that clicks buttons, validates messages, or ensures errors appear as expected.
It’s a clear business win: you write tests once, and they run many times, saving hours of manual testing. This enables faster releases and quicker feedback, helping you realize the value of your software sooner.
Bonus: Non-technical stakeholders can often review these tests, providing insights into what the software does (and doesn’t) do.
Continuous Integration/Continuous Deployment (CI/CD)
CI/CD automates the process of building and deploying software. Combined with automated tests, it ensures that only working code gets released.
The benefits? Fewer human errors, faster deployment, and software delivered to users sooner, enabling the business to realize value without unnecessary delays.
Feature Flags
Feature flags are switches in the code to turn features on or off - for all users, a subset, or specific groups. They can also enable A/B testing, where feature variations are shown to different user groups.
This flexibility allows businesses to:
- Release incomplete features without holding up other work.
- Gather feedback sooner.
- Incrementally roll out changes.
If this interests you, I highly recommendDouglas Squirrel'sSquirrel's Tech Radar. It provides a practical framework for business leaders to evaluate technical practices like these.
Meanwhile, I’m off to help finish that Angular frontend. Unfortunately, poor engineering management has already eroded much of the project’s margin.
Bye for now.
Struggling with delays and rising costs in your software projects? See how Orbn DIGITAL can help -Let's talk!