Time to reply to comments about my June column: Dev schedules, flying pigs, and other fantasies. Most comments were quite flattering, but I won’t bore you with just how right I am. Instead, allow me to address the ignorant, incessant ramblings of the unenlightened, yet effusive, readers of this column.
Eric Aside This was my first and only “mail bag” column, with responses to e-mail I received. I continue to get plenty of “feedback” on my column, but once the column became popular the number of new topic requests vastly outweighed the value of answering e-mail on a past topic. However, looking back over this early column makes me wonder if Mr. Wright should empty the mail bag again.
Software engineering is clearly ambiguous
I am incredulous at the supposition that development of a feature cannot and should not be scheduled. The statements in the article accurately portray the activity of “coding.” Unfortunately, this is what Jr. High schoolers do when they are throwing together a VB app to decode messages to each other. We, on the other hand, are supposed to be software engineers and not hackers.
—Incredulous ignoramus
I hear this kind of thing often, and it just needs to stop. Bank managers don’t manage banks and software engineers don’t engineer software. They write software, custom software, usually from scratch, with no prior known measures of nominal operating range, tolerances, failure rates, or stress conditions. Sure, we have those for systems, but not for coding itself.
I went to an engineering school. Many of my friends were electrical, civil, aeronautical, or mechanical engineers. Engineers work on projects in which the building blocks and construction process are well defined, refined, and predictable. While there is great creativity in putting the building blocks together in novel ways to achieve an elegant design for a custom configuration, even the most unusual constructions fall within the tolerances and rigor of known qualities and behaviors.
The same cannot be said for software development, although many are trying to reach this goal. The building blocks of software are too low level and varied. Their interactions with each other are too unpredictable. The complexities of large software systems—such as Windows, Office, Visual Studio, and the core MSN properties—are so far beyond the normal scope of engineering that it is beyond hope to make even gross estimates on things like mean-time-to-failure of even small function changes in those systems.
So for better or worse, it’s time to get past wishful thinking and high ideals and return to reality. We’ve got to accept that we are developers, not engineers. We simply cannot expect the predictability that comes with hundreds or even thousands of years of experience in more traditional engineering any more than we can expect a computer to do what we want instead of what we tell it. We just aren’t there yet.
Eric Aside Now, six years after I wrote this column, Microsoft measures mean-time-to-failure of much of our software. In addition, methods are becoming available to treat programming as engineering, which I describe in the later column, A software odyssey—From craft to engineering. Even so, I stand by this column as an accurate reflection of software development as a field that has grown past its infancy but remains in its teenage years as compared to its fully grown engineering brethren.
Believe half of what you see and none of what you hear
If I’m relying on another team/product group for a feature or piece of code, I sure don’t want to hear, “It should be done in this milestone.” I want dates. I need specifics.
—In need of a date
I could write several columns on dependencies and component teams, and perhaps I will, but for now I’ll just discuss dependency dev schedules. First of all, if your dependency did have a dev schedule, would you believe it? If you said, “Sure, what choice do I have?” start taking Pepcid now before your ulcer develops. It’s not only the dev schedule either. Don’t believe anything dependencies say—ever. If they are in the next room and tell you it’s raining, check your window first.
This doesn’t mean you can’t work with dependencies—you can, and it can be a great experience and a windfall for your team, product, and customers. You just must keep a close eye on what’s happening. Get regular drops and conduct automated testing of those drops. Get their read/write RAID RDQs and watch their counts and problem areas. Send your PM to their triage meetings. Get on their e-mail aliases.
Eric Aside Check the glossary for help with these bug-tracking references.
Basically, watch dependencies like a hawk; they are an extension of your team and your product. The more you stay in touch and current, the better you will be able to account for shortcomings and affect changes. As for when features will be ready, you simply must rely on your influence to up priorities and on your communication channels and private testing to know when features are really ready.
Motivation: It’s not just pizza and beer
Your general sentiments make more sense for early level planning of a project than the final milestone before shipping. You need to address issues such as how schedules are often used as management tools to drive performance of the team, providing deadlines and time constraints to execute against.
—Can’t find the gas pedal
First, let me reiterate, if you hold devs to features dates, they will lie and cheat to meet the dates. They will lie about status, and they will cheat on quality and completeness. If you don’t want to experience either of these from your dev team, you need to come up with a better motivational mechanism. I’ve used three different approaches in coordination with each other to great effect.
First, at a basic level, there are the Richter-scale estimates themselves. My devs know that I expect each feature to be done in roughly that amount of time. If a two-week task takes two and a half weeks, that’s probably okay. If it’s taking much longer, there’s usually a good reason and the dev will let me know. The lack of a good reason provides ample motivation. However, because there’s no hard date, lying and cheating are rare.
The second motivational tool is finishing the milestone. This can be dangerous in that it can invite shortcuts, but the overall effect is to encourage devs to work hard from the start and to know when they are behind. The key difference between a feature date and a milestone date is that the latter is a team date. The whole team works together to hit it. Therefore, there is less individual pressure to cut corners. However, that still can happen, which leads me to the last and most effective technique.
Eric Aside This notion of a self-directed team working toward a clearly defined common goal is central to many agile techniques, though back in 2001 I didn’t know it.
The last motivational tool that I use is by far the best. I make it clear to the team which features are the must-ship features, the ones we must finish first. I tell them that everything else can and will be cut if necessary. Unfortunately, the must-ship features are often among the most mundane to code and the least interesting to brag about. So I tell my team that if they want to work on the cool features, they must first complete and stabilize the critical features. Then they will be rewarded by working on the less critical and far flashier stuff. This kind of motivation is positive, constructive, and extremely effective. Works every time.
Sinking on a date
Continued from the previous quote: [You also need to address] that schedules are an absolute necessity for aligning the work of different functional areas (not just Dev, but PM, QA, UE, Marketing, external partners).
—Brain out of alignment
If you really needed solid feature dates to synchronize disciplines and dependencies, no software would ever ship. Of course, we do ship software all the time—we even shipped a huge effort, Office XP, on the exact date planned two years in advance. Thus, something else must be the key.
What really matters is agreeing on order, cost, and method, and then providing timely status reports. The agreements should be negotiated across the disciplines, and the process for giving status should be well defined and should avoid blocking work.
- Order Negotiating the order of work on features is nothing new, although there are some groups who never agree on priorities.
- Cost Negotiating cost is often done between the dev and PM. (For example, a dev says, “If we use a standard control, it’ll save you two weeks.”) But sometimes it’s left just to the dev. It should also include test and ops.
- Method Negotiating the methods to be used is frequently done for PM specs, but it’s done less frequently for dev and test specs—to their detriment.
- Status reporting As for timely reporting of status, you really need check-in mail and/or test release documents (TRDs) to keep PM, test, and ops aware of progress. Test needs to use alerts for blocking bugs. And PM should use something like spec change requests (SCRs) to report spec changes. (To learn more about SCRs, read Late specs: Fact of life or genetic defect?.)
If the different groups can plan the order of their work, know about how long it will take, have confidence in the methods used, and maintain up-to-date status reports, projects hum. Problems are found, risk is mitigated, and surprises are few. More importantly, no one is pressured to do the wrong thing by artificial dates. Instead, everyone works toward the same goal—shipping a delightful experience to our customers.
Be First to Comment