There are a number of common-sense software development practices that can actually hurt your chances of success.

Here are 5 common-sense items you might want to avoid:

1) Treat Team Members the Same

It’s common practice and it makes sense. It’s fair, right? Treat everyone the same. What could be wrong with that?

The origins of the “fairness” practice may come from early childhood when kids discover crying “no fair!” is a great tactic for getting what they want, or maybe it has something to do with the golden rule of “treating thy neighbor as thyself.”

But in practice, we usually do treat our neighbors differently. Some neighbors we hang out with, invite to our houses and party with into the wii hours of the night. Other neighbors we avoid like the plague. So why do we force ourselves to treat all team members the same?

Some team members contribute immensely to the success of the project; they are self motivated, get their work done on-time and get along with everyone. Others, we can hardly count on, they consistently miss self-projected deadlines, they are sick a lot (in the Bahamas) and frequently complain about others.

Why should these two personalities be treated or rewarded similarly? Doing so only reinforces the negative behavior and increases the risk of losing the preferred team member. You have limited resources, both in time and reward-money. If you spread them equally among the team, it’s a disservice to your organization.

You can count on your best team members recognizing that and not tolerating it for long.

2) Follow Established Procedures or Processes

Procedures and processes are there for a reason: to avoid mistakes and to identify the people who make mistakes. Following the rules only makes sense. Avoiding mistakes is a good thing.

Well it might be a good thing, until your best team members start to feel as though their hands are tied behind their backs and if it wasn’t for some stupid process, they would be able to get a task done in 1/10th the time.

Avoiding mistakes is a good thing, but at what cost? Software engineers are essentially problem solvers. That’s what they do all day. The best of them enjoy and derive fulfillment from solving problems with the least amount of effort (both personal effort and computing resources). They are by nature very intelligent people. Every developer on the team probably possesses well-above-average intelligence. They will find ways to solve problems, but if they are bound by some arbitrary rules that prohibit them from deviating from standard procedures and processes, their productivity (and creativity) is limited.

This isn’t to say teams should avoid processes all together. But as a team, there are two ways to view processes: one is to view them as the laws of the land which should be followed at all times and the other is to view them as a set of recommended guidelines that seem to work well, but feel free to deviate as you see fit. The latter is far more productive for intelligent people.

To invoke another biblical adage: The process is created for the team, not the team for the process.

3) Create a Detailed Design Before Starting Development

Seems like a great idea. A detailed design is like a step-by-step instruction list on how to get the job done. Having a detailed design makes the programmer’s job much easier. Nearly brainless. If X is the input, Y is the output. Don’t think about whether or not it makes sense. Just do it.

With detailed designs, you nearly guarantee an increase in productivity and you nearly guarantee a result that’s mediocre at best. Without the ability to refine and adapt a solution as the work is being performed, you eliminate hundreds of branches of potential evolution, which could have made the result that much better.

But having evolutionary branches of a potentially better solution scares a lot of project managers. What if the branches are never-ending and the solutions never get done? That’s a real possibility if the project manager doesn’t do his job well, because a huge part of that job is to help guide the evolution to an outstanding result.

Plus the up-front savings of avoiding a detailed design and opting instead for rough design guidelines will often produce better solutions in less time.

4) Make it Difficult to Change Requirements Mid-way

Project managers are all about delivering their projects on-time and on-budget. The number one risk-factor for delivering a project on-time is a change of requirements.

And, that’s why we have change committees involving numerous people from different departments whose job it is to approve any changes to the established project scope. They analyze the impacts of a change on the project schedule and the budget, often inflating both to increase the likelihood of rejection or at least provide some padding in case the change is approved.

The results are predictable. Changes are nearly always killed by the change committee. Who in their right mind would approve a change that increases the cost of the project and delays the delivery date?

Here’s the big problem with killing nearly all changes: some change is good and by making changes difficult in general, too many changes are killed. It’s a chemotherapy approach of dealing with change…kill nearly everything and hope that the few surviving cells happen to be the ones you wanted to keep in the first place.

That’s definitely one way to do it. But, development teams that employ a democratically-run change committee (1 person, 1 vote) will never create outstanding products. Ideally, changes should be reviewed by teams of 3-4 people, with 1 person having the ultimate say, after considering the input of the committee.

