Traffic was rather heavy as I was driving home from work today. At some point, I noticed the lane to my right was clear, whereas a few feet ahead my lane was jammed. I started changing lanes, but then the car ahead of me (which was fully stopped) attempted to do the same. As I had more room, I stepped a bit firmer on the gas, hoping the other car noticed and let me pass to its right. It worked.
As I pulled away from the jam, I pondered my rather trivial feat. Unconsciously, I had performed a flawed risk/reward analysis: for the perceived benefit of pulling into my driveway a few seconds earlier, I had risked entering a car crash — even a fender bender is annoying enough as to deny any real or perceived time benefits.
Obvious, right? Yet we do it all the time with much more critical things. I’m not talking about flawed probability percentages or delusional rewards — though those are serious problems in their own right; I’m talking about risks and rewards that are not really exchangeable in terms of units or dimensions. Thus, for the prospect of a won argument, we risk a long-term relationship. For the reward of making it to production a couple days earlier, we risk data integrity, customer satisfaction and architectural quality. For the sake of familiarity and transferred responsibility, we enter unacceptable risk as we plan and execute projects using known-flawed waterfall methodologies, with vendors that should know better.
There doesn’t seem to be much written about this, and it makes a lot of sense: risk-reward analysis originates in the financial industry, where the one ruthless unit for all measures is money. We are supposed to do that as well (make a business case or somehow else monetize much of our IT project decisions), but all too often we lack method, discipline, or both — and yet we plow ahead based on questionable proxies for actual business risk and value.
Next time I carry out a risk-reward analysis, I’ll try to make sure that both ends are measured in the same units. I hope you do too!
Over the years, I’ve had the privilege of being part of a few teams: development teams, architecture teams, management teams. I’ve also been privileged to manage a few teams of my own. In my experience, I’ve seen that staff meetings tend to fall within two distinct styles or “colors”, and of course there’s room for many intermediate shades as well. In this post, I outline the styles and make the case for my favorite meeting color.
For the past couple of weeks, owing to a mishap, I’m temporarily switching from my Nexus 4 to a loaned Lumia 520. I’m no stranger to Windows Phone, and I’m not really missing any apps. I do miss the tight-knit Google ecosystem, though, and that got me thinking about the implications the concept of mobile ecosystem has for the enterprise market. Read on for my thoughts on this.
Like such things are prone to do, the media storm surrounding Flappy Bird has subsided. For weeks, the game’s sudden rise to fame and perplexing demise by its creator, independent Vietnamese game developer Dong Nguyen, brought about many theories and thoughts. Although the matter has seemingly been settled, the loud chorus claiming that @dongatory was incapable to cope with success brought to my mind a question we seldom ask of our own projects, one which carries deep implications: are we ready for wild success?
Summer is in full blow in the northern hemisphere, and, I think, particularly so in the Caribbean. Family commitments involving plenty of food and the beach, among less glamorous stuff, have kept me silent over here for almost two months now. This is just a short note to let you all know that I’ve been awarded a research grant from INTEC to work on architecture description languages (ADLs) as tools to assist high-level electronics design. Read on for some details.
Three months ago, I was teaching a class on Fundamentals of Software Engineering. This course has a module on Software Architecture, which I typically teach from the Carnegie Mellon SEI perspective. After teaching it a few times, I had been thinking about better ways to transition students from the “computer-science-first”, code-driven perspective they have when they get to this course, to the more abstract level of thought desirable to properly grasp and reason about software architecture in a structured fashion. Read on to find out how I reached out to another engineering discipline to achieve this.
Last week was marked by two interesting announcements concerning instant messaging (IM). First, BlackBerry announced that its signature Messenger app is gaining a Channels functionality that comes across as a Facebook/Twitter mash-up, and that it’s coming to Android and iOS this summer. Later, Google announced their revamped Hangouts strategy to unify and enrich IM across its different platforms and offerings. In this post, I explore some of the commonalities between both strategies, as well as single out my perceptions about the main drivers behind these changes at both companies.