Yes, it’s relative share (a smaller part of a bigger pie) but PC growth has stagnated.
Microsoft makes a significant bulk of its Windows revenue from new PC sales and business
upgrades – very few consumers actually upgrade their Windows absent a new computer.
Back in the 90’s technology moved so quickly that a computer released in 1998 had
technology not even heard of in 1996. You’d be a fool not to upgrade! Nowadays?
Not so much.
Why? Because Microsoft has no taste.
And more importantly, neither do most Windows software developers. Open up virtually
any popular Windows application and you’re presented with a really ugly interface:
Boring grids, lackluster UX and visual design, indecipherable “help wizards”.
iOS and OSX app developers have a strong design aesthetic. OSX apps look nice:
Web developers share the same design-as-a-core-competency philosophy influenced
by Apple:
And developers are on the same OSXbandwagon.
At virtually every innovative conference and meetup I attend, ranging from
JavaScript to Ruby to the Business of Software
conference, I’m met with a sea of glowing Apple logos on MacBook Airs and Pros
(or the subdued Apple logo on iPads).
Yes, if you go to a .NET conference or perhaps a big-enterprise conference, you’ll
likely see a lot more Windows machines in the audience. But the “get ‘em young”
strategy is likely to work well for Apple, as future developers starting with
OSX and Apple are significantly more likely to continue with the platform as
they enter the workforce, demanding OSX development environments or not working
at predominantly Windows shops.
Microsoft realized this years ago
but only recently has there been a flip-flop on the younger generation as
new college students prefer Mac to PC.
This is a trend that is likely to continue as long as Windows clone manufacturers
continue to underperform
against Apple. And, without the halo effect of a strong phone and tablet, Microsoft
has no hope of luring consumers back to the Windows ecosystem.
Because Microsoft has no taste neither do their developers, and so there’s nothing
in the Windows ecosystem that is desirable:
Today’s children are tomorrow’s consumers (and business owners!) and they are overwhelmingly rejecting
Microsoft’s (non-Xbox) offerings
in favor of Apple (and to a lesser extent, Android).
But what about businesses? Microsoft has long held a lock on large enterprises
that require strong controls and IT departments. Apple has a history of ignoring
this market, and there’s no evidence of this changing. However, with the “BYOD”
movement, Apple is proving to be a competent player
and Microsoft is increasing costs.
Enterprise Apple sales are outperforming Windows.
Microsoft also held a lock on the small and medium sized businesses that could
setup Windows computers, servers, and services (Exchange, MS Office, etc.).
However, SMBs are increasingly replacing expensive locally hosted solutions
with cloud based
that are cheaper, require significantly less management, and provide better
availability and performance.
The loss of developer, youth, and app mindshare is a huge blow to the Windows platform.
iOS and Android ecosystems are defined by the apps that run on their devices.
And the web is increasingly becoming the way we run applications on our bigger
desktop and laptop computers.
Microsoft has billions of dollars in revenue and is not likely to disappear any time
soon, but the era of Microsoft as a dominant consumer platform is over. Developers are moving
to the web in droves and switching to OSX (or Linux). American youth are preferring
Apple and iOS products, and small and medium sized businesses are replacing Microsoft
software with web-based apps to manage and run their business.
Software companies that don’t have design as a core, integral component to
their software design are at an ever-increasing disadvantage against
companies that do.
(Edit: Updated with a more recent image of QuickBooks.)
Facts do not cease to exist because they are ignored.
In my last post, I discussed why software effort estimation was harmful.
I mentioned that you can’t add up all the individual tasks to get a completion
date at some arbitrary point in the future, and you can’t (with some caveats)
use estimation to “staff up” a project from the beginning.
Where does this leave us? Should we not estimate at all? These folks think so:
Some folks have asked how I/we estimate. In general, I think fine-grained
estimation (hours, etc.) is a waste of time. Hours are not interchangeable
(one developer may get it done in seven hours, another in six) and don’t accurately
take into account risk.
At work, we use relative points-based estimation where
1 point = small, 2 points = medium, and 3 points = large (large stories are
almost always broken into smaller stories before development begins). We have
a guide that gives representative stories for each size point.
Initially we fill our backlog with a large number of stories, broken down into
individual deliverable units (e.g. “user can login”, “system sends email reminders”).
We take a rough estimate of size (for some reason a well-gel’ed team can agree
on relative sizes without too much difficulty) and use that for basic prioritization.
We then pull items off of the top of the backlog and work on them. As we go, if
a story feels “too big” it’s broken up into smaller tasks. In general, no one
should work on a “large” story – it should be decomposed into small and medium
sized stories.
We can use velocity and “gut feel” to continually keep the backlog stacked with
a few weeks worth of stories, ensuring that each developer has enough work to
keep them busy (Google’s “Priority Queue”).
Why Points?
Points reflect that software development is inherently a chaotic and un-knowable
endeavor, full of uncertainty and icebergs. But, this doesn’t allow us to abandon
accountability or plan for the future. We’re professionals, and we act like it.
Points lets us spend our incredibly valuable and scarce time working on what we
do best: crafting amazing software, not agonizing whether feature X will
take Y or Z “ideal hours”.
Points also reflect that a given story contains the same amount of risk or size
no matter who works on it. Switching from PostgreSQL to MongoDB represents
the same amount of risk and relative effort no matter who works on it.
Lingering Questions
There were a few questions raised in the last article that I’d like to address.
How do we know how to staff a project?
When will it be done?
How will we make internal/external commitments?
How do we know how to staff a project?
If you look at the best estimators, they have a few things in common:
Teams are fixed (no churn in developers)
They have a lot of historical data to depend on
They are often working on few, long-term projects or many projects that are very similar
These things typically only exist at large, established companies. Those that probably
operate under a waterfall-type model – minimize risk and cost. The software they
create is rarely used to disrupt entrenched markets but to claw share from competitors
– and viewed under this lens it makes sense that any given software project at
these companies generates little measurable value and so requires the most control.
(This post is not for people working at those companies, although I think given
enough prodding, you could get your management to be more flexible.)
But – if you’re asking “how many people?” then you’re removing the main support of
effective estimation – that is, fixed team composition. Historical data estimation
only works if you have the same people working on the future project. Otherwise,
the estimates are significantly less valuable, especially in the short run as teams
of new people fight to “gel”
(and don’t forget the mythical 10x developer).
More interestingly, though, is that each additional programmer past a certain
number gives diminishing returns. This is something (generally) not accounted
for in historical data. You can’t take the performance of a four person team
and multiply it by ten to achieve the performance of a forty person team.
If you have n-number of “programmer months” you also can’t simply throw a large
number of developers at the project to get it done “faster” (also known as schedule compression).
The larger the team, the less schedule compression you achieve, and the greater
diseconomies of scale.
It sounds surprising at first, but intuition should help. If it took five people
a year to work on a project, would it take ten to finish in six months? Maybe,
but that seems doubtful. Not everything on a software project can be worked in
parallel. Gut intuition tells you that it should be done later than 6 months.
What about twenty people. Could you get it done in three months? That seems a lot less
likely. What about forty people? Could forty programmers get it done in a month
and a half? Absolutely not.
So what might account for these results? Over three decades of data from the QSM database suggest that defect creation and density are highly correlated with the number of people (and hence communication paths) present on a given project. Larger teams create more defects, which in turn beget additional rework. Fixed code must be retested and the team may find new defects injected during rework. These unplanned find/fix/retest cycles take additional time, drive up cost, and cancel out any schedule compression achieved by larger teams earlier in the lifecycle.
Conclusion: Minimize team size. The “optimal” size of teams is relatively
fixed (less than five developers).
“How many developers should we have on this project?” is the wrong question to ask.
“How can we subdivide the project into 2-4 person teams” is the right question,
and planning can help with that. I’ve never had estimation be a high-order
term in the equation, though. Generally putting a list of all of the different
features broken into small chunks, organized by rough size (Small, Medium,
Large) seems to work just fine.
I think a key point of this is on larger software projects, you must subdivide
the work into separate components that don’t rely on shared state, etc. between them.
This means your different components will act via message passing and an API.
Steve Yegge’s infamous “API ALL THE THINGS”
post is a good example. It’s not an exact fit, but if you squint a bit and cross
your eyes so you can see through the picture, you get an idea of what I mean.
When will it be done?
What does “done” mean? There’s always a feature you can add. Always some
refactoring or improvements to make. “Done” is just an arbitrary pile of
features that are “good enough” to be shipped.
Tower of Babel
What seems to happen most often is that over time, software never gets “done”
because developers don’t have a clear “done” criteria. This leads to software
built very wide (lots of features) but not very deep (not fully “done”),
leading to the age-old “90/90” rule.
Even if a feature has well-defined “done-ness” estimation has a strong
anchoring effect that encourages “90%”
done features. If you estimate a feature to be eight hours but it really takes
twenty to be “done”, in most companies you’ll receive pressure to compromise
on quality or take shortcuts because you’re “taking too much time”.
Absent external pressure, I’ve often seen developers put too much emphasis on
the initial estimate – even if there’s no manager breathing down their neck,
the selfsame developer will feel guilty that they are taking “too long”.
Conclusion: Features should be fully “done” before moving on to other features.
Avoid anchoring effect and be willing to invest the appropriate time to release
high-quality code.
How will we make internal/external commitments?
The creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line. ref
This is a hard problem. I argue that building software is a lot closer to writing
poetry than building a bridge. Ask a poet how long until the sonnet is written
and you’ll get a blank stare.
Unless you’re building something very similar to something you’ve done before,
you’re fundamentally creating something that has never existed before. Even
the most “scientific” estimates contain a large chunk of
risk (or “unknown unknowns”) that cannot
be quantified ahead of time.
If you must make a commitment to a random date in the future and scope is
fixed, you’re almost always screwed. Agile development helps avoid this by
encouraging (requiring?) incremental development. Start working on the most important
features first; aim for always shippable/deployable software by keeping the
features small.
In this manner, you’ll always have working, testable software and will be moving
towards the goal. Your customer/stakeholder will see the progress (or lack thereof)
instantly, and be able to re-prioritize as necessary. Since you’ve got shippable
software at every point in the game, Marketing and Sales can accurately inform
customers on what’s going to be in the next release in a “just-in-time” fashion.
Many softwarecompanies have been
abandoning announcing arbitrary dates for their latest products and
announcing at conferences and tradeshows because it’s
too restrictive and places their development on someone else’s timeline.
When Apple does a product announcement, the software has been in a feature freeze
for months, and the hardware inventory has already been piling up. They don’t
release handwavy dates “sometime next year” because they give a date
once they’re already finished (iOS betas are more or less feature complete:
Apple spends a long time polishing and fixing bugs, but no major features are
usually released once the betas are released to the public.)
And, the functionality that is delivered is not promised ahead of time. I suspect
Apple has a high level roadmap and works on the most important features first
and cuts anything that isn’t ready or good enough.
If Microsoft and Apple can’t predict the future, what chance do you have?
Conclusion: Work on the most valuable features first in an iterative fashion.
Always be delivering working software.
How to be Successful With Minimal Estimating – Build Small Software
Many small things make a big thing.
Since team productivity is maximized with smaller team size, effort is fixed,
and software is inherently unpredictable, this leads to an interesting conclusion:
don’t build big software projects.
Large software projects are cost/productivity inefficient. Large software
projects contain a large amount of risk that cannot be determined a priori.
Large software projects fail more often
than smaller ones.
Use rough approximations of feature size for high-level planning and guidance
Use small teams to build small software
Deliver frequently, working on the highest-value features first
API all the things to enable different teams to integrate via a standardized API
Delta Air Lines tells me it will take two hours and twenty-five minutes
to fly from New York City to Atlanta, GA. American says two thirty. United?
Two thirty-four. Yet, the captain just told me it was “one-hour forty-five” minutes
“wheels-up to wheels-down”. What gives?
It turns out that the US Department of Transportation (US DOT) rates the airlines
by “on-time performance”: whether or not the aircraft reaches the gate by the quoted
time. So, like any rational actors, the airlines pad the flight time to account
for ground delays (waiting by the gate for the tug driver to appear),
re-routes due to bad weather, etc. – but also to goose the ratings.
They could massively pad and say the flight takes three hours, but that impacts
the ability for folks to connect to other flights. Airlines constantly tweak
the advertised flight time: too much padding and the wasted time on the ground
costs dearly; too little and the DOT will come after you.
Software
Software developers are often called upon to estimate various tasks, features,
or bugs. Oftentimes this is measured in hours, but for larger stories it could
be days or weeks (month-long estimates don’t seem to be as common).
These estimates are used to estimate the effort for a given task and, in the hands
of a business user/project manager, added up to get the completion date for
the project as a whole (e.g. feature X takes 2 weeks, feature Y takes 3,
X + Y = 5 weeks to launch). This completion date is then used in a formula to
calculate total project cost (salary per day * days, or equivalent).
In really terrible places to work, someone other than the developer will
actually do the estimating. This estimate will then be given to the developer
as an implicit (or at especially evil places, explicit) time not to exceed.
This is such a depressing situation I cannot dare think of it further.
Estimation Process
The estimation process itself is not very well defined at many software companies.
Often the developer will try and compare feature X to a known feature they have
completed in the past. For example, “Create login form” may have taken them four
hours on a previous project, so they can reasonably estimate likewise for a login
form on a new project. Or, “Add a customer” seems a little bit harder than a login
form, so multiply the login form estimate by 1.5x to get 6 hours.
It gets a lot trickier for larger features, like “Customer Analytics”. What does
“Customer Analytics” mean? Hopefully the developer has been given a specifications
document from a business analyst (or equivalent) that spells out all of the requirements:
Bar chart of Customers over time (group by signup date)
Ability to change scale (view week, month, year)
Exclude inactive Customers
etc.
In this case, the smart developer would decompose the feature into smaller
features that can be compared to past experiences. The dumb developer would try
and estimate the feature as a whole. Bad, naughty developer!
Missing Data
Most estimation is drawn from past experience. What if the developer doesn’t have
this experience? How can they estimate? This is where things get tricky. And by
tricky, I mean “completely made up.” Sure, for things that have been done before
by someone the developer can draw some parallels and make a guesstimate. But
what about the stuff that has never been done before (presumably, the secret-sauce
that makes you money)? Usually you just take a Wild-Ass Guess (WAG-estimation)
and hope you’re not wrong. Given the rarity of being punished for
under-promising and over-delivering this WAG tends to be a massive over-estimation.
Effort vs. Accuracy
It seems obvious that the more time you spend on your estimates, the more likely
you are to “get it right.” Right? This thesis is basically the entire justification
for the Waterfall model of
software development.
Completely spec out the entire system ahead of time, spend a lot of time researching
and estimating the problem, determine project dependencies, and you can determine
the “finish date” before writing a line of code! It’s seductive and taps into
the part of our brain that craves order and dependability.
Pretty little stories all in a row
It turns out that effort spent estimating only provides marginal returns and,
eventually, becomes negative. Why? Because of overfitting.
In machine learning, overfitting generally results from having too little training data
(edited: incorrect usage of test data)
or focusing on irrelevant metrics. The costing algorithm you evolve into can only
accurately predict your training data. When fed a new problem the algorithm
provides widely variable or incorrect information.
Human estimation algorithms fall into the same trap – the more you try and dig
into a problem, the more you see parallels that don’t exist and the less you
account for randomness (or “unknown unknowns”). You end up being very confident
in your estimation but ultimately are wildly wrong.
“Agile Estimation and Planning” Addison-Wesley
Why Estimate?
Let’s back up a bit. Earlier I wrote that folks estimate in order to determine
the completion date for the project as a whole.
And? What’s the point of knowing when the entire project will be complete? Who
cares? Typical answers are:
So we know whether or not to undertake the task
So we know how many developers to put on the problem
So we don’t overspend
So they can generate a ship date for marketing/PR reasons
But I think the deeper, much-less admitted reason is that managers and other
“business people” don’t do a particularly good job of calculating business value,
motivating, and managing software people and projects. They wield the estimate
as a cudgel: perform X by Y date or else.
“You can’t control what you can’t measure.” This line contains a real truth, but I’ve become increasingly uncomfortable with my use of it. Implicit in the quote (and indeed in the book’s title) is that control is an important aspect, maybe the most important, of any software project. But it isn’t.
My early metrics book […] played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.
The tl;dr of his article is that the software projects that require tight cost control are the ones delivering little or no marginal value. That is,
To understand control’s real role, you need to distinguish between two drastically different kinds of projects:
* Project A will eventually cost about a million dollars and produce value of around $1.1 million. * Project B will eventually cost about a million dollars and produce value of more than $50 million.
What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects. It suggests that the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value.
To my mind, the question that’s much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value?
If the value of software we’re writing is so low, is it worth being written? If
the project has such tight time constraints that a schedule slip will doom the
project then you’re in a world of hurt. (The solution is agile: work on the most
important things first, have an always-working project, and cut scope to hit
a date.)
This exposes a major weakness in most software companies: the inability to determine
project value. Given a project of unknown value, the conservative business will
then attempt to minimize cost. Unfortunately as we’ll see, cost minimization ends
up becoming very expensive in the long run.
Hierarchy as a Service
Most companies are incredibly hierarchical – programmers report to a tech lead
who reports (tangentially, to a project manager) to a mid-manager who has one
or two layers in-between them and the CIO/CTO/CEO. The further up the stack the
greater the nosebleed: the lack of visibility of the day-to-day machinations of
the software organization and the less concrete decision making (aka vision over
strategy/tactics).
This results in senior/mid tier managers that don’t know much about how software
actually gets written. Given the perverse cost-minimization (because they didn’t
do their job) organizations go to great lengths (of both time and money) to
keep projects under tight control:
They require big up front design before any code is worked on
They require sign-offs and constant oversight
Anything that isn’t directly driving completion of a task is forbidden (or at least, implicitly disincentivized)
What does this do? It encourages waste via Parkinson’s Law.
It discourages refactoring when software entropy becomes unmanageable. Ultimately,
estimation ensures software projects underachieve. By strictly managing
cost, an organization guarantees the value is strictly limited.
(I’m not entirely sure what this means, but I’ve never seen the folks who are
writting the specs, requirements, etc. ever being asked to estimate how long
each spec will take to write. Or have the CEO give a date when the company will
hit some arbitrary metric, although see the perversity in public company
earnings estimates and reporting.)
Trust me, I’m Lying
Ultimately companies require estimation because they
don’t trust anyone. They
don’t trust developers to deliver results. They don’t trust mid-management to
motivate their reports. The underlying reality is that the folks “in charge”
are worried that everyone is going to rip off the company and only by holding
people to arbitrary deadlines are they assured stuff will get done.
Committing to a date allows them to sleep better at night and shifts the blame
from them to the folks on the front lines. And this is wrong, both morally and
from a pure technical perspective. (See: Results Only Work Environment
for how to manage based on results.)
Estimation considered harmful
Estimation is ultimately a futile effort. Software, more or less, is like writing
poetry. Or solving mathematical proofs. It takes as long as it takes, and it’s
done when it’s done. Perfect, or imperfect, estimation won’t change how long it
takes to complete the work. If that sounds horrible to you, then go do something else.
Even if we could completely accurately estimate all of the pieces,
software of any complexity has interdependencies and “unknown unknowns” that
tend to not surface until implementation time. You can’t know the end date
a priori by simply adding up all the components.
Estimation actually slows down development because estimation isn’t free.
The developer is incentivised to take as long as possible estimating in an effort
to not get beaten when they miss the estimate. Why waste that time when the metric
the developer is attempting to hit ultimately generates negative value?
(In Peopleware they discovered that projects where no estimation was done
had the highest average productivity; any estimation lowered productivity no
matter who performed the estimation.)
Software is not like bricklaying –
you can’t speed it up without major consequences. The Mythical Man-Month
teaches us that adding developers to a late project will only make it later
due to exponential communication and ramp-up (coined “Brook’s Law”).
This results in folks that think adding more developers to a project at the beginning
will allow them to hit an arbitrary date by spreading out the workload. Unfortunately
new software doesn’t work this way, either, as the same exponential communication
overhead occurs in the beginning, too. You merely end up with a giant mass of
incoherent code. And you waste a lot of money employing people who don’t add
much value, sitting on the bench waiting for their part of the project to begin.
The solution is “Don’t build big software”, which I’ll cover in a future post.
Two Points for Honesty
Estimation isn’t all bad, though. The act of estimating forces you to consider
the problem domain in some detail. As Winston Churchill said, “Failure to plan
is planning to fail.”
This is why I espouse the agile activity of relative points-based estimation.
Regardless of which point system you use (linear, exponential, etc.) group-based
estimation helps the entire team arrive at a shared understanding of what
each feature/story/etc. is supposed to do. This is critical to keeping a high
bus factor.
The key point is that these estimates are never, ever used to try and pinpoint
a “ship date” (you should be using continuous deployment anyway) or used to
punish a developer for “taking too long”.
The estimation process should take place relatively quickly. Break stories up
into trivial tasks (which by definition don’t need estimating) and then roughly
estimate the risk posed by other stories (external integrations, hard machine
learning problems, etc.). In all, this process shouldn’t take very long.
This ensures minimal estimation waste, keeps developers happy, and velocity high.
That’s a very good question. I have a huge man-crush on Joel.
Probably so much that if I saw him in person I’d babble like a child and be
basically incoherent. He’s done more to advance the state of programmer
work environments and software development than anyone I can think of in recent history.
Joel doesn’t strike me as the kind of guy who would use hourly estimates to
punish developers. So, I think it comes from a good place, and not the deep-dark
evil place that most estimation requirements come from. But, when it comes to
EBS, I’m not sure it really provides that much value relative to the overhead
vs. relative points-based.
It’s really close to what agile points give, namely a burndown chart, except
you’ve got all the overhead of keeping track of exactly how long it takes to finish
(I admit that I may be overestimating the time it takes to manage this reporting.)
Building safety-critical software is necessarily out of
scope, as that is a completely different animal. I’ve never built space shuttle
software or something that could easily kill someone so the suitability of this
technique is undefined.
Some folks have asked how I/we estimate. In general, I think fine-grained
estimation (hours, etc.) is a waste of time. Hours are not interchangeable
(one developer may get it done in seven hours, another in six) and don’t accurately
take into account risk.
