Bulldozer00's Blog

“Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.” – George S. Patton

One of my pet peeves is when a bozo manager dictates the how, but has no clue of the what – which he/she is supposed to define:

“Here’s how you’re gonna create the what (whatever the what ends up being): You will coordinate Fagan inspections of your code, write code using Test First Design, comply with the corpo coding standards, use the corpo UML tool, run the code through a static analyzer, write design and implementation documents using the corpo templates, yada-yada-yada. I don’t know or care what the software is supposed to do, what type of software it is, or how big it will end up being, but you shall do all these things by this XXX date because, uh, because uh, be-be-because that’s the way we always do it. We’re not burger king, so you can’t have it your way.”

Focusing on the means regardless of what the ends are envisioned to be is like setting a million monkeys up with typewriters and hoping they will produce a Shakespear-ian masterpiece. It’s a failure of leadership. On the other hand, allowing the ends to be pursued without some constraints on the means can lead to unethical behavior. In both cases, means-first or ends-first, a crappy outcome may result.

On the projects where I was lucky to be anointed the software lead in spite of not measuring up to the standard cookie cutter corpo leadership profile, I leaned heavily toward the ends-first strategy, but I tried to loosely constrain the means so as not to suffocate my team: “eliminate all compiler warnings, code against the IDD, be consistent with your coding style, do some kind of demonstrable unit and integration testing and take notes on how you did it.”