5) Assign Tasks Based on Resource Availability

Gantt charts are a project manager’s best friend as they allow the project manager to view the entirety of the project in a visual representation with dependencies and they can even provide resource assignments. But one of the drawbacks of the Gantt chart (such as Microsoft Project) is that project managers are encouraged to simply assign tasks based on resource optimization and leveling features.

The problem with this should be obvious: important tasks are often randomly assigned to team members based on their availability rather than their skill sets. This is a huge mistake!

Another one of the project manager’s major roles is determining the strengths and weaknesses of each team member and assigning tasks based on this information. Assigning critical or show-stopper tasks to a weak team member is a recipe for disaster. Likewise, assigning trivial tasks to your most talented team members is a waste of your best resources (not to mention a risk of decreasing job satisfaction for those team members).

No Gantt chart is going to identify this information for you. That’s your value-add to the team.

Hopefully by avoiding these common(-sense) mistakes, you can improve your development success. Remember, a lot of the above hinges on the quality of your team, which I wrote about previously. I’d love to hear your thoughts on the above suggestions. Leave a comment if you agree or disagree with some reasons or examples why.

For those who love to build stuff, there’s no better feeling than introducing a new product into the world.

On Friday, Axosoft released a new commercial application: PureChat V1.0. PureChat is a simple web-based application that allows an ASP.NET web site operator and a visitor to chat with each other. Since this blog is about shipping software, I thought it might be interesting to talk about how this product came to be.

As Jonas explains in his blog post about PureChat, the project was born from a side-project that he worked on after the last major release of OnTime. In What’s the Developer’s Incentive to Ship, I explain how having side projects at Axosoft is an extremely motivating tool for all of us. It gives everybody a chance to breathe and learn new things. But more importantly, it’s a great way to actually keep everyone focused on shipping our main product. Once OnTime 2008 was out the door, the side projects (could get) started.

This time around, each developer decided to work independently on different projects. As I said, what came to be known as PureChat was started by one of our software engineers, Jonas. He was the sole programmer on a project he chose in order to test out a couple of ideas around a chat tool using AJAX. After he showed the initial idea to a few of us internally, we became excited about the prospect of using it for our own web site.

There are dozens of such chat tools out there, but most are hosted-only solutions and are generally a little too complicated in the wrong ways and not complicated enough in the right ways. We thought there was still a good opportunity here to make something that was extremely simple to use, while  effectively allowing web site visitors and web site operators to communicate.

So a few of us jumped into Jonas’ project, improved the UI and adding dozens of new requirements. Everything from the exact size of the client window to the color and appearance of every chat conversation was carefully scrutinized. We wanted to make sure all of the product’s features were easily discoverable and didn’t require explanation.

What started out as a technical AJAX and Javascript learning project with some ASP.NET back-end quickly became a design exercise for the most effective user interface. All the focus and effort was put into making the user interface on both the client and the operator sides as clean and intuitive as possible.

Considering the project went from conception to final release in less than 60 days, the result is absolutely amazing. I’ll let the product speak for itself, and  also point out that it truly speaks volumes for how important it is to have an amazing team and to give them the freedom and motivation to innovate. To let the product market itself, we’ve made PureChat free for single-operator installations.

So go ahead. Try it and out and see what you think.

There is a lot of debate these days about whether or not the technology behind a product matters. Does it matter whether you choose C# or Java as your programming language? Does it matter if it’s on Windows or Linux? Does it matter if it’s MS SQL or MySQL?

The conventional wisdom is to view this issue from an end-user’s perspective. To the end user, the technology doesn’t matter. It’s the product that’s important. If the product is good, the users don’t care if it’s written in Java, C# or Cobol. They just want something that solves their problem.

But a lot of software companies and IT shops are using this argument to imply that the technology they choose for development makes no difference. Who cares if they choose Perl or Ruby or C#? After all, the end users don’t care, so why should it matter to them?

The fact is, choosing the right technology matters more than most people think and could be the difference between shipping a great product and creating vaporware. Today, it would be comical if an IT shop chose Cobol as their development language or banked on FoxPro as their database backend for new projects. If the technology didn’t matter, these should be sound choices, but it’s obvious to most in the software business that banking on these particular technologies would have disastrous results. So the question is why? Why does choosing the right technology matter?

