In the past I’ve posted on some of the differences between the hacker school of coding and the non-hacker school of coding. I recently encountered another anecdote along the lines of this thread.
The Hacker needs to provide users with a way to switch between multiple identical windows in a form. It’d be nice to minimize use of vertical space since monitors tend to have less of it available and this application is image oriented.
Sounds like a job for a ToolBar/ToolStrip right? It’s got all sorts of built in functionality for adding and removing buttons, responding to user events, customizing the appearance, OS theme support, designer support, etc… It’ll even support runtime repositioning in case there are users out there that prefer to dock it against a different edge of the form.
Given such an easy way to provide the required functionality (and then some) why doesn’t the Hacker use it?
- He doesn’t know that it exists. One thing I’ve noticed is that coders from the Hacker school tend to have average to below-average recall.
- He thinks he can write a better ToolBar. Part of being a Hacker is not having a good grasp of the big picture. So his analysis of better tends to ignore things like designer support, accessibility, OS themes, System Preferences, System Events, Display Resolution, etc…
- It didn’t occur to him to use a built-in widget. Hackers don’t think this way. Oftentimes they were trained in an era where there weren’t very many built-in widgets. Being Hackers they wouldn’t have used them even if they were available.
Each of these in some respects arises from the natural desire and concomitant tendency to “subvert the system” that is a hallmark of most Hackers.
Why does this matter?
By writing his own toolbar the Hacker has just raised the technical debt both for himself and for any other team members that have to work with what he has built.
One effect of technical debt is malfunction. Situations where the Hacker’s homemade toolbar are likely to break: multiple monitors, large DPI fonts, different version of the Common Controls library, OS upgrades. The homemade toolbar no longer functions as intended and/or no longer matches the native environment. This debt costs time and money to track down and repair. Often the Hacker is long gone or, if he’s still there, has completely forgotten the mechanics of his homemade toolbar.
Another effect of technical debt is interface mismatch. Put another way, Hackers tend to produce software that doesn’t interface with other software well. So not only does the Hacker make it harder for the team to do its job, he makes it harder for the company to take advantage of the work of others.
In any complex project there are going to be many instances where design decisions need to be made. Some of these will be obvious, some less-so. These will often provide a moment at which technical debt can be increased or avoided entirely. Hackers, because of the reasons outlined in this and earlier posts, will almost always tend to choose the path that increases technical debt.
Do your system and your company a favor; protect it from Hackers.