Ubergeek is a strange and wonderful creature. He possesses supernatural powers for retaining vast swathes of detail in his head at one time. This makes him designed for coding, a priceless gem when you need to get version 1 of a new project out the door ASAP. He is the 10x productivity guy of programming lore.
However this uncanny ability to surf a vast sea of detail has a cost – Ubergeek has no need (or ability?) to construct the islands of abstraction that the more pedestrian human brain requires in order to navigate the otherwise featureless terrain. And when neither he nor others understand this fundamental difference, Ubergeek can be lethal to your project.
Some say Ubergeek can be spotted for his taste in clever, quirky/British movies such Memento, Brazil, or Monty Python, though this stereotype is probably apocryphal. For a more reliable diagnosis, watch what happens when you distribute a complex spreadsheet; Ubergeek is the one ignoring your carefully crafted summary charts, and directly processing the rows and columns of numbers. Pretty pictures just hide an arbitrary subset of the truth, and as such serve no purpose for our master of detail. This is not a problem in the case where a regular geek produces the data for other regular geeks – no skin off your nose that Ubergeek ignores your summaries. It is however a problem when Ubergeek is the author of the raw data, and everyone else needs the abstraction that he will not be able to provide.
Of course Ubergeek doesn’t waste time making recreational spreadsheets. He goes for the hard drugs, the most complex engineering artefact we construct – the monolithic code-base.
As already mentioned, Ubergeek is perfect for creating the first version of a new code-base. While it is relatively small, there is less need for abstractions above the implementation level, even if there were regular geeks in need of such abstraction, which there may not be if you’re letting Ubergeek at it on a solo run, perhaps with just a couple of awe-struck underlings to do the bits that bore Ubergeek. Also, it is generally regarded as a good thing to let the higher-level structures emerge from the early, detailed implementation, rather than trying to be prescriptive before the natural structures are understood. So far, as long as your fledgling concept is sound, everything is set up to maximize success.
The waters start to get choppy when your project moves beyond Version 1. As the critical first step, v1 is so important that it is easy to forget that it is upon v2+ that your product idea or fledgling company floats or sinks. And simply continuing to develop v2 in the same way as you did v1 is not usually an option. As the code face grows, you have no choice but to add more engineers to the mix. Plus there is a distinct danger that, with the novelty diminishing, Ubergeek will grow restless, and you do not want this guy getting bored on your baby!
As you start beefing up your development team and processes, you will notice tension brewing between Ubergeek and the new team members. The new guys want to understand the big picture, but Ubergeek doesn’t do big pictures – he needs specific questions which he answers in terms of specific functions, classes and interfaces. He gets frustrated that the purity of his code keeps getting soiled, and the new guys are nervous about making changes that might incur his wrath.
Schedule pressure from above helps the team work through this awkwardness at first, and the code starts to change and grow rapidly. As changes are made by regular geeks, in the absence of a clearly understood architecture, the code drifts from Ubergeek’s implementation-level designs, inevitably becoming more and more complicated, until it is more than can fit in even his head. Now nobody understands the code-base. Now the vicious circle has started – complexity reduces comprehension, which increases complexity – with the expected impact on schedules, quality, and morale. “Fix the architecture!!” say the regular geeks; “F*ch the architecture, fix the code!!” retorts Ubergeek.
Management usually side with Ubergeek. Apart from the fact that he has been on the project since the start, and management know that he is exceptionally smart, they have a natural abhorrence to any talk of taking longer over the next iteration in order to make the next 10 iterations shorter – such advocates are seen as naïve idealists, more interested in the “art” of software engineering than the software business itself.
So what is the outcome of this situation. Most often the project continues on with nobody happy. The “idealists” become despondent and resigned to the fact that the best they can do is to keep out of trouble and take home a salary. New recruits try valiantly for months to make sense of the codebase, but eventually go the way of the idealists. Ubergeek becomes a hacker, mopping up the code-base where he can, insomuch as he still has some understanding of how it “should” work. He probably gets tired of the raging and the fighting after a while, and moves onto the next new project, where he happily restores his faith in his own infallibility. The original project has become an average PITA project to work on, with below average quality and productivity characteristics.
If I had the choice, I would go for a solid engineer and a couple of eager disciples for my new project, rather than an omnipotent Ubergeek-management coalition, every time. We may take longer to get to v1, but the real goal of a successful product and viable code-base is a possibility. Plus, who has time for all that drama?!
The best of all worlds is an enlightened Ubergeek/Engineer/management team, where everybody plays the role they’re designed for – now that would be truly invincible…
Leave a Reply