There are a number of reasons:

1. Attracting the Right Talent - By far the most important aspect of choosing the right technology is making sure you can attract the talent that can get the job done. If the best brains in the world, the ones that can get jobs anywhere, avoid your project because of the technologies you have chosen, you’ll be left with second tier software engineers who are forced to accept a position purely for financial reasons. As tough as is to find truly talented people in the US job market today, you want every advantage you can get. So, choose the technology that will attract the best possible talent.
2. Time to Code - The amount of time it takes to write a solution to a problem plays a huge factor in choosing the right technology. If you plan to write a program that will be used in the 2008 Super Bowl on February 3rd and you are starting to write code now, you better choose technologies that can provide huge shortcuts in writing the code. Delivering a solution on February 4th, no matter how good, is completely worthless. On the other hand, if you are choosing shorter coding time when time to market is not an exceptionally important factor, you may be picking a technology that does not scale well as the application grows in popularity.
3. Execution Speed - As computers get faster, there’s less and less concern with the execution speed and hardly any thought is given to which technology should be chosen based on this criteria. But talk to any serious game developer and they’ll set you straight about the importance of execution speed of their code and why this factor alone has kept them one generation behind on the latest language developments. When C became popular, game developers were still doing assembly. When C++ was big, they finally made the switch to C and while C# and Java have taken over, games are still largely written in C++. The reason? Execution speed.
4. Code Maintenance - Choosing the right technology from the standpoint of code maintenance can mean the difference between longevity and M.C. Hammer. If the code cannot be easily maintained, enhanced and expanded, it will collapse under its own weight.
5. Future Support - Will it be around in the future? This is a tougher question to answer, but if the future support of a technology is largely in question, it might be smart to avoid it. If a technology does not hit the mainstream, it will be harder to find talent and there will be a lack of state-of-the-art development tools, affecting time to code and execution speed. Choosing popular technologies that are well supported by the industry and profitable companies can be an easy way to avoid future pitfalls.

Although the casual gamer enjoying a video game couldn’t care less if the game he’s playing was written in C++ or Python, the success of the game largely depended on the chosen technology. That’s why you’ll find larger more sophisticated IT organizations care a great deal about the underlying technology of the products they choose. They want to make sure the future viability of the products and companies they choose are sound.

At Axosoft, our choice to adopt Microsoft .NET and SQL Server as the technologies of choice has given us a significant competitive advantage providing us an edge in each of the 5 categories mentioned above. From attracting the right talent (developers often leave their jobs just to use newer, more exciting technologies) to shorter time to code to execution speed, code maintenance and future support. In each of these categories, .NET provided Axosoft with a significant competitive advantage allowing us to grow faster and provide a more solid product.

Recently, I got a link to The Story of Stuff by Annie Leonard. This is an amazingly well done 20-minute video about how stuff is made, sold and disposed. She does a phenomenal job of putting the Story of Stuff together and selling the viewer on the importance of being Green. If you only have 20 minutes, I’d rather you watch her video than read this article, so go do that if you haven’t already.

Then I got to thinking, as software engineers, what’s our responsibility for being green? I did a couple of searches and ended up with nothing. The general view appears to be that software developers are automatically green. After all, how could software not be green? It’s just a bunch of bits, right? Software hardly has an environmental impact, or so is the consensus.  Can software be any more green than it already is?

As I thought more about the subject, I realized that in fact there is a huge variance in software greenliness (new word?).  The notion of green has always existed in software development under a different name: “Simple!”  Yes, simple, is the word we have used to describe the most green software in our industry and some of the most successful software products of all time have been the greenest solutions. I’ll get to some examples in a minute.

But software developers don’t think in terms of developing green software.  On the contrary.  Because we assume all of our solutions are by default green, we end up doing things that have a huge negative environmental impact without realizing it.  As software engineers we rely heavily on a few fundamentals to help us determine the best possible solution:

• Moore’s Law - By far, the most influential theory on software development for more than 4 decades has been Moore’s Law. Not truly a law of nature or science in the traditional sense, Moore’s Law was simply an observation based on the historical trend of integrated circuits approximately doubling their number of transistors every couple of years. Faster, cheaper and smaller computers being just around the corner has been the most perfect argument for writing slower, bloated and more expensive software for millions of developers over the years. I confess, I have been one of them.
• Cost of Development - As software engineers we are taught to do cost analysis in the following way:

