Wissen

A New Approach To Predict Burnout Risk for Software Developers - Cape Of Good Code

Egon Wuchner — Fri, 10 Sep 2021 13:22:47 GMT

Summary
Why are software developers so often exposed to burnout symptoms?
Early indicators of burnout are measurable with DETANGLE®
Conclusion
Frequently Asked Questions
Links

Summary

Burnout symptoms are often a result of suboptimal procedures and working conditions. They are signs of a serious and protracted illness.
Especially, burnout of software developers is more widespread than one might suspect. It hits companies via increased employee turnover, reduced team productivity and above-average sick leave just as hard as the affected employees.
Amongst many other reasons, “meaningless” work, frequently changing priorities, unrealistic goals, deadlines, and overwork are disproportionately often named as causes.
Early indicators for these most important burnout causes can be identified from the work on the software code with the DETANGLE Analysis Suite.
With these analysis results, project leaders/-management have information at hand to identify health-threatening working conditions of their developers at an early stage and can initiate countermeasures timely.
By regularly applying these analyses, additional information regarding the trend of the relevant key metrics will become available. Over time it becomes increasingly easy to narrow down the causes of a developer’s burnout and to avoid it before the individual and as a consequence, the organisation is seriously impacted.

The Most 'Striking' Way To Explain Technical Debt - Even to Your Kids & Managers - Cape Of Good Code

Konstantin Sokolov — Wed, 30 Jun 2021 13:53:19 GMT

The term “technical debt” is a very useful metaphor. It helps to illustrate certain problematic peculiarities in software development.

Regardless of the apparent clarity of the term, I always have the feeling that people who have never been directly involved in software development cannot fully understand the real magnitude of the problem of technical debt. For those responsible for software projects, however, this would be very desirable.

In the following I will try to present this important topic in a simple and comprehensible way. I hope it helps to understand how too much technical debt can destroy the future of software.

I Already Know Where the Problems Are in My Code - Cape Of Good Code

Konstantin Sokolov — Thu, 27 May 2021 00:49:53 GMT

If you’re in the software development industry, you’ve probably heard this phrase more than once. From colleagues, suppliers, customers or business partners. But most often, of course, from yourself. You have said it out aloud, consciously thought it or implicitly assumed it.

Why? Because it is what you truly believe. Anything else would be a personal disaster, wouldn’t it? And while I am 100% convinced that I am unfamiliar with the majority of the problems in my code, I too often catch myself thinking the opposite.

Software Due Diligence - Focus on Contributors and Their Cooperation - Cape Of Good Code

Egon Wuchner — Mon, 17 May 2021 17:16:08 GMT

Summary

The success of a software company takeover depends to a large extent on the retention of key developers.
The DETANGLE® Software Analysis Suite identifies different groups of key developers.
The acquisition risk decreases if the investor can conceive measures at an early stage to retain these employees.
The tool also analyses the entire effort and knowledge distribution in the development team. The optimisation of knowledge distribution enables quality and efficiency improvements.
An optimised knowledge distribution also reduces the dependency on individual persons.

Avoid Pitfalls in Software Due Diligence - Cape Of Good Code

Konstantin Sokolov — Thu, 29 Apr 2021 12:31:08 GMT

The role of software assets in M&A transactions becomes increasingly important for the evaluation of business risks and the commercial or strategic value of the target. The tight time frame makes it obviously inevitable to apply a tool-assisted approach for the assessment of the technology status and the inherent risks. There is a growing understanding that widely used static code analysis tools can not deliver the necessary depth of insight for the investor compared to the analysis of the history of the code and its changes.

In this blog we are going to elaborate why identifying the relevant code and potentially risky hotspots needing improvement has to consider more than just code quality and hotspots of changes. The next blog is focusing on the human factor and why the identification of key developers needs to look beyond knowledge islands.

10 Mandatory Criteria When Selecting a Software Supplier

