Have you ever worked as part of a software development unit within a company or another organization, either in a managerial position or as a technical person, and known that not everything was fundamentally right? Have deadlines been missed by a significant margin repeatedly, and even small changes to the software required an inexplicably large amount of work? Perhaps the final product was riddled with bugs and required frantic on-the-fly patching. Or maybe the unit suffered from high developer turnover, causing the workload to fall onto others.

Project management tends to react to these challenges in a very similar way. Software developers are pushed to work harder and harder—after all, the problem must be with software development, right? All unnecessary tinkering to reduce technical debt is dropped, so the focus can be solely on feature work. The end customer wanted these features ready yesterday! As a last resort, under schedule pressure, the project may begin to cut corners on quality assurance in the hope that duct tape and quick fixes will get them out of trouble faster.

All of these approaches frequently turn out to be wrong and may even worsen the problems.

The root cause of the difficulties is usually deeper. Below, we present four different questions that management and software developers should aim to answer first.

How is software architecture managed?

In our previous blog post, we discussed architecture responsibilities. Software architecture roughly refers to the structure of the software and its components, as well as the general principles that guide the design and development of the software. Well-designed architecture helps manage the risks and costs of a complex software project and creates a system that genuinely meets the needs of end users.

Problems with architecture often stem from a lack of a clear overall vision for software development, coupled with no one taking true ownership of how the architecture should evolve. As a result, each software developer tends to work independently as they see fit, which leads to a chaotic and fragmented outcome. The real needs of end users, which the architecture should reflect, are also not necessarily up to date.

Making changes to the software can be particularly challenging if the whole system has not been designed from the beginning with potential changes in mind, and no one ensures that changes can be implemented in the future as well. As a result, the software effectively becomes hardware.

Key questions regarding architecture include:

• Who is responsible for the architecture?
• What kind of architecture does the software follow?
• Does the architecture enable the software to be modified and maintained at reasonable costs in the long term?
• How are end users’ needs considered when designing the architecture?
• How is knowledge and expertise about the architecture shared within the team?
• How is adherence to the architecture monitored?

If the answer to any of these questions is missing, the sirens should start blaring.

How is technical debt in software kept under control?

Technical debt in software refers to short-term compromises and choices made during software development that enable quick progress but result in additional work, risks, or problems in the future. Technical debt accumulates when software is built in a way that is not optimal for long-term maintainability, performance, security, or other quality aspects. Therefore, debt must be regularly reduced to make the code more sustainable in the long run.

Neglecting technical debt has numerous researched negative effects. It often significantly increases the time developers spend on development work. Recent studies indicate that, on average, up to 25% of the time spent on software development projects is wasted on issues related to technical debt, such as bugs and tracing them. It also negatively impacts software developers’ job satisfaction.

The challenging aspect of reducing technical debt is that it can be expensive. However, the longer it is postponed, the more costly it becomes to reduce, and the negative effects of the debt intensify.

Regarding technical debt, the team should at least ask themselves the following questions:

• How is the accumulation of technical debt monitored?
• What kind of technical debt has accumulated in the software, and what is its impact?
• Is time allocated for reducing technical debt?
• What plans have been made to reduce technical debt?

At what level are the software development practices, tools, and processes?

Over the decades, professional software development has advanced significantly from the “wild west” of the past. No longer are self-styled programming gurus, fueled by energy drinks, isolated in their own silos, hacking away at code with ad hoc methods and different tools, lacking common communication, quality assurance, or process automation. Nowadays, for example, software that has not been thoroughly tested cannot even be considered half-finished.

A professional software development process involves coordinating work collaboratively, regularly evaluating its results, and systematically improving practices based on feedback. There are several methods for managing the software development process, with Agile methods like Scrum gaining the most traction in recent decades. However, the key is not the specific method itself, but rather ensuring that the chosen approach is effective and genuinely works. Holding daily stand-ups occasionally (often overly long) and calling it Scrum does not mean the software development process is in good shape.

