SQLServerCentral Article

Pro Developer : Throwing Money Out the Window


Pro Developer

Throwing Money Out the Window

It's common knowledge among programmers that most of the ills of the software

industry, and most particularly the companies where we work, could be solved by

simply letting the technical people make the technical decisions. In fact, that

sounds so obvious that you might be tempted to shake your head and wonder what

planet I come from. Obviously, since this is so incredibly logical and sensible,

it's a given that most companies leave management decisions to managers, and

technical decisions to techies, right?

Hey, you. Yeah, you. The one in the back staring at your compiler errors.

You're laughing in all the wrong places. At least let me finish, and then we can

all laugh together about how silly an assumption this is. Now, as I was about to

say, anyone who's ever been paid for writing code already knows that regardless

of how sensible it might be to let the people with the expertise make the

decisions, that's just not the way it happens in the real world. In fact, in the

overall scheme of things, when it comes to decision making power, programmers

are at the bottom of the food chain, whether the issue is technical or not.

In short, no matter how silly it may be, most critical technical decisions in

the software development business are made by middle or upper management, a

class of creature who only rarely possesses any in depth technical expertise.

This, in and of itself, wouldn't be so bad. It is, after all, management's area

of expertise to keep the company on track and make the sweeping decisions

requiring someone with a wide angle view of the business. The problem with this

scenario is that an extremely high percentage of the time, these decisions are

made without consulting the technical staff about the feasibility and

consequences of the decision. Worse still, management often makes decisions for

their own reasons over the loud protests of their technical staff, ignoring the

recommendations made by those who have the greatest skills in that arena. It's a

wonder that any software ever ships at all.

Corporate waste

In fact, the combination of project disasters and fickle or crisis driven

management frequently insures that we don't ship software. Talking with an old

friend and fellow programmer a few weeks ago, we tried to put a number to this.

What we came up with was that of all the projects we'd worked on, only 10% of

the code we'd written ever saw the light of day by being released as a product

for use by customers, whether it was shrink wrapped products or internal IT

systems. This means that 90% - yes, you heard me right, 90% - of all the

projects we've worked on died a premature death and never saw implementation in

the field. Sometimes it's a good old fashioned project disaster (I don't think I

need to define that term with this crowd). Other times, it's simply capricious

decision making, constantly changing direction to go with whatever is trendy or

politically expedient. And of course, there's always crisis management, where a

project never gets completed because it's put on hold so that we can be assigned

to putting out a different fire, only to be pulled off that effort for yet


In other words, 9 times out of 10, all of the time, effort, blood, sweat and

tears we put into those systems, not to mention the financial cost incurred, was

for nothing. The code was simply thrown away. Yes, we try to stash away the

clever bits of code we've written to be used later, but the rate that technology

changes usually minimizes the benefits of this. Overall, it's just money out the


Having heard this story over and over again from developers the world over,

it slowly became clear to me over the years that this wasn't an uncommon

scenario. As my mind reeled over the staggering amount of waste that is the norm

in the development industry, one question kept recurring over and over again.

Why? Why would any company willingly throw that kind of money into the

fireplace, shrug it off as business as usual, and then embark on yet another

project that would ultimately suffer the same fate? If you think of a business

as an organization which exists for the purpose of making a profit, your brain

will eventually reboot. It just doesn't make any sense. Or does it?

Remember the human factor

Businesses are run by people, and people all fall prey to the frailties of

human nature. When considering the matter at hand, the people in question are

known as management, and they are no less human than the rest of us, no matter

what speculation you might hear from programmers when hanging out by the

espresso machine. That means that decisions aren't always made for the most

altruistic of reasons. Every person has their own career ambitions, their own

vanities and ego, and their own personal agenda.

Furthermore, they're spending someone else's money, a point not to be taken

lightly. I can assure you, if the money were coming out of their personal bank

accounts, you'd see an entirely different set of priorities. Instead, this money

just isn't real to them. Rather, it's an abstract set of figures on a

spreadsheet simply referred to as "the budget". I'm making a point of this

because if you expect that mentioning the financial consequences of the

decisions is all that will be necessary for the logical mind to see things your

way, you're in for rapid disappointment. This isn't their money, and it's too

difficult for them to translate it to the impact on their personal paycheck.

It's not like they spent the family's savings on a red sports car and have to

explain the decision to their significant other.

