After having been working in consultancy in a variety of companies, I have witnessed the following process over and over;
- Consultancy project “A” is sold to a customer.
- Software “A” is made to meet the customer requirements.
- Because of resources restrictions, the software “A” is done as a monolithic block. It is “integrated”.
- Software “A” works, and gets the management recognition. The bespoke software “A” becomes a part of the company catalogue for other customers.
some months pass
- The management proposes to offer software “A” for the project “B”. This seems logical because “A” and “B” are in the same domain of expertise.
- Engineers agree to modify software “A” to do “B”.
- After a month of work, engineers find out that adapting “A” to “B” is impossible, and after convincing the management of it, they produce software “B”, again as a monolithic block to match the requirements of project “B” due to the resources constraints. Best practices? there’s no time for that.
- Software “B” works. Now there are two bespoke software pieces to be offered in the future.
- The cycle continues, while the management claims that they need to improve revenue, cut down costs, etc.
This is the usual modus operandi of a software as a product company. In such organizations, the software is seen as a commodity, with little to no added value other that the person-hours used to produce it. Because the software is seen as a commodity, there is no added value in a good design nor the use of best practices in order to recycle that knowledge (to scale). However the management asks for actions to scale, which in business neo-language, translates into more hours per the same salary per employee.
Software that scales
The first intuitive feature of a computer program is that it automatizes something, it does something faster or better than a human being. This is the low hanging fruit of producing software and it is almost always achieved. Even the most horrific piece of software will be faster than a human being at calculating.
The second, and most important feature of software is that it can be incremental. This one is harder to achieve, because it is not obvious. This feature implies that the addition of every new feature takes less and less human work as the software evolves, making the potential marginal revenue higher. This feature is explained in the book Clean Architecture by Robert C. Martin.
If there comes the time when to add a new feature is more complicated than to re-write the whole application, that is the empirical prove that the software is not scalable.
So, how does one make scalable software in a consultancy-like business?
Make libraries and never monolithic “integrated” blocks. Once you have a working library that is tested, you can add communications, GUI, etc. When another project comes, the library shall be the core of the new project, having the chance to discard the customized layers added on top.
Write technical documentation of the libraries. This separates the wheat from the chaff, and shows that the code does actually have a scientific background. At least an informed reader can discern if the science behind the code is good enough for the new purpose.
Make libraries and technical documentation available in the organization. If a department (or even an individual) is being scalable, there is no good reason to keep that isolated. Everyone in the company should be aware of the company’s state of the art, and have the chance to benefit from it.
By implementing these simple rules the projects revenue explode. I have examples where months of developments reduced to hours for an equivalent outcome.
- Make libraries (packed knowledge)
- Document the knowledge.
- Make the knowledge available.
I spoke about software because the examples are perhaps clearer to see, however this applies to all human activities including regular consultancy. If from every project one can extract the core of it in a document of some sort, it is already scaling up for the next time by having ready-to-consume knowledge. And that is the key.