Decision Points in Programming

I have a sort of personality quirk that causes me to constantly play what I describe to others as the “what-if game.” This is where I have some kind of oddball thought about altering something that we take for granted and imagining how it plays out. Lest you think that I’m engaging in fatuous self-aggrandizing, I’m not talking about some kind of fleeting stoner thought like “what if I had like eight million Doritos and also X-ray vision?!?” I mean that I actually really start to think strange things through in detail.

For example, not too long ago I was in an elevator and thought to myself, “would I ride this elevator if I knew that there was a 1 in 10,000 chance that the elevator would plummet to the bottom of the elevator shaft?” I thought that I would. I was going up a ways and the odds were in my favor. I then thought to myself that this was a rational choice but viscerally insane — why take the chance?

This led to the thought “what if elevators around the world just suddenly had those odds of that outcome for some reason, and it was intrinsic to the nature of elevators?” Meaning, nothing we could do would possibly fix it. Elevators are now synonymous with 1 in 10,000 plummets. How does the world react?

It’s a wild thing to think about, but the predictive possibilities and analysis are endless. First of all, we’ve got all of these tall buildings, so it’s not as though we’d just leave everything in them and become brownstone dwellers. Some brave souls would go up to get things from these buildings and keep playing the odds. The property value of high-rises would immediately plummet, and you’d probably invert the real-estate structure nearly overnight with suburban/country home prices skyrocketing and swanky downtown high-rises becoming where extremely poor people and drug addicts lived (who else would routinely brave the odds?) I think the buildings would still stand because of the sheer amount of elevation required to knock them down and the fact that we actually develop quite a tolerance for risky things (like driving to work every day).

There’d also be odd anthropological effects. I’d imagine that a whole generation of teenage thrill seekers and death defiers would start doing elevator joy rides to prove their mettle. People would develop all kinds of cargo cult ways to stand or sit in the elevators with a mind toward simply surviving the plummets. In fact, perhaps humankind would just become really good at making the plummets survivable. Politically, I’d imagine that a huge wedge issue debate would emerge about freedom to ride elevators versus the sanctity of life or something. I could go on forever about this, but I’ll have mercy and stop now.

The point is that I take these mental trips several times per day, considering a whole variety of topics. Most of the thoughts that emerge are bizarre and beneficial only as exercises in creativity, like the elevator example, but some are genuine ideas for reboots in thinking about our craft. I find the exercise of indulging these mental divergences and quasi-daydreams to be a good way to get the subconscious brain working on perhaps more immediate problems.

So if you’re up for it, I invite you to have a go at this sort of thinking, but perhaps in a more structured sense. At times in the history of programming, decisions were made or ideas proposed that wound up having a profound effect on the industry. Imagine a world where these had gone differently:

1. Tony Hoare introduced what we later called “the billion dollar mistake” — he implemented the concept of 0 as a null reference. But what if there were no null?
2. A lot of what we do to this day as programmers has its roots in decisions made for the typewriter: for example, the QWERTY keyboard and using CR/LF for end of line. What if these conventions had been different when the computer started to take off?
3. Edsger Dijkstra famously swung the tide against the use of GOTO as a programming language construct with a seminal paper. What if it had popularly stuck around to this day and GOTO statements were still something we thought about a lot?
4. Of the three programming paradigms (structured, object-oriented, and functional), functional is the oldest, but it lied dormant for 40 years or so before gaining serious popularity today. What would the world look like if it had been the most popular from the get-go and stayed that way?
5. C++ really took OOP mainstream, but it did it in a language that was effectively a superset of C, a non OOP language. This allowed for the continuation of a very procedural style of programming in an OOP language. What if that cut had just been made cleanly?
6. What if the most popular object oriented languages didn’t have the concept of “static” and everything had to belong to an instance?
7. What if Javascript had been carefully planned in an enterprise-y way, instead of thrown together in 10 days?
8. If disk space had been as cheap as it was and the need for stored information rather than calculation had been higher, would the RDBMs as we know it ever have become popular?

Thinking through these things might just be a random exercise in imagination. But, who knows, it may give you an oblique solution to a problem you’ve been mulling over or a different philosophical approach to some aspect of programming. Things that we do, even highly conventional or traditional ones, are always fair game for reevaluation.

Years of Lessons Learned from Home Automation

I’ve had three variations of my home automation setup. The first incarnation was a series of Linux command line utilities and cron jobs. There was some vague intention of a GUI, but that never really materialized. The second was a very enterprise-y J2EE implementation that involved Spring, MongoDB, layered architecture, and general wrangling with java. The current and most recent reboot involves nodes in a nod to Service Oriented Architecture and the “Internet of Things.” As I mentioned in my last post, the I’m turning a Raspberry Pi into a home automation controlling REST endpoint and then letting access and interaction happen in more distributed, ad-hoc fashion.

The flow of these applications seems to reflect the trajectory of my career from entry level developer to architect — from novice and hobbyist to experienced professional and, well, still hobbyist. And I think that, to an extent, they also reflect the times and trends in technology. It’s interesting to reflect on it.

When I started out as a programmer in the working world, I was doing a lot in the Linux world with C and C++. In that world, there was no cred to writing any kind of GUI — it was all about being close to the metal, and making things work behind the scenes. GUIs were for the faint of heart. I wrote drivers and kernel space code and automated various interactions between hardware and software. This mentality was carried over into the world of hobby when I discovered home automation. X10 was the province of hobbyist electrical engineers who wrote code out of necessity, and I fell in nicely with this approach. It was all about banging away, hacking, and making things work. Architecture, planning, testing, deployment strategies, etc… who cares? Making it work was all that mattered. I was a beginner.

