OSNews

> The Reusabiliy Fallacy
This is so far from the truth in the corporate world that it hurts. We spent quite a bit of time setting up a reusability framework for our (very) specialist area. Turn around time on new projects now is almost 1000% percent faster using the framework classes than rewriting, making our clients (and my boss) much happier. Plus, a fix in the framework fixes five products simultaneously. Dynamically loading class frameworks means that we ship a single patch DLL rather than having to reship our entire product for an upgrade or a bug fix, plus reducing our testing and deployment requirements for each change.


I couldn't agree with this more. I spend a little extra time building a generic framework for certain application areas and it saves me huge amounts of time on subsequent projects in that area. For instance, I spent the first 2-3 years at this company building software interfaces for hardware that communicates serially over RS-232, RS-422, or TCP/IP. Building a simple component to send and receive data over RS-232 or TCP/IP based on user (or administrator) configuration and then reusing that component (in combination with an RS-232/422 adapter in hardware) saved more time than most people would believe, especially in debugging cycles where new equipment sometimes used different commands from older versions. The applications for 7 different pieces of equipment with as many as 4 different command sets per item (in other words, 4 incompatible versions of the same type of hardware) have a generic input and output command that gets routed to/from the component rather than having to deal explicitly with the communication interface. Not to mention other areas of reusability, such as user interface elements (for example, a display that allows the user to press an up or down arrow for each digit of a 5-8-digit value that handles roll-over, decimals, and min/max values, also allows the user to click on the value itself to input a specific value, is administrator configurable, and hands off the data in a manner that is easily adaptable to the hardware.

Those are just simple examples of reuse. In many cases, entire applications were made from a handful of custom components, many of which were later inherited or updated to add functionality for devices that didn't exist when the initial software was written.

Where would the world be without MFC (ok jokes please), Win32/FX, libXML, OpenGL, DirectX, Qt, standard libraries, etc. etc.? You talk about writing your text editor -- try doing the GUI without using a reusable class such as CWindow/CView (MFC), NSWindow (Cocoa) etc. you'll find (unless you're using VB or the like) that's it's quite a challenge.

and even if you're using VB or the like, you ARE using those reusable classes, you're just not handling the dirty work yourself. Look through the code in a VB.Net project sometime and you'll find all of the details of dealing with Windows.Forms are very similar to the way the same thing is done in C# or Managed C++.

"A software component can be copied without any cost"
Until you find a bug in the original component code, and then have to make the same bug fix through EVERY product that you've written, rather than just re-linking against an updated library. Or, you find a huge speed improvement in the original code, and to affect that change in all your products you need to manually change each copied section of code EXACTLY the same. Then test each new change individually. The cost is huge in comparison.

Exactly, copying code only has no cost to someone that doesn't pay (or get paid) for a coder's time. Re-linking is computer time, which doesn't always have to impact a coder's time significantly. Re-writing/Re-factoring/Re-implementing/Re-copying code is something generally done with some degree of human interference that's at best a little more significant than re-linking or even a complete re-compile.

And these are just a few comments -- there are so many things wrong with this article that it's hard to find anything that's right.

This is so true that I'm not even going to add my own comments to the rest of your post. The article can only fall back on poor english for an explanation of how it managed to get so much so wrong.