- Algorithm X takes 1 month to develop and takes 1 minute to finish its calculations
- Algorithm Y takes 2 months to develop and takes 30 seconds to finish its calculations
- The resulting algorithm will be run thousands of times every day, enough to keep at least one or two servers extremely busy.
- Which algorithm should we choose?

We would do a quick cost analysis and conclude that 1 man-month of a developer’s time (in the US) costs at least 2 or 3 times more than an additional server. It would be hard to argue for choosing Algorithm Y when the up-front hard costs are 2 to 3 times as much as Algorithm X.  So the slower, less green, Algorithm X wins.

• Laziness - As software engineers, we hate solving the same problem over and over again, so we build libraries of code and reuse other libraries as much as possible. This is generally great and very green! But, increasingly, we rely on 3rd party components that are thousands of times larger than the portions we actually want to use. As a result, we ship a product that requires ten times or a hundred times more disk space and memory than if the product was developed completely in-house. Of course, developing completely in-house could mean you’ll never finish the product and is not practical, but like everything else in life, there’s probably a good balance that can be maintained that makes sense for the project.

We are taught these things in school and at work. Being efficient from an economical standpoint, not a coding one, is the most important rule. Laziness and not reinventing the wheel at all costs is a trademark of a software engineer’s mentality and we can always rely on Moore’s Law to automatically solve our coding problems within a couple of years. By following the traditional wisdom, software engineers can save a little on development time, but very directly we are forcing the rapid adoption of newer, faster PCs with more memory and disk space.

We, as software engineers, are the number one marketers of hardware. We help PC manufacturers sell hundreds of millions of PCs every year just so users can run our software at a reasonable speed. That’s why when the ship-date of a product like Windows slips, stock analysts lower the estimated sales of Dell and HP. But it’s not just Windows that helps sell hardware - Windows just happens to have the most impact because it’s the world’s most popular software application. The new Windows Vista Flip 3D feature that allows you to switch between apps will probably be responsible for the sale of millions of new machines because of how painfully slow it runs on older systems.  This new feature of Vista is by far the most Visible - it’s even in the Vista commercials - so it will be the first thing that any new Vista user will want to try.  When they realize it doesn’t run on their machine, it’s time for an upgrade.

So as software creators, we are largely responsible for the adoption of new hardware. The smallest things that we do can make a big difference. We can’t simply wash our hands free of the environmental responsibility and put the blame on the hardware guys. Sure they want to sell more hardware, but we’re essentially their free sales force.

Rules for Writing Greener Code

I propose a set of software development guidelines for developing greener solutions:

1. Choose Faster Code over Future Hardware. Yes, if you wait 2 years and run your code on a future device, it will run twice as fast as it runs today, but that’s exactly the wrong attitude. To be a green developer, don’t use the fastest machine you can find as your acceptable performance benchmarking system. Instead, use a machine from 2 or 4 years ago with less memory, slower CPU and smaller hard drive. If it can run on that machine with acceptable performance, your contribution to the rapid replacement of hardware is significantly less.
2. Include Environmental Costs in Your Cost Analysis. You might find that writing slower code and buying more servers costs a lot less than the cost of another month of development, but don’t forget the hidden costs of more servers. These days the data center electricity alone that a server uses in a given year can cost as much or more than the server itself, not to mention rack costs, cooling costs, bandwidth costs, software costs and the environmental impact of all the materials and manufacturing processes that goes into creating the server itself.
3. Be Memory Conscious. With most developer machines having 2 or 4GB of memory these days, developers often forget that there are hundreds of millions of PCs out there with just 256MB of memory (or less!). Even 256MB is an unbelievable amount of RAM. I couldn’t imagine having that much memory on a computer at the start of this decade and now I have 2GB! It’s because developers use memory as if it was free. The argument is that memory doesn’t cost anything. You can pickup 1GB sticks for under $100! The problem is for a large number of machines that are not capable of having 1GB of memory, you need to replace the entire machine and guess what happens to the old machine?
4. Build in-house When Possible. Using 3rd party components and external controls can be a great way to save time in the development of an application, but make sure you’re not using 100MB worth of components for 1MB of gain. If the ratio of things you use in your 3rd party controls to things you don’t use is 1:100, that’s bad. It’s not just bad for the environment; it’s even bad for your end-user experience.
5. Go Back and Solve it Again. Every developer knows at least a dozen areas of their software that they could have coded more efficiently. Often the performance of re-solving critical areas can gain an order of magnitude in performance improvements. But we never go back to do it again because we’re busy adding the next new feature. Going back and solving problems we have already solved might seem like a waste of time, but it’s often very satisfying to cut down hundreds of lines of code to just a few lines and make it much much faster.

