Before reading this page, please read the relevant blog post: A-Team Library. This page is an excerpt of a climactic court room like epilogue of a document that was authored for one of the clients I use to work with. The actual context and details have been omitted. The excerpt has been borrowed and tailored a little bit for public reading. The tone and message remain the same.
We shape our tools, and thereafter our tools shape us – Marshall McLuhan.
So much time and energy are spared every day building something that is a pattern. If it is spent on abstracting individual instances to an idea, it can be implemented in a way so that reuse yields business value. It is only after using ATL that one would believe it saves time and money.
At the time when feature XYZ was being developed, all other teams were sincerely developing in whole or parts the necessary or missing pieces to put XYZ in place. My team (A-Team) did not require one line of code (including the backend) to embrace XYZ. The intention is not to underestimate or discredit the honest efforts of other teams but to propose and present modern ways to build software that would truly benefit the business. So the offering from my team was almost zero cost to the business for implementing and adopting XYZ. Some might critique that there is still the cost to test. Following is the counter argument:
« contextual counter argument » … but it is safe to say that we can depend on the libraries from A-Team.
All we had to do for XYZ adoption was add a configuration line item. In an ideal world, we shouldn’t have to even add that. Imagine how rest of the applications would benefit the business if conceived and implemented that way.
ATL is built based on real time use cases or usage scenarios. The library defines and sticks to the semantics so that the developer can concentrate on high-level concepts or business problems, not mundane details. It helps the developer think of what instead of how. Besides satisfying the basic needs (commonly use cases), the libraries can be extended if needed. The end effect is that the amount of code churned is relatively reduced and at the same time produce code with a clarity of business logic.
Too Long, Didnot Read Syndrome – Readability is the first enemy of software maintenance. The library is guaranteed to make the user code succinct and human readable. Less code avoids TLDR syndrome. Less code there is to read, the higher the odds are that someone will actually read it.
The library in itself is succinct and uses advanced features of the language. Some of the limitations of the language are actually taken advantage of. It is not about some reductio ad absurdum contest where we use up all the clever tricks in our books to make the code fit into a less physical space. It is actually practical, sensible strategies to reduce the volume of code an individual programmer has to read to understand how a program works.
Why do we need to take so much pain → rephrase → effort in doing these things? It is a tricky question to answer. Typically the truth in the answer is subjective. Software is an intangible thing. Unlike most other branches of engineering – civil or automobile, it is difficult to identify and realize the right way to write software. Worse, it is even more difficult to prove it because what seems right to one may not be so to the other. Most other branches of science/engineering have laws (of nature) that we cannot break or positively stated, we can depend on – force, gravity etc. For instance, if I were to build a bridge, I have to obey nature’s laws – the length between the pillars being proportional to the maximum wind force. Failing to do so will have tangible results.
Over time, we seem to have found only one way to identify and confirm the right way to build software. Different people say it in different words, but it means the same. One has to look through the mind’s eye, and think how we intend to solve the problem, and also how long and how well will it withstand the test of time. That enlightens us with the solution of the time!
In other words, we have to identify patterns, create models, and discover abstractions. We have to establish our own laws in software, more appropriately stated, define our conventions. Doing so prevents the butterfly effect in building and maintaining software. Or … get control over the butterfly effect, if you will.
It is on these core principles that the ATL is built: abstract, reuse, extend!
EPILOGUE
Our ability to imagine complex applications will always exceed our ability to create them – Grady Booch, Father of Object Orientation
Time isn’t enough to think about and document all the different ways we can improve our software. Sometimes, or most times, we just have to do it. There are lots of radical improvements that would truly benefit the business. For instance, imagine the code base that does not to physically have CSS per sister-site, or any configuration for that matter, on disk. Imagine the day when adding a new sister-site is just a click of a button, truly a click of a button. That is the horizon we should aim for. We may never touch it, but we can definitely learn a lot and reap some benefits in its pursuit.
It was never the effort of one man. It has been the collective effort of the minds of the A-Team since the beginning. Even if denied by modest and affectionate team members, ATL has always been a product of inspiration, passed on from one to another.
