How to Refactor the Technical Roadblocks in Your Development Process
How to Refactor the Technical Roadblocks in Your Development Process
11 January 2024
Kilian Niemegeerts
Key takeaways
- Don’t forget about automating testing, it can seriously bottleneck the rest of the process.
- Integrate security as early as possible in your development process.
- Developers are creatures of habit: clearly communicate the benefits of new tooling.
- You can’t avoid technical debt completely, but awareness goes a long way.
Large organisations nowadays are complex, which means that there are plenty of elements that can hinder the development process. Since we often encounter the same issues and challenges during our projects, we decided to write a two-part blog on possible development roadblocks.
In this first part, we’ll take a closer look at the technical roadblocks: testing, security, and (developer) tooling, all of which lead to technical debt. In the next blog, we will explore non-technical challenges related to management styles and company culture.
Testing
Automation is a key element of streamlining development processes. One often overlooked bottleneck is manual testing, leading to significant delays. In our experience, testing is frequently considered secondary to coding and infrastructure setup, and the first victim of budget cuts. However, the impact of leaving out testing should not be underestimated.
However, it’s not all about speed. In some cases, we’ve even heard quotes like “the real test is production”, a risky approach that we obviously don’t recommend because of its impact on customers. Automated testing will prevent issues from happening in production in the first place and will also increase the quality of your products and services. We also recommend test-driven development (TDD), which will help you proactively improve quality throughout the development process thanks to its systemic approach.
Security
Security is also often treated as an afterthought, even though it is a critical aspect of development. Luckily, terms like DevSecOps have made decision-makers more aware of the importance of security. However, as we explain in an earlier blog, this term is more of a marketing buzzword.
Security can also be a roadblock in the development process because security teams, who may not be in the loop, have the authority to block development. If a developer submits code where they unknowingly used a library containing a vulnerability, they can render (parts of) the code unusuable, forcing the developer to find a solution.
You can avoid this scenario by enacting a shift left, which involves integrating security earlier in the development cycle through (automated) checks based on your organisation’s security policies. Instead of blocking code at the very end, vulnerabilities and other security risks will be flagged while coding in the Integrated Development Environment (IDE). However, this will often require adapting to a new way of working. This leads us to the next possible roadblock: developers and their tools.
Developers and Tooling
Even if you eliminate the usual roadblocks like security and testing, developers themselves can be a roadblock in the development process. Like all humans, they are creatures of habit. Even if you’ve set up advanced tools like the IDE we described earlier, getting developers to actually use them requires careful communication.
Developers can also pose a (technical) roadblock when they are a single point of failure. If there is just one developer with enough in-depth knowledge about a certain application or piece of code, and they are unable to work for whatever reason, things can grind to a halt. This knowledge gap can be solved through adequate documentation. Not a developer’s favourite task, but thanks to generative AI tools like ChatGPT this documentation can be generated automatically. This brings us to our final technical roadblock, where everything comes together: technical debt.
Technical Debt
Let’s not beat around the bush: there is no avoiding technical debt completely. Major errors in production environments will always need to be solved as soon as possible. However, always consider the impact of quick fixes on your code base. Emergency solutions are often built on other code that was originally meant to be a temporary placeholder, leading to further dependencies, and eventually forming another roadblock.
The only real solution here is to automate the entire development process, but awareness goes a long way, along with reserving dedicated time for solving technical debt whenever possible.
Conclusion
Dealing with the complexities of today’s development processes requires a balanced strategy. In this part, we’ve discussed how addressing technical challenges, from testing and security to developers and tooling, will help you lay a solid foundation and avoid substantial amounts of technical debt.
However, development goes beyond just tech. In the next part, we’ll shift our focus towards non-technical impediments by looking at the influence of management styles, corporate cultures, and business users.
In need of an expert DevOps partner that doesn’t shy away from the hard truths and looking at the bigger picture?
Sorry, the comment form is closed at this time.