“Hard Code” is an opinion column for developers by I. M. Wright, Microsoft development manager at large. The column’s motto is “Brutally honest, no pulled punches.” If you enjoy this column/podcast, you’ll enjoy I. M. Wright’s “Hard Code” (Microsoft Press, 2008), which includes 49 columns and numerous Eric Asides contextualizing I. M.’s unpulled punches. (Eric Brechner is Director of Development Excellence in Microsoft’s Engineering Excellence group.)
Today’s podcast is new, published in September 2009, and it can be found here.
I. M. opens this month’s column/podcast this way:
My older son can now drive. This adds two new worries to my life—how ancient I feel and thoughts of my son in a ditch somewhere. To mitigate the second worry, my wife and I enforce a curfew and insist my son call if he s running late. The other night, he arrived home 20 minutes late without notice. My wife was furious that he was late. I was furious that he didn t call. Why didn t my son call to say he was running late? Because, like my wife, he was focused on the schedule. He avoided facing conflict until he got home. He said, "I got home as fast as I could"—presumably breaking numerous traffic regulations along the way. My son completely missed the point. The purpose of the rules was to mitigate risk, yet his response to them was to drive recklessly. Software engineers do this all the time. They come up with a development schedule, unexpected issues come up, and they end up being late. Instead of informing their managers of the delay, they avoid facing conflict, rush the work, sacrifice quality, and slip the schedule, all with little control or visibility. It s the opposite of what managers should want, yet those same managers insist on following the schedule precisely. Why? Because most managers and engineers don t distinguish between the two types of scheduling—meeting a commitment and managing risk. Those who understand binary and those who don t Yes, that s right. There are two types of scheduling and project management. § Meet a commitment. You made a commitment to customers or partners and you must meet it at the quality and time period promised. Period. § Manage risk. There is a mix of critical and desirable work. People can make bad choices. Issues can arise. You must manage risk to ensure critical work gets done. These two approaches to scheduling and project management often get confused. Why? § They typically appear together. The overall project has commitments, but it is made up of smaller tasks that require risk management. § They both use dates. The difference is that dates for commitments are untouchable and drive everything. Dates for risk management are simply checkpoints to make sure work stays on track. § They both are called scheduling. Most people simply don t know the difference. § Meeting commitments is the only type most people are taught. From the time kids enter school, they are exposed to inflexible due dates and commitments they must meet. When they later learn project management, it is all about Gantt charts and milestones, with some risk management thrown in as an aside. § Managing risk is usually self-taught and informal. A small number of people are formally taught risk management. Most of us learn it from peers in college as we juggle large workloads. Instead of completing everything on-time, we form workgroups, focus on the critical work, and minimize the damage to our grades. This tragic lack of understanding leads to horrible decisions, poor engineering, and scheduling disasters. You need to know the difference and apply the right scheduling to the right problems. Let s start with meeting commitments.
My older son can now drive. This adds two new worries to my life—how ancient I feel and thoughts of my son in a ditch somewhere. To mitigate the second worry, my wife and I enforce a curfew and insist my son call if he s running late. The other night, he arrived home 20 minutes late without notice. My wife was furious that he was late. I was furious that he didn t call.
Why didn t my son call to say he was running late? Because, like my wife, he was focused on the schedule. He avoided facing conflict until he got home. He said, "I got home as fast as I could"—presumably breaking numerous traffic regulations along the way. My son completely missed the point. The purpose of the rules was to mitigate risk, yet his response to them was to drive recklessly.
Software engineers do this all the time. They come up with a development schedule, unexpected issues come up, and they end up being late. Instead of informing their managers of the delay, they avoid facing conflict, rush the work, sacrifice quality, and slip the schedule, all with little control or visibility. It s the opposite of what managers should want, yet those same managers insist on following the schedule precisely. Why? Because most managers and engineers don t distinguish between the two types of scheduling—meeting a commitment and managing risk.
Yes, that s right. There are two types of scheduling and project management.
§ Meet a commitment. You made a commitment to customers or partners and you must meet it at the quality and time period promised. Period.
§ Manage risk. There is a mix of critical and desirable work. People can make bad choices. Issues can arise. You must manage risk to ensure critical work gets done.
These two approaches to scheduling and project management often get confused. Why?
§ They typically appear together. The overall project has commitments, but it is made up of smaller tasks that require risk management.
§ They both use dates. The difference is that dates for commitments are untouchable and drive everything. Dates for risk management are simply checkpoints to make sure work stays on track.
§ They both are called scheduling. Most people simply don t know the difference.
§ Meeting commitments is the only type most people are taught. From the time kids enter school, they are exposed to inflexible due dates and commitments they must meet. When they later learn project management, it is all about Gantt charts and milestones, with some risk management thrown in as an aside.
§ Managing risk is usually self-taught and informal. A small number of people are formally taught risk management. Most of us learn it from peers in college as we juggle large workloads. Instead of completing everything on-time, we form workgroups, focus on the critical work, and minimize the damage to our grades.
This tragic lack of understanding leads to horrible decisions, poor engineering, and scheduling disasters. You need to know the difference and apply the right scheduling to the right problems. Let s start with meeting commitments.
Enjoy.
Share this post :