Prioritize your tooling
When building a new software system, engineers must consider many aspects. Understanding the functional and non-functional requirements, deciding on the architecture, technologies, data needs, etc. All of these considerations, among others, are required to build a system that fits the needs of the business in the short and long term.
Management and operations are not prioritized
An aspect that is not prioritized is management and operations in the longer term. Tooling is usually an afterthought once the system has been around for a while and is stable.
The problem with building tooling for a system in production for a considerable amount of time is that, at this point, making a case for operational and maintenance needs becomes hard as there is no clear ROI to the stakeholders, who are thinking ahead towards the next big thing that is needed for the business to stay competitive.
Once the operational overhead becomes so high that the engineering team spends most of their time maintaining and adjusting the system's configuration, the automation of certain steps and the need for tooling to enable the stakeholders becomes a priority. The problem is that, at this time, creating these tools for the system is extremely expensive.
As time passes, systems grow in complexity, and due to the rotation of staff, the knowledge gap requires a considerable amount of time and effort to build a complete understanding of the system and domain, as well as create relationships with the stakeholders all of which are required to build successful tooling.
Prioritize the tooling from day zero
I believe a better way of building systems is to prioritize the tooling from day zero, regardless of what type of system it is, even if it is an experimental system where the future is uncertain (is it ever certain?).
An initial barebone tooling provides the foundation for the tooling to evolve as the system evolves, allowing stakeholders to provide feedback early on. Another benefit is that this process provides insight into misses in the initial requirement collection at an early stage.
I suggest reducing the scope of the system initially if needed to prioritize tooling, make the necessary changes in your team to enable a group of people to focus on the area, the gains of this will be seen throughout the life of the system for many years to come, allowing the business to move even quicker as requirements and staff change, providing a real competitive advantage.
Published: