TBT – Re-posting: Software Estimation

My debut to the software world was about seven months ago. Prior, the projects I managed had tangible assets: prints, videos, landscapes, structures, etc. Obviously in the software world there are no longer physical structures or tangible assets. This alone has been the most difficult hurdle to deal with… not because you can’t ‘see’ the project; but because the project idea is no longer bound by constraints.

PLANNING

Why do we plan? Two reasons. First, rarely will a stakeholder give you the green light to start a project until you can tell them how long it will take, what the deliverables are, and most importantly, how much it will cost. Secondly, a plan allows you to monitor actual progress to planned progress which allows you to throw a big red flag early before it’s a bigger issue that impacts the schedule and budget.

The better you are at planning, the better your bids and the more effectively you’re able to manage projects.

AGILE

Agile project management methodologies (like Scrum) are the creation of poor planners. Designed by developers turned project managers who didn’t understand the black box that is project planning, and in most cases widely accepted by clients who were equally, or even worse at planning. The client couldn’t plan or forecast their needs; which inhibited the software world from developing accurate plans (even if they’d known how to).

[…Let the hate mail roll-in…]

I won’t say that Agile doesn’t have its place, it does. And I won’t say that Agile is a poor format, it’s not. But I do think there are far better ways to go about project management. If your project has a drop-dead due date and a hard budget, you’ll never deliver using Agile.

The gains seen and quoted by Agile are compared to broken waterfall formats — not working ones. It’s a lot like comparing the gas mileage of a 30 year-old compact car that hasn’t been maintained to a brand-new bus and citing the bus’ mileage as a vast improvement. Saying that everyone who wants to save money on gas should go buy a bus to drive around.

MFG. & CONSTRUCTION VS SOFTWARE

The difference between manufacturing and construction; and software is not the end product. Yes, the former deliver physical assets and the latter intangible code. However, the real difference is how they work.

Manufacturing and construction have been around a long time, which has allowed both industries to create standards. Standard bidding and procurement processes. Standard costs, efficiencies and margin.

None of these exist in software.

Manufacturing and construction also share the same fatal flaw. In manufacturing, the sales team, designers, design engineers, manufacturing engineers and operations team all sit in a different place. A project is born in sales and moves like a cowboy jumping from boxcar to boxcar on a speeding train. Sometimes they slip, or fall, or have to turn-around. The design engineers say that the product sales dreamed up cannot be created. The manufacturing engineers say the plans the design engineers drew cannot be built. And the ops guys tell the manufacturing engineers that their cells or lines or whatever will hurt their margins, efficiencies, et cetera; or that pricing on the needed materials is impossible to acquire.

In construction we replace the engineers and operations team with architects, engineers and contractors. Architects draw what cannot designed. Engineers design what cannot be built.

In software, the general practice is that all the disciplines (interaction design, visual design, front-end and back-end development) sit in the same room and work iteratively on the same project. It would be like putting all of the manufacturing people in the same conference room and telling them to build a product or all the construction disciplines in a work-site trailer to hash-out all the details. The result is a far more refined end product.

The problem of course, is that at end of the exercise you have a finished product. How do you bid or estimate a project that is planned during construction? You can’t.

The broken system used in manufacturing and construction breaks each part of the process off into a separate world that is controlled, planned, bid and built. The downside of course is that rework is often created and oversights that a collaborative setting would catch, missed.

BIDDING

I’ll fall back on an industry I know well, landscape construction. When asked to bid an outdoor living area, typically a designer is the first on the scene. They bill a flat rate assuming a set number of iterations. They design based on physical constraints (soil type, area, exposure) and project constraints (time and money) which makes knowing how much a design will cost an easy calculation. In software, only the latter half exists of the needed equation.

Once the stakeholder approves the design, a contractor[s] bids the job. The contractor knows from takeoffs about the same constraints the designer did. They’ll also factor in whether an engineer is needed for any structures and the overall complexity of the project. For example, is the site machine accessible? or will portions need to be done by hand?

Everything in construction has a metric that’s fairly accurate. X feet an hour to dig french drains. Add a complexity factor of .31 for rocky soil, .15 for re-routing irrigation, .85 for hand digging. Add an area modifier of .3 for New York, or (-0.01) for rural Virginia.

