Need help?

About

Career

Contact

Blog

Staffwerke

We will send your results to your email. By entering your email you consent to our privacy notice and allow us to send you emails related to this questionnaire.

# Efficiency test for your software development projects
In recent years, we have realised that many companies make very expensive mistakes in their software development. These mistakes significantly impair the efficiency and quality of projects and lead to millions being wasted. This is why we have developed the "12 rules of software develop-ment". Based on these rules, we have created a special online test that helps IT professionals evaluate the quality and efficiency of their software development processes.

## How does it work?
The test consists of 27 precise YES or NO questions. These questions are based directly on our 12 golden rules and cover all essential aspects of software development. The test offers a quick and easy way to evaluate the current efficiency of your software project.

## What to expect in the evaluation?
Once you complete the questionnaire, you will immediately receive a detailed evaluation. This result will show you the level of efficiency of your software development processes. **The benchmark of 92% efficiency should be your goal in order to be competitive.**

## Your results and impulses for implementing them
The analysis clearly identifies problematic areas in your company. You receive specific recommendations on where and how you should make improvements. These clear implementation impulses aim at sustainably increasing the efficiency of your software development.

## Your results available at any time
The results are displayed online. You can also download them as a PDF. This gives you access to the analysis and recommendations for action at any time.

Answer the questionnaire now and find out how efficient your software development really ist. Optimise your processes and **reach the next level to leave your competitors behind.**

TEST YOUR

It is not mandatory for developers to write code during an interview. 
However, it is essential that they can discuss real source code. 
This goes beyond simple examples or yet algorithms. 
The reason for this is that there is no universal standard that can reliably assess a devel-oper's skills. 
Neither academic degrees nor the professional experience on a CV provide a realistic assessment of actual competences. 
To really judge what a developer can do, you need to look deeper into their code. 
The focus must be on how a developer approaches problems. 
This is the only way to find out about their mindset and problem-solving skills. 

Failing to let developers actually write code means that their skills are not adequately as-sessed, which amounts to an almost blind decision. 
This leads to significant losses in efficiency, conflicts within the team and ultimately mil-lions in financial losses for the company. 

Developers often differ from others in their behaviour, which can certainly be attributed to the special demands of their profession, which usually requires a higher IQ and extreme-ly abstract ways of thinking. 
But we're not looking for an entertainer, are we?

Hands-on tip: 
Carry out practical coding tasks during the interview to assess technical skills directly. This will increase the productivity of your team and reduce the familiarisation time of new employees. But make sure these coding tasks are actually relevant to the project.


Code reviews are an indispensable part of the modern software development process. 
Not only do they allow other experienced developers to assess the work, but they also promote knowledge sharing and learning within the team. 
Reviews foster code style diversity within the team, with team members of different skill levels benefiting from each other. 
This contributes to the development of a strong coaching culture in which both experienced and less experienced developers learn from reviewing each other's work. 

Without code reviews, you lose the opportunity to ensure technical quality as well as architectural conformity and long-term maintainability. 
A quick look at the test coverage also helps to ensure compliance with the test strategy.


Hands-on tip: 
Implement regular code reviews in the development process to promote knowledge sharing and identify errors at an early stage. This will improve code quality and save costs for bug fixing and maintenance in the long term.


The role of the architect in the software development process is often misunderstood and/or unclear. 
A key aspect of this role is governance, i.e. monitoring that the intended architecture is implemented correctly. 
While the initial review of the programming results is carried out through code reviews or technical acceptance processes, it is the architect's responsibility to check whether these results also fulfil the defined architectural specifications. 
For example, an implementation that works technically may nevertheless represent serious violations of the specified architecture - such as development in a monolithic manner in a microservice environment. 

The architect is responsible for identifying such discrepancies and demanding corrections where necessary, which can even lead to a complete re-implementation if the solution is systemically redundant or non-compliant. 

If this critical review is not carried out, it inevitably leads to the degradation of the system and subsequent costs running into millions.


Hands-on tip:  
Ensure that architects systematically review programming results to ensure compliance with architectural guidelines. This will help you avoid expensive subsequent corrections and ensure the integrity and scalability of your system.


