Every week on “The Apprentice” may be different, but we know one thing: Donald Trump is going to walk in, ask questions, fire someone, and drive on.
You might want to work like “The Donald” on the show, but if you measure software performance, you probably feel more like a contestant on the show. After all, you start with a problem too broad and vague to adequately solve in the timefame, are involved too late to impact quality, and assigned too little staff, software, and hardware resources to do the job right.
If you’ve ever felt like that, well, I have too, and I survived. Today I’m going to offer a way out.
A Power Story
Ten years ago I was doing programming work for a large corporation. The setup was not too different from what I outlined above: My requirements were vague, the deadline set in stone, and, every now and again, someone would ‘pop in’ with a new requirement. These new requirements came verbally, by someone (usually a project manager) stopping by my desk. If I pushed back, the manager would huff and say something about how the steering committee had decided that the new feature would be included.
I was dejected. Here I had a schedule gun in my back, I was under intense pressure, and the requirements kept mounting completely out of my control.
Like I said, not too different than performance testing, or, worse, having the responsibility to deliver the entire system, where performance testing is just one more thing to tack on at the end. (With performance testing alone, you can fail the test run. If you have to build or manage the whole solution, when the test run fails, you have to fix it … before the big deadline.)
So I went to my manager, despondent. I had no power, what could I do?
My manager pointed out that I was looking at things all wrong — that I was the most powerful person in the room.
A Secret
My manager pointed out that none of the people in the list, not the project managers, the analysts, the director or VPs, none of them, could actually build the software. I was the only one.
Five people working full-time on the project, ten more giving it a few hours a week, and I was the only one who could do the work.
If I felt like building the software, it would get built on time. If I suddenly got an appendicitis and missed a week, the project would be a week late. All the blustering, bossing, yelling, and cajoling in the world could not change that simple fact.
Without little old Matt, nothing would happen.
Yes, it might be possible for the company to replace me, with someone who would have to start the mental process to understand the system. No matter how self-documenting the code would be, if the deadline was two months and I could do it two and a half, then “the new guy” would probably take four or five months.
The other people on the project had the same schedule gun in their back, but they were missing the ability to actually get the work done. Where I had some control, they had none; in a way, they were victims of the unknown skill programmer.
One more time: I was the most powerful person in the room.
The threats, scare tactics, demands, and games only worked because I allowed them to work.
Back On The Performance Project
If you took a survey of the performance test literature, you’d find a large number of appeals to get involved up front, to make sure you have dedicated resources to perform the test (and fixing!) effort, to get the performance requirements nailed down up front and drive toward them, and, if possible, to understand the capacity characteristics of the hardware before the project begins.
Those are certainly all good things, but, as my colleague Michael Bolton once told me “If your project has dug itself a hole, good process ain’t gonna pick up the shovel.” In other words, if on this project you were not involved up front, exhorting to get involved up front isn’t going to save this project. We’ll have to do it ourselves.
What can you do instead?
First, if you are on the build/test team, recognize your position as one of power. (If you, my dear reader, are on the other side of the table; if you are one of the VP’s, Project Managers, or directors, and you recognize that you can’t have anything you dream up and the steering committee wants, that gives you a different power: The power of budgeting. But that is a story for a different time.)
Second, offer to do what you can with the resources you have. That is, you don’t need to let others dictate anything. When the business gives you a week, present what you can learn about the software in a week. If it is a day, present what you can learn in a day. If all you have is an hour, well, you can probably grab ten guys and bang at the system to see if it falls over — the point is, you can always learn something.
Third, present options. Given a day, you could probably come up with two or three forms of investigation. Beyond that, you know the kind of information you could find if given two days, a week, two weeks.
The Rule Of Three
If you present one option to management, you turn them into a victim — they have to live with your decision. If you present two, you’ve create a dilemma, the kind of thing to lose sleep over.
When we get to three options, we humans start to feel like we have real choice.
It wouldn’t turn me into Donald Trump, but if I had to do it over again, when the project manager came in with the new requirement, I would have explained how long it would take, that I was already working modest overtime, and that we could slip the schedule by the extra two days, lose the feature, or lose some other feature. Then I would wag my finger and say “You’re Fired!”
Okay, maybe not that last part, but I would refuse to be a victim.
So if you’ll permit me to ask — how are your projects going, and what can you do about it?
More to come.