This sort of waste and history of project disasters would never happen if the

techies were in charge of the decisions. However, before we get too proud of

ourselves, it's worth pointing out that it would be due to a completely

different motivation than making the company money. Programming is our art and

our passion. We just couldn't bear the thought of pouring all that effort into

our latest masterpiece and then simply tossing it in the waste bin. We're

emotionally attached, and it also goes against every logical bone in our bodies.

There's only one problem. We're not in charge.

We've all had the experience of arguing with our superiors until we're blue

in the face, trying to explain why the technical direction they want to take is

either completely pointless or disaster waiting to happen. If you didn't have

the conversation out loud, you certainly had it in your head. Either way, the

end result is all too often the same. We're either patronized because "we don't

understand the big picture" or we're simply told, effectively, to sit down and

shut up. And so, given that we work for others, in the end it's our job to do

what we're told. Disaster ensues, the project dies or is swept under the rug,

and then here we are in the conference room again, having exactly the same

argument over yet another doomed project. I often get visions of the Flying


What if the programmers were in charge?

The other side of this coin is that had our recommendations been heeded, a

huge amount of this waste would have been averted. Either the disaster would

never have taken place, or time and money wouldn't have been wasted on a project

that was obviously never going to see fruition in the first place. So the real

question is this: how do we convince our superiors to trust us and follow our

lead in the arena we know best?

There is no single silver bullet that will solve this problem. People are

complex creatures, and you can't expect to deal with them successfully without

taking a number of things into consideration. However, I want to touch on

something here that is an important consideration if you truly wish to effect

change in your organization: credibility. It might surprise you to learn that in

the scenarios and conference room skirmishes I've just outlined, we have


What's that you say, how could we possibly have no credibility when we can

list disaster after disaster in our own defense? Simple. Those disasters, all

those failed projects you can list at the drop of a hat? They were all our

fault. Yes, you heard me right. From management's perspective, the reason they

failed was not because the task was illogical or impossible. It failed because

the programmers simply didn't get it done. Where else could the blame possibly

lie? You certainly don't expect management to take the heat, do you? How do you

think they got to be managers in the first place?


So, the next time you speak up questioning the path of the new project, don't

be surprised that your recommendations and concerns are summarily dismissed. You

have a history of failed projects. You have no credibility.

With that in mind, we must learn how to accumulate this rare and valuable

commodity, for programmers are not as helpless as the description I've given

would seem to indicate. At least, they don't have to be. First, let's look at

the benefits that we bring to the party. If programmers ran the farm, the

company would benefit by having better functionality, higher quality, improved

integration, dependable timelines and the completed projects would actually be

used and produce benefits.

By bringing benefit to the company you work for, the project will also make

your management look good, thus improving their chances to get what they

personally want. And even though nobody cares what your personal desires are,

there are at least two people who care about your management's private agenda:

them and you.

This is a critical point to comprehend. Programmers have wasted enough breath

in logical arguments to provide the world with wind generated electricity for

the next century. The reason it's a waste of time is that it's the wrong battle

to fight. The decision makers above you are going to make their choices based on

their own agenda. If you take the time and effort to understand their needs and

then learn how to help them achieve them, you're halfway home. Make sure that

they know you're responsible for helping them attain their desires, and you

become something very powerful in the business world: a person with


A new set of priorities

So, in order to better steer the ship that we would ultimately go down with

should our efforts fail, we need to accomplish two things. First, we need to

build credibility with those who have the power to effect change. Secondly, we

need them to know that we're looking out for their personal objectives and are

successful in our desires to support them.

In the beginning, this may mean that rather than fighting the big project

battles that you want to fight, you instead lower your voice and give your

attention to smaller matters. You won't get political clout overnight. Trust and

confidence happen gradually, so you need to factor this into your plans.

First, practice thinking from your manager's point of view. You have plenty

of opportunity for interaction. If you make it a priority, it's not hard to

listen a bit harder and discern what their goals are. People are typically happy

to talk about their dreams and desires, both large and small. In casual

conversation, take an active interest in what your manager's are. Does he want

to be the CEO someday? Is he more focused on getting a good raise or bonus?

What's the criteria for which those chunks of money are handed out? Do his

superiors care about immaculate reporting, reduced costs, increased sales, or is

it more political than that? Would they be impressed if your boss passed along

insights and tidbits of internal company goings on that would allow them to