In an ideal world, developers always get the best hardware and software available to increase their productivity and motivation. 
Software development requires a high level of creativity, concentration and abstract thinking. Inadequate equipment that unnecessarily slows down everyday tasks such as compiling disrupts the flow of thought and significantly impairs efficiency. 
Although faster and more powerful equipment offers significant time savings and increased employee satisfaction, many organisations equip their development teams with sub-standard hardware and software. 
This practice invariably leads to frustration, loss of motivation and impairs the overall efficiency of the development process. 
The financial "return on investment" from better equipment should not be the only factor considered, because although the positive impact on developer morale and productivity is difficult to quantify, it is real and significant.


Hands-on tip: Invest in the best available hardware and software for your development team. This will increase their motivation and productivity, leading to faster development times and greater employee satisfaction.

In most larger software projects, it is unfortunately common that there are not enough test environments available. 
It is essential to provide test environments that are as close as possible to the production environment. 
Without this, it is difficult to check whether applications work reliably under real conditions, such as under high load from many simultaneous users. 
In addition, the lack of realistic data during the testing process means that software either does not work in practice or delivers faulty results. 

Competing access to limited test resources leads to delays and loss of quality, resulting in considerable costs or even product recalls.

Hands-on tip:
Provide sufficient and adequate test environments that are similar to the production environment. This will minimise the risk of expensive errors in production and improve the reliability of the software solutions.

Many companies tend to over-regulate themselves.
Developers are often not given admin rights or have to work with internet access that is slow and severely restricted. 
Such restrictions are drastically counterproductive. 
Developers need extensive rights and access to resources that are necessary for effective work. 
They create essential products and drive innovation and progress for the actual business. 
Developers are also very skilful at manipulating systems. 
If they are denied necessary rights, they spend a lot of time trying to circumvent these restrictions. 
This kind of generalised mistrust reflects a lack of competence at both technical and management level. 
The absurdity of this becomes clear when you realise that the resulting software ultimately runs at the customer's site and/or supports the entire business. 
Restrictions such as massive firewalls and filters are an obstacle to software development, as modern development often relies on copying and adapting existing code. 
If you still want to be paranoid about your own people, you can minimise your risks by setting up dedicated networks without destroying productivity.


Hands-on tip: 
Grant your development teams comprehensive administrative rights and unrestricted Internet access. This will increase their efficiency and innovative strength by removing unnecessary hurdles in software development.

Concentration is essential for software development. 
Many tasks require in-depth focussing, also known as "tunnelling". 
This focussing occurs after about 15 minutes of undisturbed work. 
Offices in which developers, testers and architects work in groups of a maximum of three people without constant interruptions effectively support this process. 

Physical proximity to non-technical people such as administrative staff or other departments is distracting, especially if they are frequently on the phone or involved in conversations that are not of a technical nature. 

Such distractions take developers away from their concentration. 
In addition, collaboration in small, focussed groups of professionals encourages practices such as pair programming and increases productivity through direct, technical communication. 
Open-space offices always have a detrimental effect on the concentration of developers.

Hands-on tip: 
Set up specialised work areas for a maximum of three developers to minimise distractions. This promotes concentration and efficiency, which increases productivity and the quality of work.

Many companies that use agile methods tend to foster a culture of "meeting oversaturation", which severely impairs the productivity of developers. 
Agile methods are not the origin, but often the turbo for oversaturated calendars. 

This leads to developers being repeatedly pulled out of their concentrated work phase, the "tunnel". 
To be truly effective, developers need longer, uninterrupted blocks of work. However, if they only have short windows of time between meetings, they never get into the necessary state of deep concentration and therefore cannot deliver meaningful output. 
The right schedule of meetings is therefore crucial: 
Two poorly timed meetings and the entire day's productivity is wiped out.


Hands-on tip: 
Schedule blocks of at least four hours per day without meetings so that your developers can work undisturbed. This will allow them to enter a state of deep concentration, which will increase the quality and efficiency of their work


Regular dialogue between developers and users is crucial for the successful development of software. 
Although good requirements engineering forms a solid basis, it is not enough to fully grasp the subtleties and specific needs of users. 

Especially when it comes to small details such as the size of control elements or something banal like the choice of font, friction and misunderstandings arise due to too many intermediate stages in communication. 

User feedback that is obtained directly and not just from stakeholders is therefore essential. 
It enables developers to get a deeper understanding of the actual applications and expectations. 
This regular exchange contributes significantly to ensuring that the software is not only functional, but above all meets the needs and wishes of the users exactly and is ultimately accepted with enthusiasm rather than scepticism and resistance.


Hands-on tip: 
Encourage direct dialogue between developers and users to obtain feedback. This will ensure that your software solutions perfectly fulfil actual needs and expectations.


