In the Matter of Component Architecture

In the Matter of Component Architecture is a fantastic piece on the value of code reuse which appears to have been written merely as an email to a mailing list.

Software as it is currently being developed provides so much value relative to its costs that we as practitioners of this medieval-class craft can get away with practices that would not be tolerated by a Taiwanese manufacturer of toasters.

2 thoughts on “In the Matter of Component Architecture

  1. It’s all the fault of licenses. Starting at the beginning of that piece; I can buy a jar of peanut butter, take it home and do what I want with it. Instead, imagine if the jar came with a license saying that I’ll only use it on pre-made bread of type X or Y and absolutely not that hippie open-recipe bread and that it cannot be shared amongst my friends, they must buy their own jars. Would you buy it? Now multiply that by the number of items you use in your breakfast task (tea, milk, sugar, kettle, cereal etc.), each with their own slightly different licenses.

    Imagine if Coca-Cola ordered a warehouse where the license said they could only store bottles of Coca-Cola in it. One day, Coca-Cola discover they’ve made a few too many cans and need somewhere to store them. There’s some spare space in the bottle warehouse, but the license prohibits them from doing so. Oops!

    A lot of NIH syndrome stems from the license terms of other software being unacceptable, or the existing solutions aren’t quite flexible enough to do what you need with them. When you license something closed-source that you cannot modify, you’re handing over control of a large part of your organisation to some random company whose only goal is to take as much money from you as possible.

    Taking those above points into consideration, is it any wonder that people re-invent the wheel all the time in software engineering?

  2. “The Sears Department stores of K-Mart Corporation will sell you an adjustable wrench that not only has a guarantee … they will even replace it if you broke it because you damaged it on purpose. … I do note that their more complicated appliances don’t have this strong a warranty…”

    And there’s the clue: software is much more complicated than a wrench, and far easier to break. Making a peanut-butter sandwich is a well-defined task with a clearly-defined set of tools, and it isn’t complicated (even if you add the jelly component).

    But if I write software, it could be used on a variety of platforms and different kinds of hardware, to process all manner of weird data for which it may or may not have been designed. There are too many variables to offer a cast-iron guarantee, and the vendors who give the appearance that they do so are usually selling false promises (just read the EULA fine-print).

    Writing software is more on a par with performing surgery or offering counselling than it is with building houses (“architecture” is such an unfortunate word in this context, because it implies rigidity and precise definition). I bet you will never find surgeons, psychiatrists, etc, who will offer a guarantee that it will “just work” — there are too many variables, they’d be mad to even entertain the notion. Likewise, for all the attempts to tie software writers’ hands with strict coding conventions and inflexible languages, eventually you will have to admit that what you want is a talented team with commitment and energy. Whether or not to use an out-of-the-box component or craft one yourself should be left to your better judgement. We accept this in other walks of life, so why should programmers be relegated to the level of electronic burger-flipping?

    (PS: Seems to me this has all been discussed before, but the supposed solutions always fall down to a greater or lesser extent. New methodology, anyone? I’m sure that’s never been proposed before… ;)