How Coding Green Translates to Shipping Great Software

So you might be asking yourself how do these rules relate to Shipping Great Software OnTime? To answer that question, let’s take a look at some of the characteristics of green software:

• Simple - The more Green a software application is, the simpler it is. So if two products can solve the same problem equally well, the greener solution will generally win. Examples include Google Search beating Alta Vista. Gmail beating Hotmail and Yahoo Mail. Flickr beating virtually all other photo sites at the time. The trend is clear.
• Fast - Greener software is going to execute faster and as a result enjoy faster adoption. Again, given the choice of two products that solve the same problem equally well, the one that executes faster will win. A great example here is the rapid and surprising adoption of FireFox. Although it still has not beat IE (a product that ships with the OS, giving it a significant marketing advantage), the adoption of FireFox has been a phenomenal and surprising success. Between IE and FireFox, clearly, FireFox is the greener tool which runs faster and consumes significantly less resources. When you ask a FF user why he or she switched, the number one reason is that FF is much faster.
• Lower Resource Usage - Greener software takes less system resources to execute. Again, given the choice of two products that solve the same problem equally well, the one that requires less resources will be preferable. Although FireFox can be used as an example again, I’m going to use the example of Apple’s OS X. As far as operating systems go, OS X is definitely greener than Windows. The latest version of Apple’s OS X Leopard runs well even on a PowerPC G4. That’s a chip that’s about 4 generations behind today’s latest CPUs. That would be the equivalent of getting Windows Vista to run on a Pentium 3. When you ask recent “switchers” from the Windows platform to OS X why they switched, a recurring theme is that OS X is faster, more reliable, it’s not as choppy and things just work. Lower resource usage is a significant advantage of OS X in this case and you sure don’t see a lot of people switching the other way to ask why they switched.

I suspect that some of you might want to ask me “then why didn’t DOS beat Windows? DOS is clearly the greener OS.” The answer is that the solution has to solve the problem “equally well.” DOS, although greener than Windows, was also single-threaded and provided an awful text-based interface. It was not intuitive to the average user and was limiting in hundreds of other ways. So DOS did not provide an equally good solution to the OS problem.

Writing greener software could be a significant competitive advantage, and as a byproduct, it could be better for the environment. It seems to me like a big win all-around.

The company always has a substantial incentive to ship. Usually, it’s financial. If you don’t ship the software, you can’t sell it. If it’s an internally used tool or a line of business application, then the company’s incentive to ship is to increase user productivity (again a financial incentive). To the company, shipping the software affects the bottom line and the incentive to ship is clear.

But what’s the incentive to ship for the software developers? Those are the guys that control the real ship date.  In nearly every company I have ever seen, there is virtually no incentive to ship for the developers. In fact, in most companies, developers have an incentive not to ship! Sure, you can argue all you want that if they don’t ship, they risk the chance of losing their jobs as the company might suffer layoffs. Theoretically, improving your company’s financial well-being so you can keep your job should be a big incentive.

But Windows Vista didn’t ship for 5 years, 3 years later than the original plan. How many developers lost their jobs? Zilch. Plenty of companies are financially secure enough to withstand slipping ship dates without resorting to layoffs. Whether the software is for internal use or if it’s the core product that the company sells, developers don’t feel much pain from slipping ship dates. As the ship date continues to slip more and more, the sense of urgency, importance and chaos continually increases, adding some spice to an otherwise boring job. So there could even be hidden incentive not to ship. That’s a flawed system.