pursue their own agenda? No matter what your superior's goals are, if you

listen, ask questions, and express a sincere and active interest, you'll hear

them. If you're happy to help them wherever possible, whether it's kicking out a

great report for them in your spare time or passing along what you hear, your

influence is going to rise accordingly.

Don't make an offer of your spare time services. You'll get taken advantage

of. Instead, simply drop by one day and say, "By the way, I heard you talking

about how your boss really wanted more detailed reporting from you, so I kicked

one out in my spare time that should really impress him. Here's a sample

printout. Gotta run, got things to do, see you later…" If you perceive,

anticipate, and quietly fill needs without being asked, in a casual and business

as usual manner, you're going to get noticed. He may not say anything, but

believe me, it'll happen.

Incremental successes

Building credibility is a similar approach. You've probably been spending all

your time trying to do the job you were hired to do, right? Silly you. That

needs to be dealt with, of course, but your priorities are all wrong if you

truly want to change the world. Credibility is an incremental affair. You don't

gain it by having one huge success. Furthermore, that's too risky. One huge

success could easily turn into one huge failure. Instead of rolling the dice on

all or nothing at all, we instead simply leave a trail of small successes, so

frequent and consistent that there can be little doubt that betting on your

opinions is a sure thing.

Even if the project you're working on now is scheduled for imminent failure,

you can still get mileage out of it. The first step is shifting your thinking to

a very fine granularity. Almost any task can be broken down into a sequence of

small, consecutive actions. Let's say that you wanted to bench press 300 pounds,

and you had a body that was capable of doing so. Here's two different

descriptions of accomplishing that task.

Approach one:

  1. Took a deep breath and lifted the weights.

Approach two:

  1. Set the alarm clock

  2. Went to bed at reasonable hour

  3. Got up on time

  4. Took a shower

  5. Dressed in appropriate clothes

  6. Walked to weight room

  7. Set machine for 300 pound bench press

  8. Reclined on the bench

  9. Grabbed the weight bar

  10. Took a deep breath

  11. Focused

  12. Invoked upper body muscles

  13. Raised weights to full arm extension

  14. Took deep breath

  15. Lowered weights to resting position

  16. Rose from the bench to conclude exercise

Yes, I know, it seems kind of silly to go to all that detail when all you did

was lay down and just punch up the weights. However, the first approach shows

only that you succeeded in one effort. In the second approach, you have 16

consecutive successes on operations that each could have failed or encountered

problems. Now who would you rather put your trust in, the guy who did one thing

right, or the guy who did 16 things in a row right? This is how you must

approach every job you do. >From the smallest coding task to the largest

documentation effort, there are a host of things that you have to do right to

succeed. Take the time to write them down so that you can always refer to your

notes instead of having to recount your successes from memory.


Of course, it matters little to have ten thousand successes if the decision

makers don't know about it. Consequently, like anything else in the business

world, if you want positive results, you have to do a little advertising. Care

must be taken in how you go about it, however. You don't want to be one of those

obsequious little weasels that pander after a manager constantly recounting the

fact that you did something right. Such creatures garner no respect. To give you

an idea of a more subtle approach, consider the following example.

Let's say that you were tasked with writing a small, simple, dialog based, an

affair that should only take around a week. First, do your homework. Fire up a

spreadsheet and do your estimating, in quarter hour granularity as I've

discussed in the past. Next, having summarized the tiny detail into somewhat

larger modules, take any meetings, time off or other work distractions into

account and project dates for each module. Yes, it's a small, brainless little

app, but anything can be broken down into modules. If you're looking at a week's

worth of work, you should be able to come up with at least 5 modules, one for

each day.

Now, print that spreadsheet out, casually toss it on the manager's desk on

your way past, saying, "By the way, I'm working on that app you wanted and

here's the timeline and milestones. I'll let you know when it's done." Then keep

walking. You don't want to make a big deal out of it.

As you complete your each task, pay attention to how long it took you, and

punch that number into the spreadsheet, right then and there. Tedious, perhaps,

but you have larger goals in mind, so it's worth it. Now, at any point in the

week when the manager walks by and says, "Hey, how's that app coming?" (and you

know they will), you quickly fire up the spreadsheet from the shortcut you keep

on the desktop and say, "Right on track. As you can see, I've hit the milestones

for Monday and Tuesday, and so far today I'm right on schedule for completing on

