Pity the Wizard

Might and Magic 2
Note that this is the Apple IIgs version. #hardcore

At times, I’ve felt the temptation to equate the development and growth of a team to that of a party in a Role Playing Game. But, while the RPG analogy does have some striking resemblances to real life, it is better for telling us about pitfalls than about actual good practices. They are both similar in that you start out a Role Playing Game with little knowledge of your task, and build a party based on intuition. As the game progresses, you realize that your party design is not exactly aligned to the tasks that you are confronted with. Continue reading “Pity the Wizard”

Risk, the Developer, and Patton

Every developer has been confronted with the request, ‘Take your best guess,’ in working their way through a problem. Now, this puts an engineer in a very hard position. Many teams are conflicted when it comes to taking chances: you can take any chance you want, as long as you only pick the right solution. That makes it very hard to put a developer in that position, since it’s not really a guess if the only allowed outcome is 100% success. Continue reading “Risk, the Developer, and Patton”

Four Quadrants

A while ago I was in my car, listening to the radio, and the Beatles came on. I’ve never really been into them, but I have respect for them and their influence on music. I started to think about my likes and dislikes in four quadrants as sort of a silly thought experiment:

Four Quadrants
Four Quadrants

On the Y axis is my level of respect for something, and on the X is how much I like something. Continue reading “Four Quadrants”

Possible But Not Practical

I recently was working on a project and got in one of those discussions where I was not communicating at all. I was trying simultaneously arguing that the software was something I could build, but one that would not work. I felt pretty confident in my abilities to build and deliver it, and, in fact, that it would be pretty cool once built.

However, I was also trying to indicate that because of its complexity, it would have the characteristics of an unstable nuclear isotope – it would not last long. The system in question wold require so much more human intervention to keep it correct than was available within the organization that every month of operation would put it further and further out of true. It was ‘Possible, but not Practical’. Continue reading “Possible But Not Practical”

Good Metaphors

When I started a job a few years ago, I was assigned to a project on a Marine Base. There was one member currently on the team as it was undergoing  staffing transition, and he had perhaps the best and most memorable welcome I have ever received, which was a great example of good metaphors in IT.

He said something along the lines of: “We have only one rule here, and it was said best by the Rock: Know your role and shut your mouth.” Continue reading “Good Metaphors”

Bad Metaphors

Several years ago, I left a dinner table of colleagues wishing a question had gone unasked. We were having dinner before a big release which included a major migration for a business unit, and a product manager said something like ‘This is like the night before the big game to you guys, right?”

I sat upright, and launched into, what was, to me, an impassioned motivational speech about comparing a multi-year software project’s final deployment to a game where the likelihood of success stood around 50%. I think it’s very important to keep in mind that modern engineering requires at least a 90% delivery probability, if not 100%. Sports is a competition whose mechanics can be good metaphor, but whose outcomes probably can’t. Continue reading “Bad Metaphors”