If a developer does the identical work the day after the software ships as the day before the software ships, from the developer’s perspective, shipping software is a non-event. After all, what’s the big deal about shipping software if I’m going to continue to do the same thing I was doing yesterday? Some individual team members are independently goal driven to ship. Hopefully, that’s the makeup of your team. But if I had to guess, judging from the norm of slipping ship dates for software projects everywhere, I suspect the vast majority of teams are made up of developers who are not overly anxious to ship software. What can you do?

Building an Environment that Encourages Shipping

Google is famous for the “20% time” it gives its engineers to work on projects they like. The way this works is that engineers are allowed to spend 20% of their time on whatever project they want, not necessarily the one that the company is banking on. Ask any engineer what they think of Google’s 20% time and they’ll say something that resembles “awwweeeesome!” But ask a manager or an executive of any company about Google’s 20% time and they are filled with fear. Fear that something like that would cut their productivity by 20% - how could they possibly afford that? The typical executive might even think Google is leaving productivity room on the table and at some point they could eliminate the 20% time and improve productivity by 25% (going from 80% to 100% is a 25% increase for those of you keeping track).

That’s a short-sighted view. Here’s why:

Most engineers at Google “save up” their 20%-time until the appropriate time in their main projects when they can work on their fun projects. Take a wild guess as to when the appropriate time to work on their 20% fun project is. You guessed it. It’s immediately after their main project ships!

Now imagine you are an engineer who [thinks s/he] has a brilliant idea. Over the past 8 months, you have saved up 30 days of 20%-time to work on your brilliant idea, but the only way you can start working on it is if you ship your main product!

How driven are you going to be to ship your project as soon as possible when you know your fun project won’t start until your main project ships? Are you going to allow scope creep? Are you going to work on that cool new feature you thought of that nobody cares about or are you going to hammer out the features from your todo list? Now you understand why Google’s release cycles and continuous application improvements have been relentless and have far outpaced the industry average.  They have a pool of engineers who are eager to get on with their own projects and the only way to do that is to ship.  Now that’s motivation!

We do something very similar at Axosoft. We never called it 20% time. We just called it a “fun side project.” After major releases of OnTime, we generally brainstorm and come up with a number of side projects that developers want to work on. They can do whatever they want. Software, hardware, web apps, automatic tuna sandwich maker, whatever. Then we spend the next 30 days working on fun projects.

This is the equivalent of taking a vacation, but rather than being stressed by the typical airport security, hotel and other vacation-related nightmares, you actually get to do something you love! For most developers it’s even better than a vacation! Software engineers love to build stuff.  Most of us get a tremendous amount of satisfaction from seeing ideas come to life.  The more exciting the ideas, the more satisfaction we get and nothing is more exciting than our own ideas.

It’s easy to provide a good incentive for developers to ship.  Just don’t think of it as a loss in productivity!

Let’s get one thing out of the way fast: There is no possible way to build and ship quality software on a tight schedule by outsourcing the development, period. If you are in the business of software, then be in the business of software and suck it up and build a team that can write the code. Outsourcing your primary application development is the equivalent of outsourcing the defense of a country. Here’s the primary thing you are admitting when you outsource:

By outsourcing the development of your software, your company is admitting that another company is better than you are at creating the very product that you want to create. You’re also admitting that they can do it cheaper and they can do it better than you can while still making a profit selling it back to you.

If that’s true, then why are you in the business of building software? You should be selling dogfood or cat litter. If you are in the business of selling dogfood or cat litter, then great, continue outsourcing. But even Amazon.com, a company that by any measure is in the ”retail” business, builds their own technology and they consider it one of their primary business advantages. If Amazon.com considers it a major advantage to build their own technology and doesn’t outsource its development, then why would you even consider it?

Outsourcing breaks some of the primary laws of building great products. To build a great product, you must have a great team. Notice I didn’t say “you should” or “it would be nice to” have a great team, but rather you must have a great team. A team is inclusive of the designers and developers and testers and trainers and support personnel! If you think that the designers can throw the design over the wall and have the developers give them back a great product, you’re sadly living in a dream world. Although the threshold of importance is substantially reduced with each of the latter items (such as testing, training and support), the quality of those items are also substantially reduced when those items are outsourced.