All the required measurements are on the plan, as are the materials. The most difficult part here is anticipating problems that are only learned through experience. Knowing to check property lines, utility markings, drainage issues and other caveats that an inexperienced estimator may not account for. Another good example is site setup preparing in advance how a site will be laid out so that the damage to other parts of the lawn/landscape is minor and already baked into the bid.

The point however, is that the result is actual costs or accrued historical costs multiplied by complexity. In software, there are no historical or actual costs and complexity is incredibly difficult to assess.

A great example is a share hyperlink. The word, “share” that has been hyper-linked can vary by a factor of ten (10!) based on whether it interacts with an API (like Twitter) or simply re-directs using a self-hosted URL. Think about that. Even with detailed mock-ups not asking the question, “What happens when you click share?” can vary your estimate by a factor of 10. Ten!

CONSTRAINTS

As alluded to above, what enables industries like construction to outperform software in estimating is constraints and process. Process is debatable, but constraints are not.

Buildings are bound to the physical constraints of their lot. The lot is a certain size, in a particular zone, of a specific soil stability, grade and exposure.

Construction projects are constrained by available materials. For example a typical stud for an 8′ ceiling is 2′x4′x92 ⅝” (or 96″). No one, for both logistical and cost reasons, would ever ask for a house be built of a lumber size that isn’t already in production.

The third constraint not shared by software is industry standards and regulations. A structure must meet a mandated code for structural integrity and safety. Standard roof pitches, material dimensions and building practices are used as benchmarks on all architectural and engineering plans. And where a custom material is required, it’s fully spec’d by the engineer before any contractor creates an estimate.

These constraints alone allow the architect to create conceptual renderings within a specific budget and a contractor to provide a cost per square foot that is accurate within a factor of one. All of these constraints also exist in manufacturing but for the sake of brevity I’ll skip explaining them here.

PANDORA’S BOX

In software, there is no building lot (or line or cell or fit/form/function product). There are no standard materials or industry standards. There are best practices. For example, HTML 5 Boilerplate or security specifications but nothing in the way of ‘every web app will have x pages with no greater than x links with…’ you get the point.

Instead, there’s a market niche that a company hopes to fill with an undetermined amount of code.

Software is software because it isn’t bound. And any boundary that exists today (hardware, language, etc.) will be broken tomorrow. There is basically no request that could be turned down because of ability. In construction there are several requests you can’t appease; the culprit gravity or otherwise. In software, there is no gravity.

In summary software cannot be planned using constraints. This is a difficult concept to swallow because it’s exactly how we plan everything.

CONSTRAINT-BASED PLANNING

Let’s run through a quick example. You have an appointment across town at a certain time. You plan your day and your departure based on the known constraints of destination, traffic and speed limits. It’s a simple algebra problem; and in many ways is perfected using various mapping and navigation apps (computers are great a math).

Now plan your trip based on a detailed picture of the destination (which you’ve never seen before). The person who’s invited you doesn’t know the address or any nearby landmarks. Suddenly you no longer can use the speed limit or the traffic conditions to plan your trip. Without constraints, this simple planning exercise that we all do everyday, becomes incredibly challenging.

This is exactly how software works. The client presents an idea (destination picture) of where they want to end up. How they get there or the specifics of what’s inside that destination are completely unknown. And more than likely, what they’re asking for is not what they want. Henry Ford said, “If I’d asked people what they wanted, they would have said a faster horse.” He was of course referring to the Model T.

Now, how much do you think that will cost and how long will it take?

THE FIRST STEP IS ADMITTING YOU HAVE A PROBLEM

This is the part of the post where I go on about my great idea to solve the issue at hand. But I don’t have a solution. I know for fact there’s a problem here and I know what the root of the problem is. The first step is admitting you have a problem and seeking out the root issue; not symptoms of it.

From my point-of-view, Agile is a symptom of a deeper issue. I could say the same about breaking the design and build portions of other industries into separate departments. Both are caused by the need of constraints to plan.

I think the solution lies in re-thinking planning and removing the need for constraints. Planning without constraints means everyone works in the same department and delivers on-time, on-budget projects.

Any ideas?

Advertisements