Coding Around Ignorance

An AntiPattern. You don't know that your library has a factorial function, or an HTTP implementation, or a balanced tree implementation, so you write your own.

The result is that your code is bigger, people who use your code have to go to the trouble to learn your interface to balanced trees, even though they may already know the one in the library, and you have to work out all the bugs for yourself when they would have already been worked out for you in the library.

Furthermore, anybody who gets your code will feel the urge to rip out your reimplementation of the existing idea, and alter the rest of your code to use the standard implementation. This can take a lot of time, and subtle differences between the two implementations make it harder.

However, sometimes you look at a piece of code and think this was done, when in fact ignorance was never the problem. Maybe the library's interface was awkward so you implemented your own to get around its misfeatures. (Writing your own iterator with JavaGenerics, to look like a CeePlusPlus StandardTemplateLibrary iterator, rather than using Java's iterator, is an example. It is more like GreenSpunning than CodingAroundIgnorance, but can you call it GreenSpunning if you are trying to implement half of C++ instead of half of Lisp?)

This problem is aggravated by large and disorganized libraries, and poor documentation.

So What?

This is one of the reasons we should ReFactor. No one is going to be an instant expert on any new language, library, external module, etc. It is far better to wade in, get one's feet wet, and get something operational, rather than trudging through endless documents and web pages in the vague hope that it is already done for you. One should take his best shot with what he knows at the moment, and if a better way is found in the future, simply go back and apply it. There is no crime in not knowing everything, nor in going back and improving code as one learns more.

[Also one has to take a break-even view, if there is a project that has a deadline and you estimate it will take x hours to learn the library, y hours to come up with algorithms yourself based on what you already know, you usually opt for the shorter. Sometimes you start with the library, thinking it will take x, run into problems, realize it is going to take x+x' not sure if this will become x+x'+x''..., then opt for the harder but more certain y and KludgeItTillItWorks]

AKA the ReinventingTheFlatTire? AntiPattern.

CategoryAntiPattern CategoryCodingIssues