Lets take a closer look at the most common area of outsourcing: support. Of all the parts of software development, support is by far the easiest to outsource. It requires the least amount of technical knowledge and support managers will often tell you it’s all about “respecting the customer” and “having patience.” So if you can find people in India or Romania who can provide respect and patience to your customers at less than 1/3 the price, theoretically, you should be golden. But anybody who has spoken to a support rep recently from Microsoft, Dell, HP or any other larger tech company who is supposedly saving money by outsourcing support knows from experience that no matter how much “respect” these customer service reps provide, you end the conversation more frustrated than the start, swearing into the air and vowing to never buy from that company again. Of course you end up going ahead and buying from them again because you have no choice, but this time you know, with a heavy heart, that your purchase price doesn’t really include the promised support. Ironically, from the perspective of these companies, their outsourcing strategies save millions of dollars and not just because of the lower cost of labor. The fact that you are less likely to make a 2nd call into an outsourced support center provides an even bigger savings. So here’s what happens when a large company outsources support:

• Initial costs are substantially reduced due to lower labor costs.
• Call volume is reduced (due to frustrated users who give up calling) implying that the new call center is doing a fantastic job or the overall support strategy is working great, reinforcing the behavior that outsourcing was the right thing to do.
• Surveys will reveal nothing because A) nobody fills out 20 minute surveys and B) those who do are almost always complaining, so the percentage of complaints does not appear to be any higher than when the support was in-house.
• It does not appear that outsourcing support has had any impact on sales. This is, of course, is only a temporary effect as customers often don’t have a choice, but as soon as they do have a choice, it’s over!

So, the outsourcing strategy may initially seem like a success, even while it’s failing miserably. If you can outsource support, then why not documentation or testing? Eventually, why not development? Nobody dares outsource Design. At least not yet. But the metrics are flawed and those who rely solely on metrics for the operation of their business shouldn’t be in business. They’ll get what’s coming to them.

Note that I’m not picking on India or Romania. It would be equally stupid for an Indian company to outsource its software development or support to a US company if labor costs were reversed. I’m also not against outsourcing from the standpoint of “keeping jobs in America.” That’s about the worst possible reason not to outsource. It disrespects humanity and implies that an American’s life is somehow worth more than a non-American. Outsourcing simply doesn’t make good business sense. At least not for a company that wants to be great.

The Optimum Team

At Axosoft, we often move people around, even as little as 20 feet, just to be closer to somebody that they expect to work with on a project. It’s amazing how much productivity can be gained by being next to a person vs. 20 feet away. It encourages conversations and questions about design items, issues, features and things that would have been passed on if the people were simply 20 feet further apart. Having these conversations allows the teams to build a better more solid product in a shorter period of time with fewer defects. Increase the distance by 20 feet and you lower the overall productivity and product quality by some amount. Increase the distance to 20 miles and your productivity and product quality tanks. Increase that by to 10,000 miles and an equally large cultural gap — and you can imagine what will happen. There is a reason why companies like Microsoft, Google and Apple have built corporate “Campuses” that are focused in a single location. The close proximity of all the engineers to one another is a good thing. It creates a healthy feedback loop, which helps increase productivity and increase the overal quality of products and what’s possible. So the optimum team is one who’s physical proximity is as close as possible and its different functions such as design, development, testing and support are not outsourced.

The centerpiece of any successful development project is the team that builds it. There is no other single most important contributing factor to building great products. No tools, no development methods, no amount of money and no amount of time can substitute for the importance of an exceptional team if you plan to create an exceptional product.

Some in our industry operate under the assumption “with a good system and a fine-tuned set of processes, you can build anything with a group of average Joes.” If that sounds like your company, congratulations! You must be that average Joe. The assumption that with the right systems and tools, anybody could build great products couldn’t be any further from the truth.

Only driven, motivated and talented teams can make great products. Heavy systematic methodologies of product development and processes can only slow down those teams to ensure that the slowest person on the team can keep up. Process-heavy systems are designed for the weakest team member and therefore must slow down the pace of all other team members to ensure that few mistakes are made by those who are not exceptionally skilled. The cost of such systems is incredibly high.

See if this sounds familiar: Your team is fast at work on the latest project. Due to the size and importance of the project to the company’s success, the executive team is providing the budget necessary to expand the team. It’s estimated that your team will need to increase the “headcount” by 5 or 10, in order to meet its project deadlines. To quickly ramp up for the new required headcount, the bar for qualified candidates falls nearly as fast as the team’s cohesiveness. Within a short time your team successfully adds 10 new “heads” to meet the aggressive project schedule.

