Developing First Class Software with the Developers that Google Reject

Or – why you don't need to hire heroes

Before I start, please understand that I am not trying to belittle anyone here, or infer that they are a second or third-rate developer. I personally could not make it through the Google interview process, so include myself in the category of “developers that Google reject”. (Though, I'm pretty sure I could have gotten through the interviews when fresh out of college, when all the math and computer science algorithms were fresh in my head. With that in mind, I find it no surprise that 98% of the company are under 30!)

The Software Giants have hired all the top-shelf developers

“We can only hire middle to low-end developers here at our company. Google, Microsoft, and Amazon pay more than we can, leaving the market with only second and third-rate developers. Even if we had the money, there aren't any first-rate developers around, because these software giants have sucked them up from the development pool.” This is a rough quote I heard from someone working at a software firm in the Pacific Northwest. His perception was that in his years at this firm, the quality of developers and development has been steadily falling in his company. The firm used to be able to attract high-level talent in the Pacific Northwest, but found that it now was unable to match the salaries and packages of its very wealthy software giant neighbors. I assured him that all was not lost, and in fact, the firm is in a better position than he thinks! Read on.

Teams can do things that geniuses can’t

The collective capability of a team is larger than that of a genius. Agile development is based on self-organized and self-managed teams. The synergy of a team’s collective mind and skills will give you the same, if not better, results than the genius approach, along with some other added benefits. These include:

• You don't have the “win the lottery” or “hit by a bus” scenario to worry about
• Knowledge is spread among the team, so vacation time doesn’t affect your project plan
• It is cheaper (as you are able to hire juniors and the middle-shelf developers)
• You’re less likely to have to deal with large egos (that you often find with elite devs)
• Working with a team is fun
• Recruitment is easier (as you have a larger pool to pick from)
• Teams come up with more options when problem solving, as there are many points of view

Creating a team

Are you sold? If so, you will need more than just lumping a group of devs under one project and calling them a team. That is a group, not a team. The real magic happens when this group of devs have had time to gel together and go through the forming, storming, and norming phases to become a team. To foster this, I recommend co-locating the team in a collaborative (open space) environment, and preferably near the customer that they will be working for. This team will come up with creative solutions above and beyond what a single genius developer could. OK, now we have the start of a team. Next is a process to ensure that the same results (complex algorithms) can be achieved, similar in result to a genius.

A Software process that will get you to the same point as the genius

Enter Extreme Programming (XP). The processes of simple design, TDD and merciless refactoring will return the matching results that a genius would. These practices are a repeatable and reliable way of producing code of high quality and complexity.

The genius interview process usually entails complex questions or scenarios that require a very clever algorithm to solve, and the test is to see if you can come up with the correct algorithms and approaches that they have in mind. Now, if you were to create a set of acceptance criteria and tests that would determine that the result met your requirements, then I can fairly much guarantee you that I can solve the problem. Particularly, once I understand what you are trying to achieve so I can iterate from simple through complex, and get feedback throughout. And that, my friends, is XP in a nutshell.

The Extra Perks

There are more perks that come with XP and with an Agile team approach:

• Individuals can come and go from the team throughout the process, and progress carries on regardless (though you want to minimize team changes – team persistence, pair programming, collective code ownership)
• The code is easy to read, maintain, and quick to debug (collective code ownership, coding standards)
• You will not be accruing technical debt, which would ultimately result in a legacy system (merciless refactoring, sustainable pace, automated testing)
• Minimal to no documentation is required (code as documentation, tests as documentation, refactoring tests)
• New and junior developers have a very short lead time to reach full productivity when joining an XP team (simple design, pair programming)

Summary

A persistent cross functional team practicing XP will get you high quality results and code quickly and cheaper than if you were to rely on top shelf developers only.

Cross Functional team examples

Getting a paralyzed rat to walk
The Mayo Clinic team approach
The Philosophical Breakfast Club

Update - Sep 2015

I stumbled across a similar article on Forbes - We Don't Need The Best People, We Need The Best Teams