As my career wound on, I started doing more and different kinds of programming. I found my way into web development with Java, did things in the .NET space, worked with databases, and started to become interested in architecture, software processes and honing my craft. With my newfound knowledge of a breadth of technologies and better software development approaches, I decided on a home automation reboot. I chose Linux and Java to keep the budget as shoe-string as possible. For a server, I could use the machine I took with me to college — a 400 MHz P2 processor and 384 meg of RAM. The hardware, OS, and software were thus all free, and all I had to do was pop for the X10 modules at $10-$20 a piece. Not too shabby.

I was cost conscious, and I had a technical vision for the architecture. I knew that if I created a web application on the server that what I did would be accessible from anywhere: Windows computers, Linux computers, even cell phones (which were a lot more limited as nodes in a network 5-6 years ago when I started laying this out). Java was a good choice because it gave me a framework to integrate all of the different functionality that I could imagine. And I imagined plenty of it.

There was no shortage of gold plating. Part of this was because I was interested in learning new technologies as long as I was doing hobby work and part of this was because I hadn’t yet learned the value of limiting myself to the minimum set of features needed to get going. I had advanced technically enough to see the value in architecture and having a plan for how I’d handle future added features, but I hadn’t advanced enough to keep the system flexible without putting more in up front than I needed. A web page with a link for turning a lamp on may not need data access, domain, service, and presentation layers. And, while I had grand plans to integrate things like home inventory management, recipe tracking, a family calendar and more, those never actually materialized due to how busy I tend to be. But I was practicing my craft and teaching myself these concepts by exploring them, so I don’t look back ruefully. Lesson learned.

Now, I’m rebooting. My old P2 machine is dying slowly but surely, and I recently purchased a lake house where I want to replicate my setup. I don’t have another ancient machine, and it’s time to get more repeatable anyway. A minimal REST endpoint on a Raspberry Pi is cheap and repeatable, and it lets me build the system in my house(s) more incrementally and flexibly. If I want to use WPF to build a desktop app for controlling the thing, then great. If I want to use PHP or Java on a server, then also great. ASP MVC, whatever. Anything that can speak REST will work, and everything speaks REST.

Maybe in another three years, I’ll do the fourth reboot and think of how silly I was “back then” in 2013. But for now, I’ll take the lessons that I’ve learned in my reboots and reflect. I’ve learned that software is about solving problems for people, not just for the sake of solving the problem. A cron job that I can tweak turns my lights on and off, but it doesn’t present any way that the system isn’t weird and confusing for my non-technical girlfriend. I’ve learned that building more than what you need right now is a guarantee that you’ll have more complexity than you need and less benefit. I’ve learned that a system composed of isolated, modular components is better than a monolithic juggernaut that can handle everything. And, most importantly, I’ve learned that you’ve never really got it all figured out; whatever grand plan you have right now is going to need constant care and refinement.

The Hidden Cost of Micromanagement

I think everyone has encountered the micromanaging type at some point or another in their career. Most obviously or memorably, this might have been a boss who took the attitude, “no decision too small!” But it might also have been a coworker’s boss or just someone else at the company you had the misfortune to share an office with. If you’ve managed to avoid this your whole career, count yourself fortunate, but understand that there is a type of person out there that feels as though he is the only one capable of making decisions and then acts accordingly.

The up-front cost of this behavior is fairly obvious. It clearly doesn’t scale well, so micromanagers wind up being huge bottlenecks to productivity with all decisions essentially on hold until that person gets to them. Micromanaging also the effect of creating learned helplessness in those around them, rendering everyone else less productive. People learn that there’s no point in trying to have autonomy, so they check out and stop paying attention. Some will even engage in passive aggressive behaviors that harm the organization, such as malicious compliance. “You want me to ship this code as-is, huh? Okie-dokie.” (“Heh, heh, well, it crashes, but hey, you’re the boss!”)

Being subjected to a micromanager is hard to take and often stressful, so turnover is typically high in such scenarios. And that’s where a hidden cost comes in. People working under the purview of a micromanager don’t suddenly and automatically switch gears when their situation improves — they often bring their previous behaviors along for the ride. If you’ve ever seen the movie The Shawshank Redemption, recall the scene with Red in the grocery store when he gets paroled to work after 40 years in prison:

Red: Restroom break?
Boss: You don´t need to ask me every time you need to go take a piss. Just go.
Red (thinking to himself): Forty years I´ve been asking permission to piss. I can´t squeeze a drop without say-so.

Red’s boss and the grocery store are experiencing what I’m describing as the hidden cost of micromanagement. He has an employee so used to having his day micromanaged that the employee is maddeningly, annoyingly dependent. In your own travels, it’s easy to tell the signs of a previous victim of micromanagement: endless updates about details and inconsequential minutiae, constantly asking permission to do anything, non-stop preemptive apologies and general insecurity about work quality. That all might seem harmless, if a little sad, but the problem is that this lack of autonomy and willingness to take charge of situations has a real productivity hit for both parties. The new manager/lead should be focusing on bigger picture issues, such as removing impediments from the path of her team — she shouldn’t have to worry about whether one of her team members’ Outlook inbox is 80% full. That’s a meaningless detail that nobody should report to anyone, and yet tons and tons of micromanagement victims do.

It goes without saying that you should avoid micromanagement. It’s a terrible interaction and leadership strategy on its face that is largely the purview of people with psychological problems. But look for past victims of micromanagement and given them a hand or a leg up. Encourage them. Work with them. And most of all, let them know that they’re capable of making good decisions and worthy of being trusted to do so. Your organization will be much better off for it.