components  ->

Beans, beans, the musical fruit...

One of the Holy Grails of computer science PhDs and marketing types is "components". Java earns rave reviews for making it easy to use components. Components are not our friends.

<vsync> that package is somewhat bizzarely implemented
<vsync> the way its classes are organized
<dieman> well. yeah. i would expect that.
<dieman> it was a c application.
<dieman> its not like you can sprinkle farie dust on it.

(#kuro5hin on slashnet)

It is assumed that once you take an ordinary software library and transform it into a "component", magical things will happen. You will be able to take your Word Processor Component and fit it to your Spell Checking Component, and they will just work.

In reality, of course, several things will need to happen. First, both components will need to have moderately similar paradigms for the information in question. For example, text editors use different and hotly contested methods for keeping track of line breaks. Second, the interface between the two components will need to be defined. This means APIs, and programmers actually reading them and writing code.

"Components" don't magically solve anything, and assuming they can just causes the creation of various predefined boxes to stuff your code in, which just makes your job harder and usually doesn't make the job of integrating the pieces together later any easier. Even if you have the complete source code, the original author almost certainly had somewhat different goals in mind than you, and the different pieces will connect in various disjointed ways, causing all sorts of trouble later.


Having almost convinced themselves that they had made software components a success, these same experts then looked at various fine American corporations and decided that everyone working together was a Bad Thing. So they fired a bunch of people and then hired companies to do the job these people had just been doing. (See the inspirational poster)

Don't get me wrong. I'm all for focusing on core business goals and things like that. But at some point organizations need to be self-sufficient, for several reasons:

  1. You really want the people running your network to have some clue what you're trying to accomplish with that network, business-wise. You want them to share in this goal. This is much easier if you write their paychecks.
  2. With abominations like ".NET", you are suddenly having all your mission-critical confidential information processed by an external entity, off of its servers. In this case, the entity in question "innovates" pretty much everybody in its path.

When I left, Sun was outsourcing its entire IT department. This created such interesting situations as when I wasn't getting assigned an DHCP lease and walked over to one of the few "networking" guys around. He was able to pinpoint the problem, take me to the room full of cables, and show me exactly what was going on. But he wasn't allowed to even look at the servers because they had taken that portion of his job away. They had gone so far as to change the passwords on him. (Incidentally, it was a "known issue" that there were more IPs needed than were being given out, and the official solution was to sit and wait for someone else to unplug.)

Come on, executives. Let your own people do a little of the work themselves. Things will tend to work better and employee morale will be a lot higher.

school work code mind log
AIM: TimHowe
ICQ: 18784951
Yahoo, Slashdot: vsync64

Last modified: Sun Nov 12 04:44:23 PST 2000