time." When you've finished the project on time and per your own schedule, drop

off a printout of the updated spreadsheet on his desk in the same casual manner,

saying, "Here's the information on the project I just completed. Thought the

data would be useful to you. Gotta run, got things to do…"

Regardless of whether it's coding projects or accomplishing any task under

the sun, find a way to break it down, project it, track it and show not just an

overall success, but a history of successes. Additionally, always be on the

lookout for things you can provide or do that will bolster your manager's

position, and then do it quietly in the background without anyone knowing. Once

it's done, again hand off the benefits to your manager in a casual, "oh, by the

way, here's just a little thing that I thought would be useful to you" kind of

manner, including the documentation of incremental successes that you

encountered while making it happen.

By not making a big deal out of any particular incident, you don't look like

a weasel and you don't raise any defensive flags in his mind that you've done

something and now he owes you. Instead, you're building an image, one of a

worker that he can trust and count on, and one who's watching his back even when

he doesn't realize it. Keep that word in your mind - image. That's what your

priority is.

Enjoying the benefits

The payoff is huge and yet subtle. We started out talking about the

monumental waste that goes on in this business, and how so much of it could be

averted if techies were just given a little more horsepower in the decision

making process. Here's how it works.

The meeting rolls around for what looks to be yet another project disaster

kickoff. Stupid, illogical requests are made of the developers by an apparently

clueless management group. Programmers' voices are raised pointing out the

logical problems, the logical solutions and the obvious consequences of ignoring

their advice. They get passionate, they wax eloquent. Ultimately, they are

completely ignored. All the time, you sit quietly in the corner, saying nothing.

Sometime later, after the meeting is over, you collect your thoughts

regarding all the beneficial suggestions made by the team. Put together a very,

very, small and simple spreadsheet or document, no more than one page, that

highlights the suggestions along with the benefits. Summarize, summarize,

summarize! Later that day, or the next, casually drop by the manager and drop

off another "by the way" printout. Having already thought of how the benefits

you've summarized could play to the personal advantage of your manager, briefly

mention things in that light. "I was on my way to go do something else, but it

occurred to me that the points that Joe and Fred made had an interesting side

effect (note that you're not taking credit for someone else's idea, and you're

also subtly building credibility for your team mates). If we gave their approach

a shot, it would actually help you with this goal that you've been trying to

accomplish. Anyway, here's a couple of notes on how it would help you, I thought

it was something you'd appreciate. Gotta run…"

Of course, you'll have to replace that vaguely worded statement with specific

mention of the benefits to your boss, but you get the idea. At this point,

you've built up some credibility. Instead of insisting that the developers to

get their way, you're once again been seen by your boss as obviously trying to

cover his posterior. Furthermore, and this is critical, you drop the carefully

orchestrated information into his lap, and then walk away. When he makes the

decision, it needs to be his idea, not yours. Leave your ego at the door. We're

interested in results here. Never let on that the idea was other than his.

Another way this often plays out is that in the aforementioned meeting, after

you have a history of being a trusted, behind the scenes lieutenant, he may ask

you point blank, "What do you think?" Of course, you don't want to trot out the

benefits to his personal agenda in front of the group, but you can give low key

support to your fellow developers by pointing out the benefits at the management

and business level. And if you do it low key enough, your manager will very

likely pull you aside the next day and say, "Hey, tell me more about this stuff

you were talking about." There is often far more power in having the King's ear

than in being the King.

Of course, these are just general ideas and scenarios to get you thinking.

You're smart enough to outfox the compiler, so you're obviously smart enough to

do the math on each situation on your own. All you really need is to change your

priorities and approach. Instead of bold, loud, bloody frontal assaults on the

bastions of corporate waste, learn to work quietly, behind enemy lines. You're

not going to change the world. And you may only move that 90% waste figure to

70%. But when that 20% gain in productivity is in your turf, it feels really,

really good. And who knows, if we all learn to fight behind the lines, maybe we

will change the world of software development. Just realize that it will only

happen one project at a time.

About the Author

Christopher Duncan, President of Show Programming of Atlanta, is author of The

Career Programmer: Guerilla Tactics for an Imperfect World (Apress). He can

be reached at mailto:Chris@ShowProgramming.com?subject=Pro

Copyright (c) 2002, Christopher Duncan. All rights reserved.


You rated this post out of 5. Change rating




You rated this post out of 5. Change rating