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.


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.

“During one of our projects, we managed to decrease the time it took for a new pull request to go live from a few months to just a few hours in theory. However, the client insisted on still manually testing these changes first. This led to a significant delay, and increased the total time back to around two weeks because it relied on the availability of testers.”
Kilian Niemegeerts, managing partner at FlowFactor

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 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.

“If you’re doing DevOps right, you integrate security from the very start, so you’re already doing what is now being called DevSecOps. There’s no need for another fancy term, although I am happy that has led to an increase in awareness when it comes to security.”
Kilian Niemegeerts, managing partner at FlowFactor

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.  

“We’ve seen plenty of cases where our tooling suggestions and improvements were mistrusted by developers, because we’re seen as infrastructure people that just want to change their way of working. We always stress that the new tools are there to save them time and effort and let them focus on the actual coding by reducing frustrations. With that being said, developers are becoming more accepting of new tools in the last few years.”
Kilian Niemegeerts, managing partner at FlowFactor

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.


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?

Related posts
No Comments

Sorry, the comment form is closed at this time.