In a recent client interview, I was posed some interesting "puzzle" questions.  These weren’t of the "How would you move mount Fuji" variety (By the way, I would never dream of doing such a thing.  Surely some detailed requirements gathering would show that there’s an alternative to moving an actual mountain).  These questions were of the computer science variety, but from 20 years ago.  These were questions such as "How would you detect a circular reference in a linked list using only a couple of pointers?"  Huh?  Linked list?  I mean yeah, I know what a linked list is.  I had to write my own memory allocation and list structure stuff in the past (the distant, academic past), but when’s the last time you had to do something like that, seriously?  Fortunately, there are no hand-rolled linked lists on this project, but it started me thinking.

There will always be developers who want to eke out every possible performance gain they can from a system, but the code they leave behind is often impossible for their successors to understand and maintain.  Even if I can prove that my algorithm for solving a problem is truly superior in its performance, in all likelihood that gain will be completely negated by the time wasted by some future developer shaking his head and trying to work out what I’ve done.

The "correct" solution to the linked list problem, is very clever, uses almost no memory, and works in a nearly O(n) scale, but if even one future developer has to stare at it for a few minutes trying to figure out how it works, then whatever benefits it had have likely been rendered moot.  You know what I’d do?  I’d replace the linked-list with a List<Entity> or a dictionary keyed on some unique property of the entities to eliminate the possibility of duplicates in the first place and move on.  If I couldn’t do that then I might walk that list, adding references to a second List<Entity> as I went, checking for duplicates on the way.  Then, if and only if I determined that this piece of code caused a noticeable bottleneck or delay would I go back and look for a better way.  These days we’re swapping "clever" for "robust" with the help of the .net framework, and I’ve yet to see a system grind to a halt because of a call to List.Contains().  I see systems grind to a halt because of nine layers of "clever" indirection in the UI, and "clever" homegrown data access layers.

Consulting and development isn’t about being smarter than the client, it’s about helping the client succeed, and that never means leaving behind something no-one can understand without detailed analysis or a 1980’s computer science education.