A horse walks into a bar and says, “I can code that feature in two days.” Dev costing and scheduling is a joke. People who truly believe such nonsense and depend on it are fools, or green PMs. It’s not just an inexact science; it’s a fabrication. Sure there are people out there who believe that coding can be refined to a reproducible process with predictable schedules and quality, but then my son still believes in the tooth fairy. The truth is that unless you are coding something that’s 10 lines long or is copied directly from previous work you have no idea how long it is going to take.
Eric Aside Program Managers (PMs) are responsible for specifying the end user experience and tracking the overall project schedule, among other duties. They are often seen by developers as a necessary evil and thus are given little respect. That’s a shame because being a PM is a difficult job to do well. Nonetheless, PMs are a fun and easy target for Mr. Wright.
Richter-scale estimating
Sure, you can estimate, but estimates come on a log scale. There’s stuff that takes months, stuff that takes weeks, stuff that takes days, stuff that takes hours, and stuff that takes minutes. When I work with my GPM to schedule a project, we use the “hard/medium/easy” scale for each feature. Hard means a full dev for a full milestone. Medium means a full dev for two to three weeks. Easy means a full dev for two to three days. There are no in-betweens, no hard schedules. Why? Because we’ve both been around long enough to know better.
In my mind, there are no dates for features on a dev schedule beyond the project dates—milestones, betas, and release. A good dev schedule works differently. A good dev schedule simply lists the features to be implemented in each milestone. The “must-have” features go in the first milestone and usually fill it. Fill is based on the number of devs and the “hard/medium/easy” scale. The “like-to-have” features go in the second milestone. The “wish” features go in the third milestone. Everything else gets cut. You usually don’t cut the “wish” features and half of the “like-to-have” features until the second week of the third milestone when everyone panics.
Eric Aside Milestones vary from team to team and product to product. Typically, they range from 6 to 12 weeks each. They are considered project dates that organizations (50–5,000 people) use to synchronize their work and review project plans. Individual teams (3–10 people) might use their own methods to track detailed work within milestones, such as simple work item lists, product backlogs, and burn-down charts.
Risk management
This brings me to my main point. Dev costing and scheduling is not about dates or time. It is about risk—managing risk. We ship software, whether it’s a packaged product or Web service, to deliver the features and functionality that will delight our customers. The risk is that we won’t deliver the right features with the right quality at the right time.
A good dev schedule manages this risk by putting the critical features first—the minimum required to delight our customers. The “hard/medium/easy” scale determines what is realistic to include in that minimal set. The rest of the features are added in order of priority and coherency.
Then you code and watch for features that go from harder to easier and from easier to harder. You shuffle resources to reduce your risk of not shipping your “must-have” features with high quality in time. Everything else is gravy and a great source of challenging but nonessential projects for interns.
Eric Aside The irony is that while almost every engineer and manager agrees with ordering “must-have” features first, few actually follow that advice because “must-have” features are often boring. They are features such as setup, build, backward compatibility, performance, and test suites. Yet you can’t ship without them, so products often slip because of issues in these areas.
It is so important to shoot down the “feature dates” myth because devs working to meet feature dates undermine risk management. The only dates that count are project dates, milestones, betas, etc.—not feature dates. Project dates are widely separated, and there are few of them. They are much easier to manage around. If devs believe they must meet a date for a feature, they won’t tell you when they are behind. “I’ll just work harder or later, eh heh, eh heh.”
Meanwhile, you are trying to manage risk. One of your risk factors is an overworked staff. Another is a hurried, poor-quality feature. Another is losing weeks of time when you could have had two or three devs or more senior devs working on a tough issue. You lose that time when your dev staff thinks their reviews revolve around hitting feature dates instead of helping you manage the risk to the product’s critical features.
The customer wins
When you make it clear to your dev team that the success of the product depends on your ability to manage the risk to critical features, everything changes. Sure, getting extra features is a nice bonus, but the key is the focus on communicating risk areas and working together to mitigate them.
When everyone understands the goal, everyone works better to achieve it. This also helps to boost morale when the tough cuts are made, and it rewards mature decisions by junior staff. In the end, our customers are the big winners because they get the features they really want with the quality they expect, instead of the features that happened to make it at whatever level of quality sufficed.
BTW, everything I said about dev scheduling applies equally well to test scheduling.
Be First to Comment