In general, adding people to a late software project makes it later. Ramping up rapidly has been a long standing problem everywhere I have ever worked.

That said, I have come to believe that the open-source software development model seems to provide an excellent way to quickly ramp up. ... What part of open-source development?

Karl Fogel, "Producing open source software", O'Reilly 2006 describes a set of common artifacts used in many open source projects that seems to work well. ... Exactly how does this help ramp up?

When a large number of software developers are already familiar with the process, or can be trained up to the culture using Fogel's text, then a a set of common working assumptions is in place. All hands march to that drummer.

Add to that, Joel Spolsky's "12 Steps to better code" www.joelonsoftware.com/.../fog0000000043.html and there exists a basic common culture that does work.

You, Steve McConnell have written some excellent texts on how to write good code. I've read more than a few of your books.

Just exactly how do you find, qualify, hire these practitioners is problematic. Given this nation's (USA) focus on driving costs down, software developers are still looked upon as worth less than a good manager, there appears to be a growing scarcity of "better" and "best" software developers. If you are trying to hire "good" developers, you won't find much worth having. The productivity of mid level developers is what US business is willing to pay for. This is actually competitive with offshoring costs. You get what you pay for. --- Upper end "better" and "best" software developers are scarce because (duh!) they are relatively few in number. Big companies look at a "best" software developer asking for $200,000 or more per year and say, "Why should I pay that when I can hire 3 or 4 'good' developers?" ... Most employers have not yet come to terms with the concept that a "best" software developer is 10 to 100 times more productive than a "good" software developer. They just don't want to pay the price.

In the end, in the face of low compensation in the software development industry, instead of Comp Sci school, many choose BS in business undergrad and MBA in finance for grad school. The money's better.

Good luck in your search.

I heard Philip Greenspun say something interesting on the topic with respect to the company he'd run just before the bubble burst - that prior to accepting venture capital they'd been deliberate about *not growing* because, and it's his words which is why it's probably as memorable but the phrase was "we can't transmit our culture that fast."

Perhaps your question is linked to that ability to "transmit culture?"  If so it seems there are some logistical limitations on how fast that can happen that should make it a strategic decision not to scale.

In a more concrete sense there's that notion of "process" but I guess the agile "people over process" mantra has infected my thinking to a point where I've come to believe people (and collectively, "culture") trumps process.

I am living exactly this situation, we started 3.5 years ago (we are in Mexico) and 2007 was the point of inflection where we tripled our sales and we are just having our financial break even. So we grew from 5 developers in middle 2006 to a team of 30 people (including the Help Desk and IT Ops and around 22 developers).

How did we get started? With a small group of experienced (4-7 year experience) programmers, and 3 of us had worked together at another employer. The results were successful if you measure software success based on economics, but required a lot of work and sacrifices, in many aspects including technical debt, including almost no documentation (as I said there were sacrifices, some very hard to make) and a lack of processes, guidelines and checklists, all of these you can attribute it to me and to the lack of venture capital in Mexico.

Where are we now? I’m the Director of Technology and Operations, and we have a LOT of projects with customers and internal project to improve our platform, hiring people to cope with workload (our projects are very small 3-10 weeks), and with significant degradation (and halt) in the architecture of our platform after 1.5 years of hiring talented (but not experienced) people. Oh, and a lack of test that would make you cry (as I am right now). On the other (brighter side) all the team is in the same room, communicates a lot, there’s a good understanding of our business and everyone in the team is very motivated to improve.

So, what do I intent to do:

    * Keep being very very selective when hiring, because of two reasons: 1) I still don’t have a decent budget (but who does?) and 2) Graduates from universities are very far from being SW Engineers and is very rare that they become SW Engineers later.

    * Dedicate resources to document guidelines and checklists and to document the basic architecture and create a list of possible improvements. These to have some introduction for the new guys.

    * Create an evaluation and compensation system similar to Construx’s Professional Ladder to further motivate everyone to improve (and specially to start reading books!!!). Especially I intend to include not only the SWE KA’s but also the Business “KA’s” required in our company.

    * Training, training, training. IT pros with knowledge in even some “simple” concepts as Refactoring and Unit Testing (or TDD whichever you prefer) are VERY hard to find here (or at least for me) so I think it’s going to be cheaper and easier to train them. As a side note I just sent the first one to a Construx Course in February :D.

    * If budget permits, buy some (basic) tools to help us implement the previous points.

Sorry for the long post, I’d find hard to explain it shorter, probably due to my constrained English. But I would love to hear more on this topic.

The other way to go about scaling is when hiring people to put them working on different functionality/an entirely different application. The more sub teams you create and hence different applications the greater productivity of both the old and new teams because there is little to know about the existing system.

Companies like Amazon use this to build scalable systems as well as scaleable teams.

I've seen this happen before. I led a new team brought in to quickly add new features to the product. Our small team stormed, normed and formed.

Later we were integrated with the larger engineering organization. This too needed to scale and doubled in size over the next two years, building new departments like testing.

There's plenty of turnover during this time too. Later I was part of another small team to build the next generation, more storming and norming.

My perspective is that hiring is important. Engineers who can handle some chaos and distractions are important.  

The goals of the company and engineering department are important. Is the goal too scale and improve quality or push product out faster and grab market share?  Is it to build a product that's low maintenance so the rest of the business doesn't have to scale 1 to 1 with the customer base.

I say this because defining best practices and other processes may be welcomed in some cases but not others. Scaling is not the same as process maturity although I think maturity makes it easier to scale.

With all that said we found engineering silos restricting scalability. Engineers couldn't transition and features and components couldn't be extended without 20 people in the room to assess the impact.

defining design and coding best practices and code reviews helpful.  This allows the engineers to see each others code, form a common understanding of good and not good code and begin to trust each other.

This alone will improve quality. Once this happens management will trust the feedback form their engineers more. This makes it more likely that the appropriate infrastructure projects and tool sets are built to allow the product and business to scale.

cheers,

Offshore development should be viewed as a supplement to the existing team and not an answer to scale. Setting up a captive offshore unit has the same problems + more of setting up a unit where you are already located. So captive offshore units are never an answer for short term growth.

One way to scale using offshore development is to have a completely new requirement to be developed. But in order to make this work you need to have excellent processes and people to manage and control it in the initial phases. Do not expect to hand over and be delivered exactly what you want. Offshore development takes time and patience to nurture and build a team.

You can read more about my experiences in offshore development and my views on it on my blog sudeepdsouza.blogspot.com.