lex parsimoniae

Selling Architecture, Redux

Architecture is a tough sell.  It rarely is linked directly to the delivery of a feature, much less is a feature.  And without that tie-in, business leaders won’t approve the time and expense to build or improve your architecture. Of course, as software professionals, we understand why architecture is important.  You can build almost any [...]

Do you know cause from effect?

I fixed a bug today – a bug that was introduced because a chunk of code was depending on side effects of another piece of code to work properly.  Depending on whether you’re ever worked directly with a computer language, this may be a subtle transgression, but the problem is distinct and real, and here’s the best part — if you learn why this is a problem, you’ll understand where this flawed thinking bites you in everyday business decisions, too.

So let’s back up and look at a non-programming example. Let’s say you go in to see you doctor because you’re feeling under the weather. The doctor runs some tests and sees that your white blood cell count is higher than expected. A good doctor would know very well that there are lots of reasons this can happen, but someone a little less disciplined who’s sitting at home playing “House, the Home Game” might shout out, “it’s cancer!” before really having any evidence to support their crackpot theory.

Process isn’t for “relaxed” projects

I’ve been working through some interesting process issues with my employer’s CTO and head of Product Management. The thrust of these discussions is that we’ve revised our Product Planning and Product Development processes, and I’m currently working on documenting what we’ve agreed upon. No sooner had we come up with a plan, however, than a “highly important” project sprung up, prompting discussions about suspending parts of our process because this project was so important. I’ve managed to stop my head from spinning long enough to gather some thoughts…. (read on for more)