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:
- Business has to realize or let known: When the engineering team accepts the authority of the business in deciding the priority of features, the business has to be prudent enough and trust the recommendations of the engineering team. Business has to shed off the old-school thoughts and educate itself that things like refactoring, redesigning etc. have an effective customer value.
- Promote collaborative development – Huddle with fellow developers, Discuss and validate one’s ideas
- Think twice before investing time/effort in churning code. It is easy and usual to think that it is one’s own invention!
- Resist the temptation to modify code without consulting its author, even when there is a bug.
- Someone once told me a quote- If you are writing code the way you were writing 10 years ago, you should probably change your profession. Developers should keep a constant watch on the way they write code and the way they think about solving problems. Meta-thinking! A good tool to aid meta-thinking is a hammer. 😂
- First there was Waterfall, and then came Agile. Agile is not a silver bullet. It is us who has to be agile, and know what we have to be Agile about.
- Was it Waterfall’s fault? Is it even a living thing? We always need something to follow to establish discipline, and when we fail, we blame the inanimate. Sooner or later it will happen to Agile too. In the end, we have to blame ourselves, and not any methodology, for what we did not do.
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!