Dirk Riehle's Industry and Research Publications

Contractions and expansions in organizing software development 2/2

When compared with hardware, software has been only a recent addition to products. Companies have been reorganizing ever since to better deal with software development.

Initially, software developers were part of the department that created and brought to market the overall product, with software initially being a small, later a large part of it. The obvious benefit of this setup is that software developers understand the context of their work, that is, the product they are contributing to.

Later, when managers understood how complex software can be, a contraction took place. Software developers moved into their own department and sometimes even a separate company. This relieved the original managers, who may never fully have understood software, from the software burden and suggested they could just buy the software features needed for their product. They would buy either from the freshly created software organization or a separate provider. I doubt that this form of contractual relationship for core product features ever worked well. However, this organizational set-up has an important benefit. It leads to an increased focus on capabilities building and knowledge sharing in software development, because software is now upfront and center. A central software organization makes this much easier than the old product silos.

Today, I’m seeing an expansion, reversing the contraction. With software developers understanding their job better and having effective means of knowledge sharing, they move close to the product again by returning to the original department. The benefit of this is the same as before: Being close to customers helps deliver the right features faster-better-cheaper. Unlike in the beginning, however, developers aren’t isolated but rather collaborate across product silo boundaries to create shared resources. Doing so is called inner source, because it adopts the best practices of open source for firm-internal collaborative software development. With inner source, there is no need for a dedicated separate software organization any longer. Stage three, the expansion, coincides with the current wave of digitization initiatives, in which software development becomes a part of the line-of-business again.

Naturally, this is a only rough description of three major stages in the life-cycle of how to organize software development. And many companies are still in the first stage, matching the significance of software in their products. However, leading companies with software-heavy products are clearly moving into the third stage, if they haven’t arrived there already. The companies my research group works in our inner source projects are ample evidence.

Tagged as (if any)

Subscribe!

Comments

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  1. […] I previously explained, to a manager the creation of such a software organization feels intuitively right. Based on many […]

Navigation

Share the content

Share on LinkedIn

Share by email

Share on X (Twitter)

Share on WhatsApp

Featured startups

QDAcity makes collaborative qualitative data analysis fun and easy.

Featured projects

Open data, easy and social
Engineering intelligence unleashed
Open source in products, easy and safe