Introduction

I wrote this book as a reaction to the perceived misunderstanding of companies, especially manufacturing companies, when it comes to integrating with a software division. I might have a partial or inaccurate view, but my aim is to report my general perception of a problem, and the effort of these pages is to motivate some decision-makers to realise there’s a new facet of modern industry that needs special attention as it behaves according to new rules. I therefore define the following:

Software company: a company or institution developing software, regardless if software is their end product or not.

Under this definition, the following are very likely to be software companies, even if some do not appear to be at first glance:

A company making an instant messenger application
A consultant group for statistical analysis and data mining
A manufacturing company producing chemicals
A manufacturing company producing mechaelectronic assemblies
A research center in high energy physics.

As you can see, while the first one naturally matches the traditional definition of a software company, the others generally are not considered as such. This is however incorrect, and creates most of the issues documented in this book. The following statements are, in fact, generally correct:

The consultant group needs to develop software for data extraction, storage, conversion, validation, traceability, visualisation and reporting of the data they process.
The manufacturing company producing chemicals needs software to keep track of quantities of produced product, improve formulations in R&D via custom software, match customers to shipped batches for quality assurance or marketing purposes.
The manufacturing company producing mechanical assemblies needs ad-hoc testing rigs, calibration recordings, support for manufacturing and commissioning (either internal or from suppliers), data analysis for post-sales support,# document traceability for regulatory certifications.
The research center needs research reproducibility, support for data acquisition from internally developed instruments, data plotting, implementation of novel models.

All of these cases require software, despite software not being the product that the company sells to customers. However, any software exists due to demand, and in this case the customer is simply the company itself.

In some cases, the software can be just bought, but this is not always the case. Some of this software may be basic scripts, other may be more complex applications with business-specific personalisation and requirements.

I hope that there’s a compelling case for the definition of “software company” to be therefore true. If your company writes code in any form, it is a software company. The implications are profound.

Woes of a young industry?

Software adds a new dimension to two well established pillars of engineering: mechanical and electronical. However, it is uncanny how bad and mistreated software is, compared to its older counterparts.

XKCD

Some of the woes of the software company is possibly connected to its young age. There is simply not a lot of established, successful process for some of these cases, and executives are not trained to deal with software companies and their different needs.

I personally believe the young age of the software company is not the only reason. Deeper forces are at play, and this book aims at describing some of them and their consequences. Plenty of literature exists on the topic, but it appears not to reach the decision makers or the environments in which they are trained.

Book structure and organisation

The book is organised as follows:

In the first chapter we will describe in more detail the software company, its goals and possible facets, and its commonalities across a various spectrum of businesses.
In the second chapter we will investigate development methodologies, such as Agile and its consequences.
In the third chapter, we will talk about code quality and its implication for sustainable software development.
In the fourth chapter, we will discuss Documentation.
In the fifth chapter, we will discuss about management, hiring process and resource allocation in the context of a growing company.
In the sixth chapter, the focus will shift towards the office and the workplace, and its influence on the productivity of a software-focused team.
In the seventh chapter, we will focus on well-being of your employees, and how this will have positive benefit on the quality of their product, as well as the long term sustainability of your software, and thus your business.
In the eight chapter, the focus will be on effective communication in the context of software development, as well as the interaction between software division and the rest of the company
In the ninth and final chapter, the focus will shift to management best practices, and general suggested best practices for both managers and executives.

This book is open to Pull Requests on github.