Equally important is that the team has up-to-date tools at their disposal and follows best practices in using them. For instance, every programmer on the team should understand how to write code that is understandable and maintainable for others, using the programming languages chosen for the project.

Today, software developers should also automate the quality assurance of their software as much as possible, using comprehensive automated testing, continuous integration, static analysis tools, and automatic monitoring. This can significantly reduce costs for manual testing and maintenance. Research has shown that automated testing, for example, can significantly lower software development costs, shorten development time, and enhance the quality of the final product.

Some questions the team should ask themselves:

• Is the team using some software project management framework, and is it followed in a way that genuinely enhances the team’s efficiency?
• Are proven programming practices being followed within the team, and are those practices monitored both automatically and through code reviews?
• Are the tools used by the team up-to-date and consistent?
• To what extent are the repetitive routines and quality assurance of the software development process automated?
• Does the project employ comprehensive automated testing, continuous integration, and automated monitoring of the production environment?

What is the software development culture like within the team?

None of the above points matter if the team’s software development culture is in disarray. A poor culture means that there is a careless attitude towards professionalism in software development within the team. This may manifest as a genuine lack of interest among team members in following best practices, producing sustainable and maintainable code, or ensuring the quality of the final product.

A typical sign of a problematic software development culture is a sense of cynicism among team members about the current situation, along with a belief that making changes is pointless because nothing will improve anyway. Both developers and project management may also cling to outdated attitudes, insisting on doing things as they have always been done, without seeing a need for progress. A strong resistance to change is characteristic of such situations and prevents the team from learning anything new.

That’s why it is crucial to have proper feedback channels for improving the software development process and to respond to feedback regularly. Otherwise, cultural problems may start to manifest as increasing turnover. Often, the most competent people are the first to leave the company.

 

Software Consulting to Help with Problems

Did the above questions set off alarm bells? Finding answers and solutions to them can certainly be achieved independently by the organization. However, sometimes problems pile up to the point where seeking external help is the right choice.

Software consulting can provide significant assistance in tackling challenges in software development projects across various areas. Buutti, as a company, has been involved in hundreds of software projects and has supported its clients through countless different challenges. All of our consultants have passed a rigorous recruitment process and a comprehensive onboarding program that both emphasize good software development practices. Through their projects, our consultants develop a broad and professional perspective on how to deliver long-term value to clients.

For solving architectural problems, we can offer deep expertise and fresh perspectives to help design more sustainable systems. In managing technical debt, we are skilled at identifying critical areas for improvement and creating actionable plans to reduce it. When it comes to developing processes, practices, and tools, we can analyze the current state of a company and recommend practices and tools that increase the likelihood of success for teams. Furthermore, we offer guidance on enhancing software development culture and fostering stronger team collaboration and communication.

The advantage of software consulting lies in bringing fresh insights that may be missing within the organization, backed by extensive experience in navigating and overcoming common pitfalls in software development. In our experience, IT projects often encounter very similar challenges, which is why similar solutions are frequently effective in turning things around. A team can benefit from the expertise of an external software consultant already in the early stages of a project when long-term decisions are still being made. Moreover, management should not hesitate to seek external expert guidance to ensure effective project leadership!

 

Sources

1. Bass L., Clements P., Kazman R. (2012) “Software Architecture in Practice, Third Edition”
2. Poort E.R., van Vliet H. (2012) “RCDA: Architecting as a risk- and cost management discipline”
3. Besker T., Martini A., Bosch J. (2019) “Software Developer Productivity Loss Due to Technical Debt”
4. Stripe, (2018) “The Developer Coefficient: Software engineering efficiency and its $3 trillion impact on global GDP”
5. Ramač et al. (2022) “Prevalence, common causes and effects of technical debt: Results from a family of surveys with the IT industry”
6. Besker et al. (2020) “The influence of Technical Debt on software developer morale”
7. Kumar D., Mishra K.K. (2016) “The Impacts of Test Automation on Software’s Cost, Quality and Time to Market”