Reusability Rant
During my lifetime (so far) of programming I've worked on a many projects that were built around or including external libraries and components. These are packaged units of software purchased from a vendor for a specific purpose. However, no matter how useful the software claimed to be, the specific purposes these packages were designed for never quite matched the specific purpose we were attempting to apply them to.
Never having been directly involved in these purchasing decisions I can only imagine the reasons that led to them. I suppose it must have seemed like the easy way out. Instead of building up expertise in a particular domain, you could just buy that from someone else, plug it into your project, and away you go. The costs of these libraries were minuscule compared to the cost of the expected effort that would have gone into rolling our own. And no matter how many times I'm certain this all must have seemed the truth, the reality was far from it.
Because the software never actually did exactly what we wanted it to. Maybe 70 to 80 percent, sure, but never all that we wanted and so we had to compensate for what it did not do. Now, this would not have been such a big deal if the package was designed for extensibility from the beginning, but not many were, and even those that were often allowed extensions only in areas we cared not to go. So, in order to actually get what we wanted we had to work around the flaws ourselves.
Usually, this lead to a lot of trial and error, building advance frameworks to augment or encapsulate the purchased piece, that often solved many of the shortcomings, but never quite all of them, and certainly not the most critical. Eventually we would reach the conclusion, over many months, that the only plausible way to achieve our goal was to modify the actual source code, of which we did not have.
Now you might think that we ought to have abandoned ship at this point, to just take our lumps, learn from the experience and move on. We would most certainly have gained enough knowledge to understand exactly what we wanted and would have been able to build it ourselves. That might have even been true in some cases, but not entirely practical. As the project evolves you only learn about its true cost as you forge onward, only aware of any additional costs after you are so deep in that backing out still seems more costly than plugging ahead. Of course, you never really appreciate the full cost until much later, and by then it is just too late, you've used up a year or two and it is time to ship your product.
Of course, if you flash enough money you can convince any vendor to turn over the source code, provided you are not going to resell it, etc. And that's usually what happened. We'd pay handsomely for the rights to modify the code, and we would do it, fix what we did not like, add what we needed and be done with it. Our product would ship. We'd have a party and then relax for a few days. And then we would hear about the big dreams for the next version, the new features and purchases already made.
I suppose that's why I sort of chuckle anytime someone talks about reusable software components. Because, it's mostly a myth. It only ever works in misguided wishes and dreams.
Software is only truly reusable at the source code level. Read it, learn it, write your own.
Comments
- Anonymous
July 19, 2004
Wow, and I thought I was alone on this one. I cannot begin to express my complete agreement through 10 years of experience on this item. Ususally not being the one involved in the purchase but mandated to implement the product(s). I just wonder what stories you could tell us now about just how stubborn those who made the purchase were to move beyond all logic and include it in the project at all costs! I certainly could! And interesting that the purchasers are soldom those who have to work with it :) - Anonymous
July 19, 2004
The comment has been removed - Anonymous
July 19, 2004
I would agree with you that particularly constrained problems can have solutions that are generally reusable. I was not implying that all such frameworks are inherently bad. Certainly, the string class in .Net is fantastic for the most part, but many string libaries in the past were utterly horrible. Still, its not these types of libraries that I'm referring to. I'm thinking of more verticle market style products that try to capture a lot of stuff in a general (and therefore not so useful) sort of way.
For example, you want to display nice bar graphs in your app. Goobysoft has a bunch of graph drawing controls that you can just pop in. Great, except they don't support the exact correct style you want, type of axes, units or whatever. Maybe the tick marks point the wrong way and you need to change that, but you can't because there is no such option.
There is nothing wrong with the product as is, it just doesn't match your exact need. The purchaser figured it was close enough, so it was a real bargain, except the effort you put in to get the final few features out of it ends up costing you more than it would have to write the thing yourself.
If details matter to you, and you really think your best option is to buy from someone else, then you need to consider the cost of the source code up front, because you will most certainly need it. - Anonymous
July 19, 2004
Lazycoder weblog » MS employees continue to advance towards an open source mentality - Anonymous
July 19, 2004
Really, are you serious? Do you write your own relational database server? Or do you only use an OS that you have the source code to? Maybe you wrote your own compiler, too? I guess you don't use any of the classes built in to the .NET framework, either. I'm sure your forms engine is better than WinForms.
This is one of the silliest pieces I've ever read. You clearly don't appreciate the giants on whose shoulders you stand. - Anonymous
July 19, 2004
The comment has been removed - Anonymous
July 19, 2004
The comment has been removed - Anonymous
July 19, 2004
The comment has been removed - Anonymous
July 20, 2004
The comment has been removed - Anonymous
April 14, 2007
I have been throwing around ideas for writing my own operating system for a while (OK, so call me wildly ambitious -- I am). I have two goals in particular for this OS that I was happy to see an application for in this post: it would be open-source (no cost to see and modify the code) and even the GUI would be built on a greatly expanded pipeline model, a little like PowerShell's, but much richer (allowing piping applications together).