To ramp up the new members as quickly as possible, they have been given the proper one-day overview of the project. They weren’t even asked to write code until Day Two. Soon these new team members start contributing thousands of lines of code. Productivity seems at an all-time high. Tasks are getting done in record time and the team now seems to be functioning on all cylinders. If you’re lucky, within a couple of weeks, the first set of problems start to reveal their ugly heads. All kinds of new nasty bugs show up in QA (assuming, of course, that there is a QA team). Senior team members have to take time off of their tasks to track down these nasty issues. After days of searching and going through weeks of code line-by-line, some suspected line code are identified. The first question asked is “who wrote this crap?” and so the process expands.

In order to find out who’s responsible for poorly written code in the future, “checkin” rules requiring detailed comments are put into place.  Additionally, every single line of code is now required to go through a complete and formal code-review to help reduce errors.

The team’s pace changes drastically. Things slow down and soon it’s obvious that the deadline targets of the project schedule are impossible to meet. At current pace, you easily need to increase the headcount by another 5 to 10 to make the ship dates.  But, even that is unlikely as a frustrated, but competent teammember finally speaks up and reminds the executives (and everybody else in the room) that 9 women can’t make a baby in 1 month.

Finally, everybody comes to accept the missed deadlines and the pushed back release dates. Life goes on…slowly.

There is a Better Way

There is, of course, a better way. Among engineers and project managers, it’s common knowledge that a really good engineer can be 3, 5 or even as much as 10 times more productive than a bad engineer. What a load of crap. You’re probably thinking I’m nuts. You might even be thinking that you personally know software engineers who are 3 or 5 times more productive than the guy in the next cube. What you don’t realize is that you are probably discounting their productivity.

It’s possible for a good engineer to be infinitely more productive than the engineer sitting next to them. How is that possible? Consider this: in 1975, how many engineers could have single-handedly done what Steve Wozniak did in designing the Apple I and later the Apple II? What about the search algorithms used by Larry and Sergey (Google)? I know that if you had given me 10 years, it’s not likely that I would have thought of page ranking or search in the way that Larry and Sergey did. So how much more productive were they? I’d say about ($)150 billion times!

The problem with comparing people in terms of multiples of productivity (such as person X is 5 times more productive than person Y) is that there is an underlying assumption that both person X and person Y can do the same job. That is a huge and usually wrong assumption. Two people might be able to do the same job and if one of them is generally 5 times more productive than the other, that probably means there is a whole realm of things that is possible for one of them that’s impossible for the other.

With that in mind, if you were working on a hardware project and estimated that you needed 10 more engineers to get the job done, would you take 10 “Average Joes” or would you settle for 1 Steve Wozniak? If you were working on a Search-related project, would you take 10 “Average Joes” or 1 Larry Page or Sergey Brin? If the answers to those questions seem obvious to you, so should the importance of building a great team. It’s not about “headcounts.” It’s about talent. So to create a winning team, keep a few simple rules in mind:

1. Hire the most talented people you can possibly find. Don’t hire someone if they don’t meet the bar you’ve set. I know it’s extremely tempting to lower the bar when it’s hard to find good people. Remember that a bad hire could actually have negative productivity!
2. Create a system that’s flexible and light in process. Implementing any kind of canned methodology that has steps outlined from A to Z on how to create products and manage teams ensures that your team will operate at a low efficiency. A more dynamic and light-weight, low-process system is ideal when your team is already talented enough to know how to do the right things.
3. Eliminate team members that consistently fall below the bar. Don’t kill them. Just fire them or move them to a different position if you can. If you can’t get rid of team members due to corporate culture or red tape, give them tasks that are non-critical to the success of your project. Often times you can increase productivity faster by removing team members than you can by adding them. If you find that you’re adding process to your efficient system because of 1 or 2 people who consistently need detailed guidelines to get work done, those are the guys I’m talking about.
4. Create a culture that appreciates talent. Talented people like to work with other talented people. That’s how they’re satisfied. By giving them freedom to do the right thing and taking obstacles (and dumb people) out of their way, you’re creating a culture that appreciates and rewards talent.

By putting the emphasis on the team rather than the process, you’ll create much better products at the end.