I would like to submit a new term into the lexicon of software developers. The Cage Builder. You may not be familiar with the term (I'm pretty sure I made it up) but you have almost certainly worked with a Cage Builder. The CageBuilder is that programmer (often bearing the title "Architect" or "Principal Achitect" or "Chief Scientist") who hold certain beliefs:

1. That they are far smarter than almost anyone except the few Superstar Programmers they hero-worship.
2. That every API created offers the Proletariat developer too much freedom; freedom to screw things up
3. That the Proletariat developer must be protected and hand-held through their own ineptitude
4. That this protection should come in the form of wrapping APIs and marking certain language constructs as forbidden

The term, CageBuilder, then, refers to the idea of creating a small realm in which the poor mortal programmer can still add value to a team without doing anything crazy.

Two things happened lately that made me think about my old enemy, the CageBuilder. The first one was here. I want to quote one of Rocky Lhotka's responses:

"However, just because some small number of elite programmers figured out how to make CORBA or DCOM work and version very effectively doesn't mean that the vast majority of programers have it all figured out."

That bothers me a little bit. Just becuse a technology or idea is not accessible to 100% of the programming populace does not mean its worthless. If something is the best solution it shouldn't be thrown out. This seems to be part of an all too common mindset mentioned in CageBuilder point #3.

The next item came in the form of someone trying to "protect" me by wrapping an API. I am working with an interesting piece of hardware right now, a Digi ethernet/serial bridge. You plug devices into it that operate over a com port. This device them maps certain IP address ports to the COM ports. This is useful in wireless sitiuations, I put this device on a wireless network and now I can access my various COM devices wirelessly by just connecting a System.Net.Sockets.TcpClient to the right port and sending the right Ascii/Hex commands to the devices and reading the responses from a raw socket. For each COM device connected, there are two ports offered: Telnet and RAW socket styles. By definition, Raw means "This is just a socket, read and write whatever you want to it, I'll just pass it along." I spent a couple of days fighting with why the reponses from my COM devices are "almost" right; visually inspecing the Hex data looks correct except with an extra byte here or there, which is enough to make Checksums wrong, APIs throw exceptions, and give me a headache.

I'm working with an individual who knows the ins and outs of COM programming better than I, he suggested we try a test whereby my CF program just connects to the IP socket (bridged to a com port by the Digi) and he connects to the other end with Hyperterminal, this would prove the Digi was passing information untouched. Sure enough, the "raw" socket was escaping escape sequences, so 0xff was being sent as 0xff 0xff. Were the firmware programmers thinking if I ask for a Raw socket, I don't really mean it?

Why is the CageBuilder wrong?
Most developers must be TAUGHT. I don't know how many times I've heard people complain that there is no shortage of developers, but definately a shortage of good developers. Yet, things like college internship programs and such are practically nonexistant these days, at least around here. People learn from mistakes and forcing people to work in a cage to prevent them from making mistakes is a good way to keep them from learning. Not everyone has the time or aptitude to advance themselves by coding at home, but anyone can improve over time given the chance.

Throwing away the best solution because not everyone will (immediately) understand it is not a best practice. News flash: software development is complicated. Many people like doing it because it is complicated. If a complicated solution is what gives your customers the best system, and enough people can figure it out to make it stable and supportable without flying someone in from another state/country, then thats what you should give your customers.

Most CageBuilders are not smarter than the people who designed the platforms they build their cages on. Microsoft does not spend billions of dollars envisioning, designing, creating testing, refining the .NET platform just for someone to tell me "You should never use threads" even if it is obviously the best solution. I once worked under a CageBuilder with an O/R mapping framework. Adding a new table to the application with "select *" support required a 16 step process and the modification of no less than 10 factories and interfaces and type-safe constant collections. This is an excellent example of the "benefits" of trying to protect developers from programming languages.

I am not yet done telling the story of the CageBuilder. However some people (you know who you are) pointed out that I should get something out here.