Proof of concept (PoC) and rapid prototyping are, in fact, standard and critical methods in the modern software development process. 
PoCs are used to demonstrate the feasibility of a technology or approach before committing extended resources to full development. 

They are particularly valuable for validating early on whether a solution can fulfil the expected requirements. 
Rapid prototyping builds on the PoC and develops a quick, functional demo to gather feedback from users or stakeholders. 

This approach allows concepts to be visualised and tested quickly, minimising the risk of having to make costly changes later in the development process. 
The transition from a successfully tested prototype to a full implementation is a crucial step that ensures that only technically and functionally proven elements are integrated into the final product. 
This minimises risks and the associated immense costs that arise when untested technologies are used directly (at full scale).


Hands-on tip: 
Use proof of concept and rapid prototyping to quickly validate the feasibility of new approaches. This minimises the risk of useless development cost and increases compliance with user requirements.


It is a common misconception that the presence of software developers is sufficient and that dedicated testers are not a necessity. 
In fact, the role of the tester in the software development process is essential and should not be taken over by developers. 

Developers and testers have different skills and mindsets. 
While developers focus on creating and optimising code, testers focus on the actual capabilities of the product. 
Testers specialise in examining software, finding bugs and, if necessary, testing usability. 
They tend to explore software in a way that developers often don't think of. 
The ratio of at least one tester for every two developers is cost-effective and allows specialists to live within their area of specialisation. 
This model prevents developers from spending time on tasks for which they are neither trained nor have an affinity, thus saving immense sums of money.


Hands-on tip: 
Provide at least one dedicated tester for every two developers. This ensures efficient error detection and improves the quality of the software through specialised quality control.


Although many software projects confirm that tests are carried out, they usually lack a clear and detailed strategy that defines which types of tests are used and how comprehensive coverage is ensured. 

An effective QA strategy must not only start at the code level, but must also consider use cases and system functions. 

System tests are also required to check whether the entire system works with the new changes without errors (regressions) occurring. 

Grey box and black box tests play a central role here. 
In other words, tests in which the system is tested from the user's perspective without the internals of the source code being known. 
Passing through various stages such as development, testing, user acceptance, etc. is crucial to ensure that the software functions as expected under various conditions and fulfils the requirements. 

Without such a structured and phased testing and deployment strategy, companies risk not only low-quality products, but also high costs due to bugs that are discovered too late. 
It is therefore essential that a clear QA strategy is developed and implemented right at the start of a project in order to minimise risks and save huge sums of money on costly rework.


Hands-on tip: 
Develop a detailed test strategy at the start of each project. This will ensure quality, avoid late bug fixes and reduce costly rework.


In many software projects, the challenge is not only to understand agility as a concept, but also to actively live it. 

An initial plan is often drawn up, but this is quickly overtaken by changing requirements, technological challenges and external dependencies. 

This leads to a situation known as the "race to the bottom" or "chicken game", in which each team claims to be on schedule until the first team folds and admits that it cannot meet the deadlines. 

The house of cards then collapses, and all the other teams follow suit with similar confessions. 

This is mainly made possible by applying the "flexible" time estimates of an agile model without updating the timeline as it was intended. 
Regular review and adjustment of timelines and milestones is therefore essential to avoid such scenarios. 

Teams must be encouraged to report transparently on progress and challenges, and management must be careful not to contribute to an inefficient working environment by micromanaging. 

Instead, it is important to clearly define priorities and, if necessary, cancel or postpone features in order to focus resources on the essentials. 

This requires an open communication culture and a constant endeavour to set realistic and achievable goals. In this way, the project is effectively driven forward without teams feeling compelled to make unrealistic promises.


Hands-on tip: 
Promote a culture of transparency and alignment in your projects. This will help you set realistic goals and avoid inefficient ways of working that waste resources.


Git has established itself as the de facto standard for source code management in modern software development. 

Git offers a number of advantages that make it ideal for teams in almost any technological environment. 

These advantages include flexibility, distributed working options and support for various merging strategies. 

These features make Git an extremely powerful tool in software development. 

Other source code management systems, although they may have their own strengths, have lagged far behind Git. 

The use of Git not only promotes efficiency and flexibility in development processes, but also supports the career development of developers by enabling them to work with industry standards that are recognised across languages. 

This directly facilitates recruiting and makes your project attractive in the long term.


Hands-on tip: 
Integrate Git into your development processes. This will improve efficiency and collaboration and make your projects more attractive for developers.


