How many developers does it take to change a light bulb?
Don’t get blogged down. It’s uncomfortable. And probably itchy.
Instead, enter your email address below (we won’t sell it to those dodgy spammer folk. Or anyone else for that matter) and we’ll steer you through the stormy waters of new technology in the most entertaining way we can think of at the time.
You can unsubscribe at any time. And signing up is totally free.
There are two classic ways to answer that question:
1) None, it’s a hardware problem
2) The light bulb works just fine on the system in my office
But, comedy hats aside, the answer you’d expect is one, right?
One bloke with a new bulb and a ladder (which, for all of you who have read the Health and Safety Policy, has not been painted and has been recently inspected, and for which the bloke in question has received ladder awareness training!). Any more than one would be overkill.
So on the same principle, how many developers does it take to add a single, small feature to a product? Same answer. One. Surely.
That’s how we’ve been doing things so far, yes. From a development perspective, we get a requirement from a customer to build something very specific. We build exactly that, in a fixed amount of time, hand it over, take the money and the job is done… okay so I’m simplifying things a little, but you get the point! That works just fine for a project delivered to a single customer that does precisely what they asked for.
But what if you want to build a Product then? Something that will be used by, hopefully, hundreds or thousands of customers in multiple locations, and that will cater to the heterogeneity of their environment and support their unique requirements.
Surely it’s still the one developer right? It’s only a few lines of code after all…
Unfortunately not. You’re not even close. Here’s what you need:
- One developer to spend five minutes implementing the new feature.
- One developer to write unit-tests to ensure that new feature does what it should and prevent future development changes from breaking it.
- One product manager to write the specification.
- One usability expert to review the specification for accessibility and usability issues.
- At least one developer, tester and product manager to brainstorm security vulnerabilities.
- One product manager to add the security model to the specification.
- One tester to write the test plan.
- One test lead to update the test schedule.
- One tester to write the test cases and add them to the nightly automation.
- One developer to ensure that deployment scripts are not affected by the change, and if they are to update them.
- One technical writer to write the documentation.
- One technical reviewer to proofread the documentation and add it into the existing body of text, update tables of contents, indexes, etc.
- A number of translators to translate the documentation and error messages into all supported languages.
- At least one manager to co-ordinate all of this.
That’s at least 6 people, assuming some folks do multiple roles, and it’s not remotely a five minute fix… it’ll take days (what’s more, this list is a cut down version of the Microsoft list posted by Eric Lippert)
So why am I highlighting all this?
It’s to make the point that Product Development is expensive, both in terms of people and elapsed time. It takes a lot longer to develop a quality, robust, flexible and accessible product than it does to hack out a one-off system.
You have to be absolutely certain that the products you are developing are what your customers need. You have to ensure that you price your product to support the costs of building and maintaining it, and market it correctly for that price bracket.
You have to be ruthlessly efficient and cut down your feature set to the bare minimum, to ensure you focus your energies on the most important areas of functionality without getting drawn into nice-to-haves and one-offs.
But most importantly, you need a team who own the product… a bunch of smart, like-minded people, co-operating with one another to define, build, test and package that product in a manner that gives them personal pride in the outcome and smacks of quality.
It’s their work, their system, their baby, and frankly it’s awesome. It’s the best damned light-bulb ever replaced. No-one replaces light-bulbs like TSG!
TSG Research & Development Team
That is what we’re building now, in the new TSG R&D team. This year is going to see some big changes in the way we deliver software to our customers, but not in a start-up or maverick entrepreneurial VC-funded manner (although the energy will be the same).
Instead those changes will be founded on the hard-earned experience of hundreds of colleagues, working with thousands of customers across the country.
These are exciting times…