Konstantin Sokolov — Fri, 16 Apr 2021 20:43:45 GMT

How often have you encountered issues with a delivery of your software supplier? It is rather the rule than the exception. Why? Because there are some technical rules or best practices your supplier should definitely comply with, if the supplier wants to be listed as a stress-free supplier in his customer base. We have put these rules as our top 10 best practices when developing software.

Rethinking (Collective) Code Ownership - Knowledge Distribution Risks Demonstrated With the German Corona-Warn-App - Cape Of Good Code

Egon Wuchner — Thu, 11 Mar 2021 13:07:48 GMT

As a project manager for a software development team

Do you know the team structure?
Do you know who is working on what?
Do you know whether the respective developer has the best knowledge prerequisites?

“You don’t have to”, say the advocates of agile development, because “the team organises itself”. And by the way, the principle of “collective code ownership” prevails, i.e. everyone is responsible for everything in the code [1].

With a little thought, one starts to wonder, e.g. because “collective code ownership” contradicts the principle of modularisation and efficient development [2].

But the principle is not only dubious, it also causes harm. Among other things, the “diffusion of responsibility” [7] phenomenon occurs, in which no one really feels responsible any more. Individual developers lose sight of the bigger picture because many of their fellow developers have also changed the same code.

In the process, the different development styles mix into a cacophony of code, and the cognitive effort required to understand the code increases to the point of incomprehensibility.

Corona-Warn-App - On the Way To Critical Technical Debt? - Cape Of Good Code

Egon Wuchner — Tue, 23 Feb 2021 15:12:18 GMT

We applied our DETANGLE analysis suite to the Corona-Warn-App for iOS and Android to assess the quality and other risks related to maintainability and extensibility. Up to version 1.11, we determined how features and defects are reflected in the code, measured architecture quality, estimated technical debt and analyzed knowledge distribution risks.

First of all, we would like to express our appreciation in all clarity for what has been achieved with the creation of the Corona-Warn-App. The overall system was developed under high media attention, tight time frames, political pressure and very high data protection requirements. With this blog, we would now like to point out quality aspects and risks that, in our view, should be given attention after an initial development stage.

Although the current code quality metrics from SonarQube, the tool used for code analysis during the development of the Corona-Warn-App, repeatedly show a very good rating for both apps up to version 1.11, there are nevertheless striking findings that contradict this good picture in parts. In this post, we will look at the results for the iOS-version of the app.

Software Due Diligence sheds a lot of light on the unusual risks associated with tech targets (Part 2) - Cape Of Good Code

Egon Wuchner — Wed, 27 Jan 2021 10:26:14 GMT

Introduction

In the following second part of the blog series, we are going to discuss the fields of investigation of a software due diligence.

This blog series also appeared as an article in the 11/2020 issue of the German M&A Review magazine. The specific issue of M&A Review can be found here.

In Part 1 we talk about the reasons why software assets present particular valuation risks. The last, third part, deals with the process of a software due diligence and its deliverables.

Software Due Diligence Sheds a Lot of Light on the Unusual Risks Associated With Tech Targets (Part 1) - Cape Of Good Code

Egon Wuchner — Wed, 16 Dec 2020 15:58:19 GMT

Table of Contents

Introduction
Software targets have specific valuation risks
An investor should know the technical debt of the software
Important questions about technical debt
Outlook
References

Introduction

This blog series also appeared as an article in the 11/2020 issue of the German M&A Review magazine. The specific issue of M&A Review can be found here.

The blog series addresses the following aspects of software due diligence:

the reasons why software targets present particular valuation risks. And why a focused software due diligence is a prerequisite for assessing technological risks in the acquisition of software companies,
the fields of investigation of software due diligence and why a mix of tools and experience is necessary for this, and
the process of software due diligence and its deliverables.

In the following 1st part of the three-part series, we are going to discuss the first point about the particular valuation risks of software targets.