– Dan Silivestru, CEO, bitHound, says:
The struggle between developers and management is a tale as old as time. Developers accuse management of prioritizing speed over quality and management accuses developers of not putting enough emphasis on deadlines and delivery. At first glance, it would appear that these rival teams are ready to go to battle over the things they hold so sacred. However, if you look closer, you see that their goals are very much the same – deliver high-quality, maintainable software that their customers will love.
Having worked in a developer vs. management culture for many years, I’ve found three strategies that can help bridge the gap between developers and management, and help deliver the best software possible:
- Put yourself in the other person’s shoes.
The first step is recognizing each other’s objectives and frame of reference. Developers tend to look at the code and issue trackers then draw their conclusions. From there, developers seek to innovate and refactor the code in hopes to build a solid, maintainable product. Management, on the other hand, tends to look at product/project management, tooling and issuing trackers to help them understand how well developers and the code are performing. From there, management seeks to execute using the least amount of resources and time possible to meet their deadlines. Both frames of reference can work well together, as long as the requirements of the project match the resources and time available. However, realistically speaking, there are many times when quality is compromised for speed and vice versa, which is where the wheels start to fall off.
As a developer, understanding what the key deliverables are for your manager with respect to KPIs (Key Performance Indicators), deadlines, growth and features right out of the gate can be immensely helpful. If you can understand the bigpicture, you can show and explain to your manager why and how a refractor will help meet their goals in the long run.
As a manager, understanding your developers need to build solid, maintainable software is important. Developers aren’t just trying to get features out the door – they want to make sure that the code they write will survive beyond the next feature. For that, they need to continuously adapt the code to the news business needs and to help ensure it will grow with the product without the need for major re-writes. Developers do understand the need to meet deadlines. Allowing developers to keep track of the corners they cut and record them as tech debt, as well as giving them the opportunity to address tech debt (10-15 percent of time allocated) with each sprint is a great first step. If tech debt is selected according to features being worked on, it can be viewed as part of the feature and therefore more easily accepted.
- You have to go slow to go fast.
If we pick up from point one, we have developers saying they can refactor the code to build better software if given more time and resources. We have management saying they want great software but not at the expense of missing a deadline. These two competing notions not only serve as a major point of contention, but also impacts the health of the code. To avoid getting to this point, both parties need to understand that sometimes you have to go slow in order to go fast.
In one of Martin Fowler’s recent podcasts, he draws comparison to a runner maintaining their health:
“If you keep yourself healthy then you’ll be able to run faster. But if you just say: ‘Well, I want to run a lot so I’m therefore going to run a whole load all the time and not eat properly and not pay attention about this shooting pain going up my leg,’ then you’re not going to be able to run quickly very long. You have to pay attention to your health. And same with the codebase. You have to continuously say: ‘How do we keep it in a healthy state?’ Then we can go fast because we’re running marathons here with codebases. And if we neglect that internal quality of the codebase, it hits you surprisingly fast.”
This is a perfect metaphor for the work that needs to go into maintaining code – if you prioritize health and longevity from day one, you will set yourself up for long-term success.
If you start writing tests from day one, features may not go out as fast as you or as management intended but as the system grows, you will start delivering even faster than you would have without the tests.
On the flip side, let’s say you choose speed and delivery over code health to appease management. While it may not hurt you with the first feature, continuing to do so makes it more costly and makes the system less flexible, requiring hard patches each time something needs to be fixed. Going this route can not only impact delivery cadence, but also severely impact the organization.
- When in doubt, let the code speak for itself.
If all else fails and an agreement cannot be reached, let the code speak for itself. Management should consider giving developers the opportunity to prove out their concepts and then come back and demonstrate it. The proof will be in the code, taking the guesswork out of making the right decision. What’s more, you’ll have healthy, maintainable code built for longevity and growth.
What we’ve talked about here are the main driving forces of us building bitHound – we want to help developers and management make the best strategic decisions possible when it comes to code quality and building great, maintainable software. Our software analytics solution provides valuable insights and actionable recommendations so developers can build the best software possible. As a third-party, objective solution, bitHound gives developers and management real metrics making goals around quality easier to measure and to complete.
