Hello and welcome to Program Five coming to you today from Redmond Washington
I'm on the road this week so I'm using a $20 headset to record this program so it's not my usual studio deal...
So, you say you want a revolution.... you want to have better tools and better applications and you want it for less and you want it yesterday
Well...
If you ask your average corporate executive today, do you believe that you have gained everything you can from using software to improve your competitive advantange, most of them would answer hell no... if only those IT guys could deliver on what they promise.
If you ask your average developer/programmer/engineer today, do you do what you do best and let others do the things you aren't talented at, most of them would answer hell no... if only I could focus on what I do well and let someone else do the "dirty" work.
The fundamental dynamic of softare is that is always promises too much and delivers too little.
And I'm here to tell you why I think that is true and what we can do about it....
It's true because we ask people to do things that are outside their abiliites. You wouldn't ask a dentist to remove a gall bladder and you wouldn't want your internist to fix your cavity. Why? because they're not trained, they don't want to, and their natural talents lie in other areas.
So why do we ask software developers to do it? Because "programming is programming" Right? Wrong, I tell you, wrong!
Some people naturally think like tool builders and some people naturally think like solution builders. While these two capabilities are not mutually exclusive most people tend to be one or the other. A tool builder thinks of all the things someone can do with their tool and a solution builder thinks of all the problems they can solve with the tools. The key difference is that the tool builder must think parametrically (i.e. how can what I'm doing be reused and where are the points of variability) and the solution builder must think constructively (i.e. how can I take these building blocks and make something useful, how do I use the variability to produce a specific instance that solves a problem).
So I assert that the reason that software is often late, always over budget and a high risk proposition is, at least in signficiant part, due to the fact that we have the wrong people doing the wrong things.
So what does it look like to have the right people doing the right things?
It's not a cause and effect situation. It's an iterative spiral. Tools breed solutions which breed feedback on the tools, which breeds better tools, which breed better solutions and so on.
Just like an artist who pays attention to each brush stroke, and can always tell you where they wish they'd had more time, or a chanc e to do it over, a "tool builder" is concerned with a certain class of details, and rightly so. A "tool user", on the other hand, is like the art gallery or patron of said gallery, who appreciates the results in a more abstract, gestalt form. They could (for the most part) care less whether the artist used oils or the "tool builder" used assembly language or C#. What they care about is the end product or the show at the gallery.
The net result of the right people doing the right things is the quintessential, one plus one equals three. You get a multiplying effect in terms of results and a dividing effect in terms of risk.
This is the fundamental premise that is used in many other industries very successfully, so why not software? Indeed why not!
So, as you sit down to write your next chunk of the future, ask yourself, what kind of developer am I and am I doing the kind of development that suits my talents.
