Reinventing Code
When it comes to ideas or products, you want to cover new territory. It's the same in the programming world. You want to build on others' abstractions.
Sometimes, though, you just can’t help it.
We’re writing our software on the .NET platform. In .NET, all user interface elements have their own window handle in the operating system. Window handles are expensive resources. Parts of our user interface needed a lot of user interface elements, but we couldn’t afford to allocate so many window handles.
So I started writing what a critic would call a reimplementation of the System.Windows.Forms namespace [1], but using a windowless model. Whereas the .NET top level interface element is called Control, ours was called LightControl. We also had LightButton, LightPictureBox, etc.
I was only implementing about 2% of the namespace, but I was still nervous. It should set off alarms whenever you’re doing something that is both low level, and similar to something that already exists. But I just couldn’t think of any alternative.
This was a few months ago.
I was relieved yesterday when I randomly stumbled upon a blog post by Raymond Chen in which he validates my strategy. Raymond Chen is the man.
This isn’t the first time this has happened.
I wrote our own file system about eight months ago because NTFS didn’t have the right performance characteristics. We needed to store lots of small files, but traditional file systems have horrid performance in this scenario. They seek the disk like crazy! We also didn’t need directories, shortcuts, or any operations other than { create, append, read entire file, delete }. Surprisingly, a good open source implementation didn’t exist, so we bit the bullet.
The Point
First, don’t be afraid to code a variant of something that already exists. Do your homework first, but do what you’ve gotta do.
Second, if you’re making something new, don’t hide power. You might be able to save someone from having to write new code. [2]
Notes
[1] This would take a hundred developers two years to finish. Luckily we don't need all of the functionality, but more importantly we don't need an uncrashable API.
[2] I'm not blaming MS on this one. Although many criticize them for not providing a windowless control framework, they couldn’t have done so just by exposing an extra option. They're not hiding power; it's just not there.