- Are small teams better than big teams?
- Does language matter?
- What’s the best language?
- How do we achieve quality?
- Is software art and talent driven, or is it engineering and process driven?
The list is probably longer, but you get the idea. Lately I’ve been involved in some back and forth over team sizes.
For the record, I think small talented teams crush big teams with tons
of process in terms of productivity and final results. They build
better software in less time. It’s been a good discussion, but commenters on various threads bring up issues that are important to address. Let’s see if we can’t tackle a few here.
Chris Winters’ post is a good place to start, as Chris delivers a lot of meat in a very few lines.
Don’t these small team pundits completely ingore the timeframe?
As Carmack said, “a team of 3 focused and creative
people can accomplish almost anything” — given sufficient time. But
time is the knob that many (most?) projects have little control over.
Everybody has competitors, and everything needs to get out yesterday.
This is truly Mythical Man Month territory.
You can deliver a project sooner with more than 3 developers, but I
have serious doubts about delivering a core module with more than 10.
The question is whether what you are building is amenable to being
broken down into what are essentially very separate projects.
Sometimes this is possible, more often it isn’t. To make it possible
will require some architectural investment to keep the modules
separate, and that investment is serialized into the schedule.
A much more effective knob to twiddle when it comes to time to
market is scope. Cut scope. Cut it early and cut it again if the
project is drifting off schedule. It is amazing how much scope can
really be done away with and still have a release that completely
satisfies commercial needs and makes customers happy. It is a mistake
to go for the many-year feature abundanzas that result in products like
our friends in Redmond like to ship once every 5 years.
Does “small team” include QA? People to gather requirements? People to write documentation?
Great question! First, on the issue of QA, I have never found a
point of diminishing returns, and I have had the luxury of spending a
LOT of money on QA during my Borland days. Simply put, it is extremely
difficult to find all the bugs. No matter how many we could find in a
week with a huge team of testers, a small core team of developers was
able to keep up. We started with a ratio of 1 QA per developer and
added more QA on top of that as we moved towards shipment. Those days
are probably gone, but boy did it ever help.
We got a lot of mileage over mobilizing the company and customers to
assist. We paid bug bounties to these folks based on severity of bug,
and I know of at least one case where a very talented SE paid for a
kitchen remodel with the funds. OTOH, I had friends working on
Microsoft Windows XP where much larger developer teams were involved,
and even more humongous QA teams. According to one friend, they
completely deleted the entire bug database and started over again
multiple times during the project because the developers simply
couldn’t keep up.
As a final thought on this, the number of resources you can bring to
bear outside the core developers is a function of the communication
load they put on the developers. Communicating via a bug tracking
system is pretty efficient, hence lots of QA didn’t bring down the
team. Having a doc or QA person want to camp out so the developer can
educate them is not going to scale.
Isn’t there a huge distinction between creating something and maintaining/improving it?
No, not necessarily. If your view of improving something is to
canvas the user base for every possible feature, build a giant laundry
list, and build all of that, you’re going to find it’s very daunting.
But you’re also going to find you quickly defocus the conceptual
integrity of your product and wind up with bloatware that does not make
your customers happy. The art of great software is in understanding
what’s important to the user experience versus what is merely urgent.
A small team can keep a product fresh and current for years if they’re
good at this because they don’t waste time on a load of features that
clog things up.
Exceptions? Beware the things that require tons of code yet qualify
as only 1 more feature on the checklist. Platforms are the arch
example of that. Supporting many printers and display adapters was the
old school. Supporting many databases or app servers is more recent.
It’s not worth it and it is a huge sink on resources.
Aren’t all the great small team examples tools?
Linux, Delphi, and Quattro Pro are described by Chris as “generic
tools built without regard for any specific business logic.” There are
two ways to think about this. Chris takes the path that says the
example is irrelevant because most software isn’t that way. I take the
path of saying that the example is spot on because all software should become a language if
done right. The benefit? Your small team is enormously more
productive as are your customers if you can actually make the language
something they can grasp and use. There is a reason these small teams
built languages (though I’m not sure I view Linus as a tool/language).
In fact, Quattro Pro had no less than 18 interpreters buried in the
guts. Very few of them were surfaced for end users, most were there to
make the code simpler and the product more powerful.
Do we know what we’re building?
Chris hints on another big problem when he says:
And doing all that for non-trivial businesses, with a
small team, no matter what language, is a tough job. (Not even
mentioning figuring out what it is you’re supposed to build.) In a
short amount of time? Approaching impossible.
The one thing that will sink a project faster than too many cooks
with not enough talent is poor requirements at the outset. If you
truly don’t know what you’re building, you’re doomed. You need to see
pretty clearly what it is before the first line of code is written. If
you must build a prototype to get there, consider it time and money
well spent.
By the way, creating a DSL for your domain is a way of creating a
formal specification. It takes rigor to create a language. Hand
waving won’t get you very far. Also note that a giant laundry list of
use cases and feature requests is not a specification. It’s a wish
list. You need to understand the commercial dynamics of what really
matters to customers, why it matters, and have a pretty good sketch of
how you’ll solve their problem.
Don’t kid yourself that a giant team running around gathering
requirements and hacking out use cases in monolithic modules is
building software, business or otherwise. It’s creating an
unmaintainable mess that makes nobody but the IT guys that assembled
that laundry list happy. Certainly the business uses who it lands on
are going to find it isn’t what they thought they were getting and it
is almost impossible to change it into what they wanted.
So then why do small teams grow large?
This is my own editorial, but I’m surprised it isn’t talked about
more. We’ve all seen teams start small and grow large as a product
succeeds. Why does this happen? The prevailing wisdom seems to be
that as you gain customers, their demands for new functionality
outstrip what the small team could provide. I don’t believe it. I’ve
looked at a lot of software releases, and by release 3 or 4, it’s all
too easy to get caught up delivering much sound and fury signifying
nothing. Did that release 3 or 4 really turn out that much more
functionality than 1 or 2? Was it really revolutionary? Were the
features all of the same caliber as the original?
No, I don’t think so.
Another source is failed negotiations between VP’s of Engineering
and CEO’s. Most CEO’s do not understand creating software. They come
from fields like Sales and Marketing where throwing dollars and bodies
at problems can make a difference. So they want their VP of
Engineering to do the same. They don’t want to hear the team is
running flat out and can’t produce more. They want what they want when
they want it, and they’ll write the check to make it happen. I have
not personally run afoul of this (I am stubborn about agreeing to do
something I know will fail), but I have heard of it. This is not the
big issue, though.
In my experience managing multiple release cycles for something like
50 products, team growth almost always boils down to aspirations and
career growth. People get tired of working on the same code base.
They get tired of working on the boring parts of the code base. They
want new challenges. They want career growth. They want to be
architects and managers. Who can blame them? It’s human to want these
things.
Pretty soon, a person who was a senior developer is an architect or
a manager. We carve some subsystem off and hand it over to them. Or,
we hire someone incredibly junior to be in charge of some unimportant
code that the senior guys want nothing more to do with. A fiefdom is
born and the big team is on it’s way. This is a mistake!
We are better off to create entirely new products as a path for
career development. If we can’t justify a product, or worse, can’t
justify giving a person a product, then we need to be honest about
that. You may lose the person as they seek opportunity elsewhere, but
you may also need to get some new blood into your small team.
This points up something to look for in your hiring practices.
Beware too much naked ambition among developers. The guys that push
for promotion every year can be awesome, but they will be high
maintenance, and they will try to push you into doing something that’s
bad for the team and perhaps even bad for themselves. Beware
especially the talented developer who wants to move into management
because they want to make the decisions on architecture. The
developers who are in love with the act of creation and who have great
chemistry with their coworkers are the gems. They will not push you
for much more than clear and exciting direction on where to take the
product next. Don’t exploit these guys either. Reward the heck out of
them. After all, it doesn’t take too many to work miracles. Make sure
they’re happy, whatever it takes.
Give me a few guys like that who are really good and there isn’t any
piece of software I can’t get built faster and better than the big
team. We’ll also keep that software vigorous and cutting edge for
years too, and we’ll run circles around the competition."
Source: http://smoothspan.wordpress.com/2007/11/27/why-small-software-teams-grow-large-and-other-software-development-conundrums/