If developers have to go through cumbersome processes every time they start their software, this leads to a considerable loss of time. 

This becomes particularly problematic if the software cannot simply run on a standard machine due to dependencies or poor configuration. 

Such obstacles not only lead to frustration, but also to significant costs due to enormous losses in development time. 

A complex or error-prone start-up procedure leads to teams developing a real reluctance to make changes or restart the software frequently. 

However, this is completely absurd, as no development is possible without constant restarts. The negative effects really explode when you switch from development to deployment or even operation. 

This phenomenon is unfortunately very common and regularly causes additional costs in the millions!


Hands-on tip: 
Optimise the start-up procedures of your software to minimise time losses. This will increase development efficiency and avoid additional costs.


The implementation of dedicated DevOps roles in software projects is crucial in order to manage the complexity of development environments. 

Often the term "DevOps" is misunderstood as a fusion of development and operations, leading to the erroneous assumption that developers can also take on operations and deployment tasks. 

In reality, large projects, especially those using advanced technologies, require specialised skills that lie outside of traditional software development. 
A dedicated DevOps is not just another developer, but someone with specific expertise in the automation, configuration and management of CI/CD pipelines. 
This professional takes care of the seamless integration of code into automated environments and ensures that these systems scale with the needs of the project. 
While developers might technically be able to perform some of these tasks, the different mindset and specialisation of DevOps leads to more efficient solutions. 

A minimum of 0.5 FTE of DevOps per team applies when there is already an existing and scalable pipeline in place. 

The task of developing and maintaining a CI/CD pipeline must not be taken over by developers, as this leads to less professional and highly maintenance-intensive solutions. 
It is therefore necessary to employ sufficiently qualified DevOps specialists who deal exclusively with pipelines in order to maximise efficiency and avoid placing an unnecessary burden on development resources. 

Not only the build process, but also deployment, operation and the associated monitoring are highly complex tasks that cannot be completed on the side.


Hands-on tip: 
Make sure that you have at least one full-time DevOps specialist per two teams. This will maximise the efficiency of your CI/CD pipelines and the performance of your development projects.

A build time of less than 10 minutes for the entire platform is not only desirable, but also a critical factor for the agility and efficiency of a development team. 
Fast build times make it possible to react quickly to problems, especially when it comes to implementing hotfixes. 

A longer build time will significantly delay the round-trip time of bug fixing, which in turn puts a strain on the overall development and release pipeline. 

This is particularly critical in a production environment where downtime must be minimised, and rapid responsiveness ensured. 

To achieve such an objective, various strategies such as parallel builds, use of build caches and optimisation of resource allocation are helpful.
 
However, this requires careful configuration and, if necessary, hardware adjustments.


Hands-on tip: 
Optimise your build times to under 10 minutes. 
This will increase the agility and responsiveness of your team in productive environments.


The ability to roll out a new version of the software to any stage with a single click plays a key role in an efficient and secure deployment process. 

In complex projects, deployments tend to become complex themselves, which increases the potential for errors. 

If a deployment requires several manual steps, this risk increases significantly. 

Automated deployment processes that enable the entire platform or individual components to be rolled out with a single click significantly reduce this risk. 

This is particularly important in distributed systems, as the simultaneous deployment of different components in different versions can cause serious problems such as data corruption or system failures. 

It is therefore very important that deployment pipelines are carefully planned and robustly implemented. 
One-click deployment not only demonstrates advanced technical skills, but also a high degree of organisational maturity in the software development process.


Hands-on tip: 
Implement one-click deployment in your software projects. This will increase the efficiency and security of your deployments and reduce the risk of errors.


Fixing bugs immediately is essential to maintain the integrity and stability of your project. 

If a bug is discovered, it is important to fix it immediately. 

Minor problems or cosmetic errors can possibly be deferred. 

Real bugs that affect the expected behaviour of the software must be fixed immediately. 
Delaying the correction of such bugs can lead to serious consequences. 

Further developments built on a faulty basis will create additional bugs or exacerbate existing ones, further degrading the code base and making future maintenance more difficult. 

The more time that passes between a bug being identified and fixed, the more expensive it becomes, as developers may have to learn the scenario from scratch to fix the root cause. 
An effective bug management strategy requires bugs to be identified, prioritised and, above all, fixed quickly in order to prevent them from spreading further through the system or causing deeper systemic problems.


Hands-on tip: 
Fix bugs immediately to ensure the integrity and stability of your software projects. This will help you avoid serious consequences and additional costs caused by postponed problem solutions.


