Another "Ruffin reacts to whatever Joel's pushing on his site lately" blog entry, in this case a response to a Joel's blog on Biculturalism, here talking about what's different in the land of software development between stereotypical Windows and Unix programmers.
Microsoft Internet Explorer itself is nothing but a tiny 89 KB program which wraps together dozens of very powerful components which are freely available to sophisticated Windows programmers and which are mostly designed to be flexible and powerful. Unfortunately, since programmers do not have access to the source code for those components, they can only be used in ways which were precisely foreseen and allowed for by the component developers at Microsoft, which doesn't always work out.
...The Unix cultural value of visible source code makes it an easier environment to develop for.
That's simply not true in the sort of set in stone fashion Joel delivers it. Let's take the The Tale of J. Random Newbie that Joel points to (itself written by Eric Steven Raymond) as proof -- in that anyone who's programmed can immediately see the truth in the tale.
In desperation, [after trying to use closed-source libraries that cause memory leaks and other problems,] Newbie starts making his own bricks — simulating less stable library services with more stable ones and writing his own implementations from scratch. His replacement code, because he has a complete mental model of it that he can refresh by rereading, tends to work relatively well and be easier to debug than the combination of opaque components and workarounds it replaces.
Newbie is learning a lesson; the less he relies on other peoples' code, the more lines of code he can get written. This lesson feeds his ego. Like all young programmers, deep down he thinks he is smarter than anyone else. His experience seems, superficially, to be confirming this. He begins building his own personal toolkit, one better fitted to his hand.
Unfortunately, the roll-your-own reflexes Newbie is acquiring are a short-term local optimization that will cause long-term problems. He may get more lines of code written, but the actual value of what he produces is likely to drop substantially relative to what it would have been if he were doing successful reuse. More code does not equal better code, not when it's written at a lower level and largely devoted to reinventing wheels.
Newbie has at least one more demoralizing experience in store, when he changes jobs. He is likely to discover that he can't take his toolkit with him. If he walks out of the building with code he wrote on company time, his old employers could well regard this as intellectual-property theft. His new employers, knowing this, are not likely to react well if he admits to reusing any of his old code.
Let's take Joel's idea that open sourcing fixes this issue/makes things easier to program for on two levels.
1.) In house code.
2.) Third party code/libraries.
1.) Raymond is obviously not talking about in-house, whether the source is open under your IP agreement or not. But if you try to extend this "lesson" there, it should be said that you'll be making a huge mistake. Though it'd be great to have J. Random Newbie point out the bugs, you might not necessarily want him fixing it. But you most certainly should have some process for getting the bugs fixed quickly.
What's most important about libraries is that they work as advertised and have excellent documentation. The code should look great too, of course, but there are legimate reasons to keep that closed. These lessons can range from not having J. Random in there hacking in poorly constructed band-aids to keeping your IP your IP. In fact, you'd rather not give others the ability to hack the original willy-nilly, as those fixes might not ever make it back through the checkin process to the original process. That make sense?
You need to have a process (pointy hair DOWN) for bug fixes libs and first-rate dev documentation. The bottom line is that if you're having these problems in-house, Newbie's done you a great favor by pointing out that you don't have first rate, bet your company on it level code.
(Which also makes me note that the story is stereotypical in that Newbie never tells anyone that he's having trouble. There's no management worth a rip in this one, or even a more senior programmer buddy. This is why you can't hire a simple computer geek and think you're ready to lock him in a room and expect great code as a result. Communication skills are awfully important -- and geek skills in your managers are every bit as important as that. Meeting half-way can't be rated highly enough.)
2.) You're using code from a company whose code sucks. Stop using it.
Sometimes you can't help it -- that company's the 800 lbs. gorilla in your marketplace (ESRI comes to my mind). In this case, you absolutely do need to do what Newbie does first in the story -- make ugly workarounds and document them. In this case, open sourcing the code would do squat for me and even less for, say, ESRI. I'm not going to have the time to figure out what's going on (eg, Furthurnet's code), much less fix it. I need to tell the [ESRI-like] company stuff's broken or be happy with the workarounds -- or do my best to start a rival in the marketplace.
(Now there's where open source helps. Do I have time to start a rival company to a multi-million dollar profit, farily danged large co? Of course not! But, hopefully, there is an itch I can scratch that, put together with everyone else's itches, make for a relatively stable alternative. Then, once you hit critical mass, you can put a company on top of that for support on installations, etc. But that's pretty pie in the sky.)
Anyhow, that's this morning's ramble. Libraries are, at least in theory, the best way to go, even if the code itself is open sourced. Clean, well-documented break points are necessary for good code reuse, and if your third-party provider, again, open source or no, can't give that to you, you're using the wrong software.
posted by ruffin
at 12/29/2003 09:35:00 AM