What If Results Mattered In Software?

I used to be in an industry where results mattered, but that was only because the customer already knew what he wanted. This was 20 years ago, and I built physical things-  software was just something I wrote to support the real work.

Defining Terms: "Results Matter"  in this usage means that I am expected to perform against a clearly defined and understood performance benchmark. Type "abc" tile costs $4 a foot to get installed, that kind of thing.

Since I moved to building software instead of physical things, I've been in this world where where results only matter in the theoretical sense. Why do I say that ? Because to be truthful, the customer has never seen what they want, otherwise why would they ask me to create it ? This has many benefits, primarily financial and pleasure, I get to be very creative.

But here is where it sucks. Let me draw an intentionally over simplified results oriented graph.

Let's pretend that this is a real project, and we know what can happen in real life, lets imagine that it does.

• Wouldn't scale, we chose wrong technology or approach
• Didn't really get clear requirements from customer
• Wanted to investigate newer technologies
• Didn't know how to program in the technologies we were given
• Customer didn't like look and feel
• etc

So in the real world, our project must always look more like this:

The graph is still over-simplified but we are illustrating that it costs twice as much to develop and support because of some problem such as bad technology or wouldn't scale or something. There are thousands of books and articles already on this giant array of problems that might need fixing, let's just say one or more happened so it took twice as long.

So now we have this new approach that makes some prescription we can fix the problem. Once again, there are thousands of articles and books on all these fixes, so let's just say we chose one called "Design Better and Test First and Use Magic Framework". Yada yada, after the thousandth one the details seem to meld together.

This is the results that the article or book promised, for this new approach. Very promising !

So what could be wrong with this picture ?

I've only been in this field since 1980, so my experience may not be representative, but this "Tail Wags Dog" thing always seems to take over.

My very first complaint is that no-one ever measures results. Because if we had more graphics like the ones on this page I believe we would have more pages that have to be printed on yard or meter wide paper. I have seen project after project year after year, no decade after decade spin madly out of control, and no one ever seems to care, "that's just the way we do things here".

But more often than not, there really seems to be no rules or metrics in most shops, "we are all professionals here" is kind of a code phrase for "whatever you say dude, if it takes 22 weeks then so gosh that has to be OK I guess."

Or there is the flip side where the manager is a butt and treats everyone badly, but that is just another way to get bad results.

Myself, I would like to see a set of rules. Maybe it would go like this.

if

    we don't start out with a best case picture of the schedule

then

    we won't know what to gauge expectations against

The obvious hint here is to use VB as the standard. If it can be built as fast as a VB app then you meet your benchmark. Nevermind that it won't scale.

So we have to introduce another rule

if

    the technology prescribed won't scale to meet 3x projected usage

then

    find another technology

But now we have another problem, that of choosing between a zillion frameworks

if

    you haven't researched a zillion frameworks

then

    keep researching

Woops, there seems to be a resource problem here. Zillion times something = a lot. Better restrict our search to stuff we have narrowed down

if

    our architect recommends it

then

    we can research it further

This is where some prayer might be helpful. Just pray that he reads the right journals, we're in trouble if he likes EJB or any other technology that might be overkill.

if

    we have a limited amount of time to learn technologies

then

    learn something you can use for everything

woops, that could easily keep us in whitepaper land or using technologies like EJBs for simple unsecured departmental apps with no security requirements. I seem to see a problem here. Overkill overkill overkill.

if

    we choose multiple technologies for muliple types of apps

then

    we are spending more time learning technologies than working

Darn. Now we got another problem. How about if we use something like Spring, that way the technology is all the same but we are only escalating our learning time when we need to add in a spefic feature ?

if

    we use a flexible lightweight system

then

    we add skills and technologies only as needed

    we only learn one "set" of skill sets.

OK I'm tired of iterating through all these rules.

But it's easy to see see we have barely scratched the surface, and we're already 20 times farther than most analysis gets. Plus the fact that we don't yet have an object model to support our statements, nor a way to really punch in data to run through our object model

Sounded great anyway.