Refactoring is an essential part of software development that is often misunderstood. 

It is not a fundamental rewrite or a comprehensive redesign that puts the existing system out of operation indefinitely. 

Rather, refactoring is about making continuous and incremental improvements to the code in order to increase its quality and maintainability. 

It makes sense to plan a portion of development resources, around 20%, for refactoring activities. 
This is not about a "blocker" of 20%. 
Refactorings must be seen as part of daily development work, especially when new features are implemented. 
This involves checking whether the existing code is cleanly structured and whether it is suitable for integrating the new functionalities. 
This enables developers to adhere to the software architecture and ensure the integrity of the code. 
Continuous refactoring ensures that the code remains efficient and maintainable, which makes troubleshooting and future enhancements much easier. 

Neglecting this usually leads to technical debt and violations of the architecture. 
This in turn leads to astronomical round-trip times - and significantly increases costs. 
Refactoring is not just a dedicated task, but an integral part of day-to-day development that keeps the software efficient and adaptable in the long term.


Hands-on tip: 
Plan at least 20% of your capacity for refactoring. This will increase the quality, maintainability and efficiency of your software and avoid technical debt.


Ideally, stakeholders or users formulate their requirements as business needs in order to clearly define what is to be achieved without specifying technical implementation details. 

This allows technical teams - developers and architects - to contribute their expertise to create the most efficient and best solution. 

It is crucial that requirements are focussed on the goals rather than dictating specific technical solutions. 

When users try to translate problems into technical solutions themselves, this often leads to misunderstandings and sub-optimal solutions. 

Users don't have the technical knowledge to specify effective technical solutions - that's what developers and architects are for. 

The most effective approach is to express needs in clearly defined goals.  
Developers and architects need the freedom to find the best technical solution. 
This ensures that the solutions developed meet the business requirements and do not just address isolated technical problems that may not even exist.


Hands-on tip: 
Encourage stakeholders and users to formulate their requirements as business needs. This will give your technical teams the freedom to develop optimal solutions that meet business objectives and can be implemented efficiently.


Here are our recommendations based on your answers:

Contact us to get a personal consultation with our CTO and lead architect of **20+ years** of professional experience and dozens of successfully launched projects. Let us supercharge your software development!


Download your personal results as a PDF e-book.

Global high performers run at an efficiency score of **{{maxScore}}**. If you want to outperform your competitors you need to have at least **{{passingScore}}** points. You are missing **{{missingPoints}}** points in order to be competitive.

Global high performers run at an efficiency score of **{{maxScore}}**. You are above the benchmark of {{passingScore}} points. Your efficiency is way above average, congratulations!

Your software development is at a critical point. The current situation shows considerable inefficiencies that jeopardise your competitiveness. Similar to many large corporations, you also need to take urgent action. We recommend that you temporarily outsource the development tasks and concentrate on specifying the requirements and approving the results. This approach allows you to benefit from tried and tested methods and infrastructures without continuing to invest resources in inefficient processes. Continuing with the current state costs your organisation a considerable amount of money every day. How much longer will your organisation be able to cope with this financial pressure?

Your projects hardly make any progress. You spend more time on internal battles than on creating real value. The stability of your processes and your time-to-market times are not competitive. It may sound harsh, but your competitors achieve around ten times the output with the same number of employees - or have only a tenth of your costs. You urgently need support and must be prepared for far-reaching changes. There are clear alternatives. You can question this result, but that will not improve your situation. Let's talk about the quickest way to get you back on track.

You lose almost 50% of your capacity. If your financial situation allows it, this may be acceptable at the moment. However, bear in mind that without significant changes, it is unlikely that your situation will improve. You can also target your budget to make improvements today and overtake your competition.
We are ready to support you!

You are making very good progress. However, you are still losing around 15% of your capacity, which means that around one in six employees is mainly occupied with coping with uncertainties. We are happy to support you in realising the full potential of your team.
 This is most effective in a joint project, where we lead through practical work instead of just making promises.


Neat! You are developing at optimal efficiency. If you are searching for a partner at eye level, look no further. Or just hit us up to go for a beer. Cheers!

Wow, did you really? Châpeau if you were absolutely one hundred percent honest in answering all our questions with YES.
In 20 years of software projects we have not come accross this level of efficiency in the wild. National Geographic might want to get in touch with you to shoot a documentary on this rare case of actually efficient software development in its natural habitat.