![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Sometimes, it seems like non-programmers have a hard time accepting that there are limits on what can be done - both hard and fast limits, and limiting points where you can do more or act faster...if you're willing to risk a failure worse than the start. When you give them a time estimate, they complain that it's broad and surely you can be more precise. Well...no, you can't.
Let me compare it for a moment to a relatively simple trip. Say that you have to get from downtown Wilsonville to the Portland airport (a trip of only some 30 miles, by the way).
Then you might say it would take about a half hour. And you wouldn't be far wrong; but if you gave that estimate to your friend who was arriving, only to get stuck in a traffic jam that added a half hour to your trip, I doubt your friend would be very happy. They would likely be understanding: people understand traffic jams better than the software equivalent, simply because they're daily occurrences.
Let's back up and analyze the simple task of 'getting to the airport', assuming that an on-time arrival (for some value of on-time) is of some importance to us. There are a lot of choices we can make, some of which we automatically reject.
For example, we could walk to the airport. This is unpleasant, tedious, prone to interruptions or problems (depending on what we are walking through) and bound to use an indirect route (since walking along the side of the freeway we would otherwise use for this trip is not permitted). It's going to take a long time, and you're probably wondering why it's even listed. This is the equivalent of taking worst-case practices, muddling through without evaluating available options or trying to improve them. It gets done, and not just when you can't afford better 'transportation', but hopefully a quick evaluation will tell you this isn't the right approach...if you do the quick evaluation. Granted, it's certain, but it's certainly slow.
The next step up: let's take a bike. Okay, at least you'll be a little better off, but it's still fairly slow, and you're still off the freeway. You've got a couple vulnerabilites you didn't have (flats, other equipment problems) in addition to the ones you did before (confusion, injury), but the new vulnerabilities are fairly easy to control for. You're not exactly Mr. Speedy over here, though. Sadly, a lot of software projects bike it for part or all of the process. If only all of that effort actually counted as exercise anywhere but in this analogy....
Buses. Public transportation. Whether or not this is an improvement is a question: you're now at the mercy of someone else's schedule and path. If they happen to do exactly what you want, that's very helpful. If they don't, it can be anywhere from somewhat useful down to majorly delaying. Public transportation equates nicely to off-the-shelf solutions integrated into your project....
Cars. Cars are a lovely option. This is the area you'd like to think your software project is in! Using the right equipment (be that hardware or software) to improve speed, while staying within fairly normal limits. But you have a whole host of new problems. First, a car requires some expertise to drive; not a lot, and most people can master it, but you do have to have at least learned the basics (or have an instructor - though I wouldn't pick this particular example drive for a 'first time out' any more than I'd pick any large part of a major project for the programming equivalent).
A bike can get through a traffic jam; your car gets stuck in it. Accidents are possible (involving you, or just blocking your progress - think contractor non-delivery, or management squabbles). The possibility for mechanical breakdowns puts the bike to shame. You take on additional, relatively controllable risks in exchange for the speed benefit - and I think, since most of us don't seem to be biking it to the airport, we'd say it's worth it. Some are preventable (a regular oil change, or its software equivalent; not planning to drive the frreeway at an hour when it routinely suffers gridlock) and others are something you can account for (I have to go at 4 pm: better tell her I might be up to a half hour late due to the usual traffic).
(Welcome to risk identification....)
Then there's the option of speeding a little, or a lot. Of course (ignoring the question of whether you 'should' in the ethical sense), doing this increases your odds of an accident and your odds of being delayed by a police officer...and increases the odds that an accident will be seriously delaying. That's assuming that you're in a situation where speeding's possible; in stop-and-go traffic, after all, you're lucky if you come near the speed limit from the bottom side.
We're getting into the riskier areas, here. You've opened yourself up to serious delay or even total stoppage, in exchange for the possibility of quicker results. Just like all too many drivers, programmers often "put the pedal to the metal" under the awareness of an impossible deadline, without thinking about the other drivers or the police officer. And routinely, they fail almost as spectacularly. (Not quite. I haven't yet seen a software project failure kill the programmer, though certainly in some cases the project manager has certainly seemed close to it....)
If you're really stubborn, you can take a helicopter. This may shorten the time, and will add to the complexity. First, you need a helicopter (read, fancy technique, hardware, or software). Next, you need a helicopter pilot (someone who knows the technique, hardware, or software well enough to utilize it to advantage). Then you probably need some permits, a landing pad down in Wilsonville that you can use, and other such advantages. You've got better speed at less risk - if and only if the permits, landing spot, helicopter, and pilot are all available. If your pilot isn't as skilled, you will have more risk, down to the point where a novice is probably not worth the effort of putting at the controls.... Unless your goal is to 'crash and burn' the helicopter to convince management to stop planning around it.
This is equivalent to the high-end tools and techniques that are expected to help in projects. Sometimes they do. A lot. If they are the right tool, and you have the right people. If you can't get clearance to land your helicopter at or near the airport, it's worthless. If you can't get a pilot, or if it has mechanical problems, or if you have a pilot and pads and clearances and no helicopter (because there's, say, a purchasing freeze on some key piece), it's worthless. It's also worthless if the time required to fuel and otherwise prepare, take off, land, flight-check, and go through all the procedures eats up the time saved over driving due to its flight speed...and if that happens, you've still paid for the helicopter. And the pilot. And the pad. And the clearances....
Throwing a 'new technique' or 'helper program' at it is not always the answer. Sometimes. But not always.
There is an extreme past which you really can't go. If I say the helicopter is the fastest you can get there, you could postulate near-future technologies that would speed it up. That's true, but if you try to put them in use now, you've just diverged from your original goal and started a software R&D experiment...and that is guaranteed to go over schedule. Sure, the vertical take-off jet will get you there faster than the helicopter. After you've invented and perfected it, created the maintenance setup, trained the pilot (or yourself as a pilot, whichever you prefer), and you still need a landing spot at each end and the necessary clearances. Have fun; I've been to the airport and back many times before you're halfway to the new vehicle.
And there is still an upper limit. You might be able to change what it is, but in the realms of currently realistic science - what can be done today - there is no way to travel to that airport in, say, 5 minutes (to pick an arbitrary number). It simply cannot be done with the realities of the situation. And driving to an airport doesn't involve human creativity. (At least, we hope it doesn't. That can be one of the most dangerous risks in driving - when someone gets creative - whereas in software design, it's desirable. In controlled fashion. Sometimes.)
Okay, so far I've talked about one trip. But one trip is just, really, one feature or capability. A software project has several, often tens, occasionally a hundred or more, features/capabilities. (It depends on how you define them, but bear with me, I'm not going to get that precise.)
So a full project is, really, more like a convention or meeting where you're responsible for the participants' travel. It's not one trip to the airport, but many - and some will be to other airports, or to the train station or the docks, depending on method of arrival. Parts of it you may be able to cover for with a cab or public transportation (off-the-shelf solutions) while others can't be handled that way (areas that must be coded in-house). Depending on the area of your work, this balance may tip more one way or the other, but sooner or later you have to decide how you're getting ot the airport/bus station/train station/whatever.
And that's when it gets really fun. Because now you get a call that someone's plane is late and they won't be on the ground for another hour. Okay, that's not so bad, you probably planned for some of that. But in software, another thing happens frequently that is truly ugly: the guest who was arriving at the Portland Airport calls you on your cell. You're about 5 minutes from the airport, and she announces that she hopes you don't mind, but she flew into Salem instead because it was there, and could you make sure she gets picked up there?
Welcome to 'changing requirements'. The later in the project they change, the harder it is to get it right and still stay on schedule. If you'd been warned at the outset that you were going to Salem, you'd have been fine: it's maybe a slightly different distance, but only by a matter of a few miles, and you could have gotten it into the schedule. Wilsonville is neatly between the two. But now you've driven maybe twenty miles toward the Portland airport - which is exactly the opposite direction from Salem. You have to turn around and head back (rip out all your changes) and then continue on to Salem (rewrite it as requested).
Anyone still wonder why programmers hate last-minute requirements changes? It's not so bad if you ask us to go to terminal A instead of terminal B, it's only mildly annoying to be asked to go to the train station 2 miles away instead of the airport, but even those cause delays and problems sometimes (particularly if we chose a specialized technology solution, and we don't have a helicopter pad near the new destination!). But the wilder the change, the bigger the impact.
It happens routinely, in varying degrees.
It's not that programmers don't want matter transmitters. Or that we don't wish we were in Salem instead of Portland, or wish we hadn't taken a wrong turn or gotten a flat or whatever happened. But we are human, estimates are imprecise, and changing the rules results in problems - bigger problems the later in the game the rules are changed. (But if we tried for a helicopter answer and your change of plans means we can't use it, we've eaten the cost and the trouble - and may even have to work around a helipad - even if the change happens only shortly after we acquire the necessary parts....)
The analogy also neatly illustrates the fact that you can't make a perfectly precise estimate. When you first ask me "How fast can you get to the Portland Airport, Tuesday afternoon, if you leave at four?" - I can't answer. I can guess. "It should take...well, it'd be a half hour in clear traffic, but it probably won't be clear then...maybe 45 minutes, maybe an hour." It's the bane of programmer's lives that statements equivalent to that one are often translated as "She said a half-hour" or, at best, the 45 minutes figure.
You can buy knowledge. Do a bit of research (check the traffic cams, listen to the radio traffic report). The closer you get to the time and the work, the more knowledge you have (the traffic cams and radio report aren't really useful until Tuesday approaching the time, after all; and there's nothing like being in the traffic for telling you if it's moving, or if the radio forgot to mention that it was a parking lot because they were more interested in the accident downtown).
I've probably beaten the analogy to death, but I think it's a good one and makes the point in terms that are more understandable than just talking about risk factors and the difficulty of estimation. If nothing else, I kept myself amused and out of trouble for a while, which has to be worth something.
I'm going to bed now. Hopefully I won't be dreaming of helicopters full of code, but you never know.
Let me compare it for a moment to a relatively simple trip. Say that you have to get from downtown Wilsonville to the Portland airport (a trip of only some 30 miles, by the way).
Then you might say it would take about a half hour. And you wouldn't be far wrong; but if you gave that estimate to your friend who was arriving, only to get stuck in a traffic jam that added a half hour to your trip, I doubt your friend would be very happy. They would likely be understanding: people understand traffic jams better than the software equivalent, simply because they're daily occurrences.
Let's back up and analyze the simple task of 'getting to the airport', assuming that an on-time arrival (for some value of on-time) is of some importance to us. There are a lot of choices we can make, some of which we automatically reject.
For example, we could walk to the airport. This is unpleasant, tedious, prone to interruptions or problems (depending on what we are walking through) and bound to use an indirect route (since walking along the side of the freeway we would otherwise use for this trip is not permitted). It's going to take a long time, and you're probably wondering why it's even listed. This is the equivalent of taking worst-case practices, muddling through without evaluating available options or trying to improve them. It gets done, and not just when you can't afford better 'transportation', but hopefully a quick evaluation will tell you this isn't the right approach...if you do the quick evaluation. Granted, it's certain, but it's certainly slow.
The next step up: let's take a bike. Okay, at least you'll be a little better off, but it's still fairly slow, and you're still off the freeway. You've got a couple vulnerabilites you didn't have (flats, other equipment problems) in addition to the ones you did before (confusion, injury), but the new vulnerabilities are fairly easy to control for. You're not exactly Mr. Speedy over here, though. Sadly, a lot of software projects bike it for part or all of the process. If only all of that effort actually counted as exercise anywhere but in this analogy....
Buses. Public transportation. Whether or not this is an improvement is a question: you're now at the mercy of someone else's schedule and path. If they happen to do exactly what you want, that's very helpful. If they don't, it can be anywhere from somewhat useful down to majorly delaying. Public transportation equates nicely to off-the-shelf solutions integrated into your project....
Cars. Cars are a lovely option. This is the area you'd like to think your software project is in! Using the right equipment (be that hardware or software) to improve speed, while staying within fairly normal limits. But you have a whole host of new problems. First, a car requires some expertise to drive; not a lot, and most people can master it, but you do have to have at least learned the basics (or have an instructor - though I wouldn't pick this particular example drive for a 'first time out' any more than I'd pick any large part of a major project for the programming equivalent).
A bike can get through a traffic jam; your car gets stuck in it. Accidents are possible (involving you, or just blocking your progress - think contractor non-delivery, or management squabbles). The possibility for mechanical breakdowns puts the bike to shame. You take on additional, relatively controllable risks in exchange for the speed benefit - and I think, since most of us don't seem to be biking it to the airport, we'd say it's worth it. Some are preventable (a regular oil change, or its software equivalent; not planning to drive the frreeway at an hour when it routinely suffers gridlock) and others are something you can account for (I have to go at 4 pm: better tell her I might be up to a half hour late due to the usual traffic).
(Welcome to risk identification....)
Then there's the option of speeding a little, or a lot. Of course (ignoring the question of whether you 'should' in the ethical sense), doing this increases your odds of an accident and your odds of being delayed by a police officer...and increases the odds that an accident will be seriously delaying. That's assuming that you're in a situation where speeding's possible; in stop-and-go traffic, after all, you're lucky if you come near the speed limit from the bottom side.
We're getting into the riskier areas, here. You've opened yourself up to serious delay or even total stoppage, in exchange for the possibility of quicker results. Just like all too many drivers, programmers often "put the pedal to the metal" under the awareness of an impossible deadline, without thinking about the other drivers or the police officer. And routinely, they fail almost as spectacularly. (Not quite. I haven't yet seen a software project failure kill the programmer, though certainly in some cases the project manager has certainly seemed close to it....)
If you're really stubborn, you can take a helicopter. This may shorten the time, and will add to the complexity. First, you need a helicopter (read, fancy technique, hardware, or software). Next, you need a helicopter pilot (someone who knows the technique, hardware, or software well enough to utilize it to advantage). Then you probably need some permits, a landing pad down in Wilsonville that you can use, and other such advantages. You've got better speed at less risk - if and only if the permits, landing spot, helicopter, and pilot are all available. If your pilot isn't as skilled, you will have more risk, down to the point where a novice is probably not worth the effort of putting at the controls.... Unless your goal is to 'crash and burn' the helicopter to convince management to stop planning around it.
This is equivalent to the high-end tools and techniques that are expected to help in projects. Sometimes they do. A lot. If they are the right tool, and you have the right people. If you can't get clearance to land your helicopter at or near the airport, it's worthless. If you can't get a pilot, or if it has mechanical problems, or if you have a pilot and pads and clearances and no helicopter (because there's, say, a purchasing freeze on some key piece), it's worthless. It's also worthless if the time required to fuel and otherwise prepare, take off, land, flight-check, and go through all the procedures eats up the time saved over driving due to its flight speed...and if that happens, you've still paid for the helicopter. And the pilot. And the pad. And the clearances....
Throwing a 'new technique' or 'helper program' at it is not always the answer. Sometimes. But not always.
There is an extreme past which you really can't go. If I say the helicopter is the fastest you can get there, you could postulate near-future technologies that would speed it up. That's true, but if you try to put them in use now, you've just diverged from your original goal and started a software R&D experiment...and that is guaranteed to go over schedule. Sure, the vertical take-off jet will get you there faster than the helicopter. After you've invented and perfected it, created the maintenance setup, trained the pilot (or yourself as a pilot, whichever you prefer), and you still need a landing spot at each end and the necessary clearances. Have fun; I've been to the airport and back many times before you're halfway to the new vehicle.
And there is still an upper limit. You might be able to change what it is, but in the realms of currently realistic science - what can be done today - there is no way to travel to that airport in, say, 5 minutes (to pick an arbitrary number). It simply cannot be done with the realities of the situation. And driving to an airport doesn't involve human creativity. (At least, we hope it doesn't. That can be one of the most dangerous risks in driving - when someone gets creative - whereas in software design, it's desirable. In controlled fashion. Sometimes.)
Okay, so far I've talked about one trip. But one trip is just, really, one feature or capability. A software project has several, often tens, occasionally a hundred or more, features/capabilities. (It depends on how you define them, but bear with me, I'm not going to get that precise.)
So a full project is, really, more like a convention or meeting where you're responsible for the participants' travel. It's not one trip to the airport, but many - and some will be to other airports, or to the train station or the docks, depending on method of arrival. Parts of it you may be able to cover for with a cab or public transportation (off-the-shelf solutions) while others can't be handled that way (areas that must be coded in-house). Depending on the area of your work, this balance may tip more one way or the other, but sooner or later you have to decide how you're getting ot the airport/bus station/train station/whatever.
And that's when it gets really fun. Because now you get a call that someone's plane is late and they won't be on the ground for another hour. Okay, that's not so bad, you probably planned for some of that. But in software, another thing happens frequently that is truly ugly: the guest who was arriving at the Portland Airport calls you on your cell. You're about 5 minutes from the airport, and she announces that she hopes you don't mind, but she flew into Salem instead because it was there, and could you make sure she gets picked up there?
Welcome to 'changing requirements'. The later in the project they change, the harder it is to get it right and still stay on schedule. If you'd been warned at the outset that you were going to Salem, you'd have been fine: it's maybe a slightly different distance, but only by a matter of a few miles, and you could have gotten it into the schedule. Wilsonville is neatly between the two. But now you've driven maybe twenty miles toward the Portland airport - which is exactly the opposite direction from Salem. You have to turn around and head back (rip out all your changes) and then continue on to Salem (rewrite it as requested).
Anyone still wonder why programmers hate last-minute requirements changes? It's not so bad if you ask us to go to terminal A instead of terminal B, it's only mildly annoying to be asked to go to the train station 2 miles away instead of the airport, but even those cause delays and problems sometimes (particularly if we chose a specialized technology solution, and we don't have a helicopter pad near the new destination!). But the wilder the change, the bigger the impact.
It happens routinely, in varying degrees.
It's not that programmers don't want matter transmitters. Or that we don't wish we were in Salem instead of Portland, or wish we hadn't taken a wrong turn or gotten a flat or whatever happened. But we are human, estimates are imprecise, and changing the rules results in problems - bigger problems the later in the game the rules are changed. (But if we tried for a helicopter answer and your change of plans means we can't use it, we've eaten the cost and the trouble - and may even have to work around a helipad - even if the change happens only shortly after we acquire the necessary parts....)
The analogy also neatly illustrates the fact that you can't make a perfectly precise estimate. When you first ask me "How fast can you get to the Portland Airport, Tuesday afternoon, if you leave at four?" - I can't answer. I can guess. "It should take...well, it'd be a half hour in clear traffic, but it probably won't be clear then...maybe 45 minutes, maybe an hour." It's the bane of programmer's lives that statements equivalent to that one are often translated as "She said a half-hour" or, at best, the 45 minutes figure.
You can buy knowledge. Do a bit of research (check the traffic cams, listen to the radio traffic report). The closer you get to the time and the work, the more knowledge you have (the traffic cams and radio report aren't really useful until Tuesday approaching the time, after all; and there's nothing like being in the traffic for telling you if it's moving, or if the radio forgot to mention that it was a parking lot because they were more interested in the accident downtown).
I've probably beaten the analogy to death, but I think it's a good one and makes the point in terms that are more understandable than just talking about risk factors and the difficulty of estimation. If nothing else, I kept myself amused and out of trouble for a while, which has to be worth something.
I'm going to bed now. Hopefully I won't be dreaming of helicopters full of code, but you never know.
no subject
no subject