We, as humans, are a strange species. We buy scented toilet paper. We tour places with tall buildings, climb these building only to put money into telescopes so that we can see the ground close up. We report power outages over television broadcasts hoping to reach that one person running a generator out of his garage so that he can scramble and notify the rest of the neighborhood. We impose death penalties for murderers to teach that killing is wrong. Then during the lethal injection we sterilize the needle and swab the area with alcohol to prevent germs from spreading. We sometimes invent things or come up with ideas only for the sake of creativity. For example, there are braille dots on the keypads of drive up ATM machines. Then there’s that torch setting on the toaster which will transmogrify a slice of bread, no matter how thick, into dust as the timer expires. (Who thought that was a novel feature?) Today I got to thinking about what motivates us to do some of the things we do. More specifically, what motivates us to approach problems a certain way?
Here at Can’t see nothing but the source code the focus is on software engineering. Writing software is all about converting people’s thoughts and ideas into a barrage of ones and zeros so some electronic device can execute them. Most engineers obsess over the details of:
- Their favorite… *cough* Groovy… *cough cough*… programming language
- Their favorite intellij I mean intelligent IDE
- Their favorite platform
- Their deep understanding of some algorithm
There are, no doubt, other things they obsess over but these are by far the most popular. In fact, you can’t be a qualified engineer unless you have a touch of Aspergers syndrome and/or are obsessed over something that normally people take for granite. So is it a wonder why software engineers have such a hard time with product management? Is it a surprise that any time you get any two half way decent software guys in a room they will argue over something as time-wasting as an Integer vs. a short? The more qualified the engineers the longer the argument ensues. You want that kind of argument. You may not want it to go on forever but you do need to entertain some of these dumb discussions. It’s healthy for the project and while it feels like it makes your deadlines slip it’s healthy for project management. If you don’t entertain two tech guys entertaining themselves over why SWT is way more betterish than Swing then you’ll end up with competition and divergent ideas. It’s important to encourage these debates but not let them run on mindlessly.
We’ve all run into our share of horror code. Y’know the complicated backward counting loop that always skips the second to last index, or the complex multi-line boolean expression that when simplified turns out to be a constant if true=false. No matter how often you see this stuff isn’t your first reaction, “why in [insert explitive expression referring to bowel movement, sexual encounter or home of brimstone] would some bonehead do it that way?” If you expound on the motivation you will most certainly find a developer under the gun to figure out a problem for which there was no proper decomposition when the code was originally written. The lack of decomposition comes from the author’s (not necessarily the guy that wrote the hack) obsession over a deep understanding of some particular domain problem. It goes like this. The product owner says, “we need a quarterly break out of our gross profit margin and these reports only give year end totals.” The original developer says or thinks, “Oh, I’ve tackled cross tab queries at my last job and I came up with the Oracle flavored secret sauce to make them perform like lightning. Alls yuh haff tuh do is…” then the code is written. Days later when the original author is in Florida on his second honey moon and junior developer Sam, who happened to be filling the coffee pot the same day Mr. Guru went off on his cross tab rant, is assigned to go fix the off by .001% bug you end up with the bone headed hack we described above.
You ever start a new job and hit a wall when someone says, “we have a strict policy and we absolutely don’t do X” and X is something absolutely critical to software development, like “do regression testing”, “use and IDE”, “compile our code”, or “use the internet”? Many times the issue lies in nomenclature. The company actually does “thing X” but does it in such a round about way that they have completely renamed and reinvented it’s intention. I worked at a company on a Java project where the nightly build was a series of make files that recursed through folders compiling folder by folder and took hours to complete. I also worked at another job where the build and release process could not be automated because the possibility of error so it made sense to have a person run each step so that it could be confirmed and validated without issue. (Translation, management needed someone to blame/harass/terminate instead of some process.) I’ve worked with people who swore every possible piece of functionality could be implemented or belonged in a DBMS table. I’ve also worked with people who thought reading books on programming was an optional practice and completely unnecessary barring you had enough experience dealing with real rather than text book issues. In all I’ve seen my share of craziness.
Nothing tops this
In all my years of software development I’ve never seen anything difficult to understand than this one guy. He deployed a special servlet to a production box that would accept hot deployments of a product that was being developed internally. He didn’t write the servlet but for some reason he was so obsessed with the thought of being the servlet’s to bypass certain security restrictions that had been plaguing him since the beginning, that it became sensible to try out this functionality on the release day of the product. Now considering all normalcy of common sense one would typically refrain from a such an idea as it:
- involves production hardware
- is the release day of a highly visible product
- had not been ok’ed by management
- involved practices that were frowned on in the company
But this guy’s motivation was outside the realms of common sense. Motivation for stoopidity comes, in the tech field, from obsession. Whether it’s obsession over how much heat your thermal component can emit, obsession to make money or obsession over a development philosophy it’s always rooted in obsession. Some people obsess over sandwiches, while others obsess over anything from bunnies, to marbles, to motorcycles. In many ways it can be a good thing mostly when controlled. Seeing these obsessions as the root of all stoopidity takes talent, and insight.
Have you been there? Have you been the victim or the catalyst of some form of motivation? Have you or a loved one been hurt by someone else’s motivation? Speak on it people….