Skip to main content

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!


Popular posts from this blog

Passing CComPtr By Value !!!

This is about a killer bug identified by our chief software engineer in our software. What was devised for ease of use and write smart code ended up in this killer defect due to improper perception. Ok, let us go!CComPtr is a template class in ATL designed to wrap the discrete functionality of COM object management - AddRef and Release. Technically it is a smart pointer for a COM object.void SomeMethod() { CComPtr siPtr; HRESULT hr = siPtr.CoCreateInstance(CLSID_SomeComponent); siPtr->MethodOne(20, L"Hello"); }Without CComPtr, the code wouldn't be as elegant as above. The code would be spilled with AddRef and Release. Besides, writing code to Release after use under any circumstance is either hard or ugly. CComPtr automatically takes care of releasing in its destructor just like std::auto_ptr. As a C++ programmer, we must be able to appreciate the inevitability of the destructor and its immense use in writing smart code. However there is a difference between …

jqGrid: Handling array data !!!

This post is primarily a personal reference. I also consider this a tribute to Oleg, who was fundamental in improving my understanding of the jqGrid internals - the way it handles source data types, which if I may say led him in discovering a bug in jqGrid.

If you are working with local array data as the source for jqGrid, meaning you will get the data from the server but want the jqGrid not to talk to the server anymore, and want to have custom handling of the edit functionality/form and delete functionality, it is not going to be straightforward - you need to have a decent understanding of how jqGrid works, and you should be aware of the bug Oleg pointed in our discussion. I repeat this is all about using jqGrid to manage array data locally, no posting to server when you edit or delete, which is where the bug is.

$('#grid').jqGrid('navGrid', '#pager', { recreateForm: true, add: false, search: false, refresh: false, …

Offering __FILE__ and __LINE__ for C# !!!

Not the same way but we could say better.
Visual Studio 2012, another power packed release of Visual Studio, among a lot of other powerful fancy language features, offers the ability to deduce the method caller details at compile time.
C++ offered the compiler defined macros __FILE__ and __LINE__ (and __DATE__ and __TIME__), which are primarily intended for diagnostic purposes in a program, whereby the caller information is captured and logged. For instance, using __LINE__ would be replaced with the exact line number in the file where this macro has been used. That sometimes beats the purpose and doesn't gives us what we actually expect. Let's see.

For instance, suppose you wish to write a verbose Log method with an idea to print rich diagnostic details, it would look something like this.
void LogException(const std::string& logText, const std::string& fileName, …