Seven Lessons Learned When Growing Your Configuration Management

When a company’s staff, product count, and release frequency grow rapidly, configuration management faces new challenges and opportunities. This article shares the main problems organizations encounter at such stages and the improvements needed in processes and tools.

Starting in 2004, the author led a configuration‑management team at a small firm of about 40 developers with two product lines and long release cycles. Their setup consisted of a popular source‑control system, an outdated defect‑tracking tool, and cryptic shell build scripts, managed by just two engineers.

As the company grew, the first lesson emerged:

1. When hiring more developers, be aware of the additional configuration‑management overhead.

The original defect‑tracking tool became unmaintainable and costly, prompting a switch to a more advanced (though expensive) tool that dramatically simplified reporting and customization. This led to the second lesson:

2. Customizations to tools must be governed.

Conflicting requests from different teams required a tiered approach to custom‑feature implementation, ensuring only approved changes were made.

After being acquired by a larger enterprise, rapid staff expansion (sometimes 10% per month) forced the team to continuously review three areas: tool scalability, processes, and cost.

3. Expand the underlying database and file system to support higher concurrency and performance.

Investing in powerful hardware allowed the team to handle larger data volumes without performance degradation.

4. Bring build environments under control, especially when multiple build servers are used.

Instead of buying many physical machines, the team purchased a high‑end server and ran ten virtual build machines on it, using snapshots for quick rollback after failures.

Parallel distributed builds reduced overall build time, while a new graphical build tool replaced unreadable scripts, enabling developers to trigger builds without configuration‑management intervention.

5. Adopt mature third‑party tools early while the organization is still small.

Building custom tools proved unsustainable; switching to proven external solutions saved time and money.

6. When the number of developers exceeds a certain threshold, traceability becomes mandatory.

Linking source control commits, defect/ticket items, and build information ensured visibility and accountability across a team of over a hundred developers.

7. Continuously evaluate the cost of your tools against market alternatives.

Periodic cost analysis led to replacing an overpriced defect‑tracking system with a solution thirty times cheaper, and the team is now assessing whether to replace their legacy source‑control system as well.

In summary, managing configuration at a growing company requires proactive planning, cost‑aware tool selection, scalable infrastructure, disciplined processes, and constant market‑price comparison to stay efficient and effective.