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!

Labels:

Comments

Post a Comment

Popular posts from this blog

Extension Methods - A Polished C++ Feature !!!

Extension Method is an excellent feature in C# 3.0. It is a mechanism by which new methods can be exposed from an existing type (interface or class) without directly adding the method to the type. Why do we need extension methods anyway ? Ok, that is the big story of lamba and LINQ. But from a conceptual standpoint, the extension methods establish a mechanism to extend the public interface of a type. The compiler is smart enough to make the method a part of the public interface of the type. Yeah, that is what it does, and the intellisense is very cool in making us believe that. It is cleaner and easier (for the library developers and for us programmers even) to add extra functionality (methods) not provided in the type. That is the intent. And we know that was exercised extravagantly in LINQ. The IEnumerable was extended with a whole lot set of methods to aid the LINQ design. Remember the Where, Select etc methods on IEnumerable. An example code snippet is worth a thousand
7 comments
Read more

Implementing COM OutOfProc Servers in C# .NET !!!

Had to implement our COM OOP Server project in .NET, and I found this solution from the internet after a great deal of search, but unfortunately the whole idea was ruled out, and we wrapped it as a .NET assembly. This is worth knowing. Step 1: Implement IClassFactory in a class in .NET. Use the following definition for IClassFactory. namespace COM { static class Guids { public const string IClassFactory = "00000001-0000-0000-C000-000000000046"; public const string IUnknown = "00000000-0000-0000-C000-000000000046"; } /// /// IClassFactory declaration /// [ComImport(), InterfaceType(ComInterfaceType.InterfaceIsIUnknown), Guid(COM.Guids.IClassFactory)] internal interface IClassFactory { [PreserveSig] int CreateInstance(IntPtr pUnkOuter, ref Guid riid, out IntPtr ppvObject); [PreserveSig] int LockServer(bool fLock); } } Step 2: [DllImport("ole32.dll")] private static extern int CoR
3 comments
Read more

sizeof vs Marshal.SizeOf !!!

There are two facilities in C# to determine the size of a type - sizeof operator and Marshal.SizeOf method. Let me discuss what they offer and how they differ. Pardon me if I happen to ramble a bit. Before we settle the difference between sizeof and Marshal.SizeOf , let us discuss why would we want to compute the size of a variable or type. Other than academic, one typical reason to know the size of a type (in a production code) would be allocate memory for an array of items; typically done while using malloc . Unlike in C++ (or unmanaged world), computing the size of a type definitely has no such use in C# (managed world). Within the managed application, size does not matter; since there are types provided by the CLR for creating\managing fixed size and variable size (typed) arrays. And as per MSDN, the size cannot be computed accurately. Does that mean we don't need to compute the size of a type at all when working in the CLR world? Obviously no, else I would
Post a Comment
Read more