How Software Excellence Fuels Business Performance

«Give a programmer a task that should take 100 hours and he will spend 99 hours writing a program that will do the task in 1 hour»
— Don Box, Developer Network Journal (DNJ), issue 20, Sep/Oct 2000, page 49

I chose this quote to introduce my article because I believe it perfectly condenses the nature of a programmer who aims to achieve software excellence.

I reported the quote literally, hence the “he” pronoun. I would have rather said “he/she/they”, but, back in 2000, a few people were paying much attention to genders.

If you widen the scope of this sentence from the individual to the organization, and include the tools, the culture, and the product management and talent management techniques, I believe you will achieve software excellence at the organizational level, and indeed fuel business performance.

I have recently read the article Developer Velocity: How software excellence fuels business performance, published by McKinsey & Company on Apr 20, 2020, which describes the dimensions and drivers that are used to measure what they call the Developer Velocity Index (DVI).

The DVI pinpoints the most critical factors in achieving Developer Velocity.

The dimensions are organized in three broad categories: technology, working practices, and organizational enablement.

The article is based on research conducted by interviewing more than 100 chief technology officers, chief information officers, and other senior engineering leaders, and by asking technology executives at 440 large organizations across 12 industries in 9 countries to rate their company’s performance.

The article highlights that the four dimensions with the greatest impact on business performance are tools, culture, product management, and talent management.

Now I would like to put in my two cents on these four main dimensions, based on my experience.

I was surprised to find out that design thinking was not even mentioned in the article.

Design thinking refers to the set of procedures followed in the process of designing something, not only a software solution.

In my opinion, design thinking should play a primary role in the software design process, as well as a means toward innovation.

I have been successfully using it for many years, in several projects, achieving software excellence.

These are just some of the techniques that may be adopted during the software design process:

Here is something I learned about agile practices.

On the one hand, every project and situation are unique, so it is a good idea to have an agile method that is customized to each situation.

On the other hand, creating an agile method from scratch is a very bad idea: there are plenty of methods out there that proved to be effective, such as SCRUM and XP, just to mention a couple of them.

So, the best idea is to start with an existing, proven method and iteratively refine it: apply it to the specific project and situation, note where it works and where it does not, make an educated guess about how to improve it, and repeat the process.

The same goes for software tools: there is a number of great software tools that can help increase the DVI: Jira, Confluence, GitLab, Jenkins, and other DevOps tools, for example, work really well together.

However, just like the agile method, we need to mold them in order to suit the specific needs of each project and situation, and luckily most of these software tools are flexible enough.

Building an InnerSource culture is about more than using open-source software within the code. And it does not even necessarily involve encouraging contribution and participation in the open-source community. Building an InnerSource culture means adopting an open-source approach to how code is shared internally.

I do not remember how long ago, I replied to a tweet on Twitter by a software engineer who asked something like “Dear software architects, can you please describe your job? What are your daily tasks? What are your responsibilities?”.

This was my reply: my own definition of software architect. She liked it, and she replied back that she would love to become a software architect one day.

«I do my best to be there for my teammates when they need me, to guide them and support them, trying to pay attention to every detail of all the software projects, and yet never lose the big picture»

Please, bear with the narcissism that urged me to quote myself, but I believe this sentence condenses the culture that all the individuals within an organization should embrace in order to achieve software excellence and eventually fuel business performance.

One important fact I learned is that the product-management team not only needs a relevant knowledge of the business and the market, but also a strong technical background. And this is something that, in my experience, I found product managers were lacking so too often.

About talent management , back in 2016, I hired a very talented, newly graduated computer scientist. After about two months working onsite, during which he learned a lot, he started working from home – this was way before the COVID-19 pandemic. He was very efficient and productive, and I was very pleased with his achievements. He worked with me for about one year. And then he quit because he missed socializing. He was very sorry to leave, but he needed to wake up every morning and go to work, meet his colleagues, and do all the “normal” stuff that people with a “normal” job do. This experience taught me a lot about what “smart” working means from a social perspective.


Fabio Scagliola,