The Motivation Why We Do Things Part I

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:

  1. Their favorite… *cough* Groovy… *cough cough*… programming language
  2. Their favorite intellij I mean intelligent IDE
  3. Their favorite platform
  4. 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:

  1. involves production hardware
  2. is the release day of a highly visible product
  3. had not been ok’ed by management
  4. 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….

4 thoughts on “The Motivation Why We Do Things Part I

  1. I need help with my new printer and scanner how do you stop prininting abbruptly when they tell you you are going to run out of ink just as your printer has printed off 30 pages of a 80 page text . When you stop it and pause the print job your printer seems to stop forever where it might have enough ink left for a 3 page document it won’t print that . What causes softwear to act up like this.

  2. The printer software is client/server. You have the client that runs on your PC and the server (firmware) that runs on the printer. Most people view this as a single piece of super-software that transcends the physical boundaries between PC and printer. In reality it’s two pieces of software that may not have been developed by the same team. So when you pause the job what happens is the client sends a command to the server and it’s up to the server to determine how (and if) to respond. I’ve seen times when hitting pause on a 30 page printout still allows the next 10 pages to printout. It’s always better to stop the job at the printer as well that way if it does something goofy you know it’s the printer acting goofy and not the software. The ink monitor is another client server example. Now I don’t know the low level details of ink monitoring but I can tell that on my Brother 420-CN the actual ink level is somehow detected whereas with my older Epson (can’t remember the model) the level was guessed based on usage. On the Epson I could reinstall an empty cartridge and trick the printer to print. (That cheapskate trick won’t work on my Brother printer.) So some software engineer probably decided to make a guess from the client based on actual usage and estimated ink per document to signal ink is out even when there is physical ink remaining in the cartridge.

  3. The point? The point is that there is no point. It’s an open exploration into the motivation why we do dumb things, especially in software development. Things like why is there a condition check on a boolean variable that is immediately hardcoded to true in the preceding line? Why did we call into a templating framework from another templating framework just to set a template attribute? I dunno, maybe something did get lost in this post…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s