Dave Donaldson for President! ;)

This is something I struggle with at work. It's frustrating when colleagues doesn't understand "the why," and even more so when you sense that they don't really care to. It's even more fun when you ask why something was done a certain way and are told "I saw it was done that way in XYZ component, so I copied that code here."

Ever since reading Steve McConnell's Cargo Cult Software Engineering, this is an issue that really resonates with me. You can wave sticks around all you like, but if there aren't any planes on the way, then you're just getting exercise. Not knowing "why" something works (or doesn't) means you're just going through the motions. As McConnell quotes in the article, Einstein said the definition of insanity is doing the same thing over and over again, but expecting different results. Shouldn't take Einstein to see that if you're responsible for building something (anything?), the "why" for the choices you make is more important than "how" they're implemented. Especially with software, where there are usually many ways to accomplish a given task -- if you don't know the "why", then how do you know which method is best?

I'm imagining a conversation with the architect designing my house: Architect: "So then, Jeff, we're going to put a beam here through the middle of this room." Me: "Having a beam there would suck... why do we need it?"  Architect: "Well, that's how it's been in other houses I've designed and that's just how I learned to do it." Me: "Hit the bricks."

Which leads to the "adding value" rant... Dave also mentioned those who just want to get the bare minimum done and go home. If that's your goal, you're not adding value to your organization. These days, "writing code" isn't, by itself, enough to add value. There are people on the other side of the world happy to do that for a fraction of what someone here makes. So how do you add value? My opinion is that you do it by working with everyone in the organization to serve the customer, no matter what it takes. Work with the product people as they figure out what the product should be and how it should evolve. Work with the sales people who know what potential customers are looking for. Work with the support people whose phones ring when the product falls short. Work with the management team to understand the overall business' needs and direction. Be flexible. Be proactive. Be innovative. As cliched as it may sounds, work to see the "big picture".

Anyway, Dave, thanks for a good post. I've subscribed!