A-Team Library

A short while ago, I had to write a compelling document for a client about a library that I had developed during my tenure, call it A-Team Library or ATL. Having to learn the “eyes-wide-shut” culture to maintain the couples-of-decades old code and simultaneously develop on the top of it was very disheartening. It was time a lot of things were given fresh thoughts. Not the least of all duplication of code and functionality. But not just that. Like in a programming language, when there is more than one way of doing something, when those ways are opposing, it causes nothing but confusion. So was the case. The business seemed to be far from realizing it.

Instead of showcasing the issues that were being faced and yet not realized, let me state the alternate – how things in such cases can be better:

Of course, none of this can be reasoned across the table without winning bureaucracy! On the other hand, documenting it would be a better approach. The document would be a mind voice. I was diligent to focus on the issues(s) rather than the person(s). Generally speaking, the issues are commonly occurring although their flavor would differ from case to case. Among the several issues that were making our jobs mundane and tedious, I narrated top 10 in the document – introduce the issue, its effects, solution, how it can abstracted for reuse and reliability, how my library solves them and yields actual business value etc.

In that document, towards the epilogue, I had to persuade the intended client audience to realize that such issues existed in the system, establish discipline and accountability, and develop a culture of solving the issues with a holistic mindset. In a way, I had to implore the desired audience, at a philosophical level, emotional level. That climactic court room like dialogue is what this post showcases: A-Team Library.

ATL was a bag of things – lot of classes, functions, scripts, utilities, techniques and practices, which when adopted as a (company) standard and managed with discipline guaranteed effective business value (time/effort/cost). Besides saving developer time for better use and increasing the reliability of the code, it would eliminate the mundane testing, not necessarily manual, and pave way for automating the scenarios(regress and beyond), which eventually provides confidence to release the final product when new features/changes are introduced – a value that the business wishes to have and demands!