I spent almost a decade being very confused about best practices for software projects. I mentored most new team members away from the practices they’d been taught. I spent lots of time thinking

• Am I wrong?
• What am I missing?
• How can this make sense?

I read articles and explanations and white papers and never found answers. My team (mostly contractors from a single consulting company) always performed well on the key criteria

• Budget – fine
• Schedule – almost always on schedule (3-7 deliverables a month)
• Scope – accommodated A LOT of late requirement changes without impacting schedule
• Quality – better than most of the 100s in my company

Then I moved from development lead to enterprise architect for consumer web:

• Dozens of brands.
• Almost 1500 websites.
• Over 100 development companies.

Enterprise Architect Role

I’m setting standards, objectives, and measures. No longer able to mentor and assign work to one team, much less 100s of teams.

One development company was consistently at the bottom of all measures

• 2x longer initial schedule than average.
• 3x longer than our top performer
• Always missed the schedule
• Weeks of problems after deploy including lost data

I thought this was unacceptable. They weren’t even cheaper than most developers. It was my job to solve problems like this. Fortunately, this company was the one I’d been working with on my team for almost a decade and I had a good relationship with someone who was now a VP. We always had dinner when we were in town together so I let him know what I wanted to talk about at the next dinner.

My AHA Moment Dinner

He listened politely as I rattled off all the metrics and issues and data losses and everything else I wanted to complain about. Then he responded with questions. Something like this

VP: How many websites has your average development company done in the last 6 months?

Me: 10-15

VP: How many has your top company done?

Me: 1

VP: How many could they do next year at the most?

Me: 6?

VP: We built 37 new websites for your brands over the last 6 months.

VP: We added major functionality to over 70 brand sites over that time.

VP: We did minor work on over 150 sites

VP: We monitor & administer over 400 websites daily

VP: We answer the phone in 7 languages and can have a native speaker in 43 languages on the phone in minutes 24/7

VP: If you tell me tonight that you want to start 10 projects on Monday, it will happen.

VP: I can give you high-performing teams if you want. Probably more than 6 sites a year, but not the scale you have asked for. New projects will start in months, not days.

VP: We cannot hire enough high quality developers to fill your needs. We do staff your projects with people who honestly should not be developers. But we have developed best practices to make them productive.

With that one sentence, 10 years of confusion disappeared. I’d been looking at it backwards thinking “best practices should make good developers better“. But best practices from this company are intended to get some productivity out of contractors who “honestly should not be developers“.

I’d also missed a really important metric: scale. My brands needed this company and its best practices. And so did I, or brands would build sites on their own instead of using my organization’s recommendations of technology and developers.

Authority Bias

When I try to discuss the harm certain best practices are doing to a company the response is usually Gigantic Consulting Company X recommends it so it must be right. In one case a client had lots of problems because of a best practice. Their main consulting company gave them a new best practice that covered the symptoms, but not the problem. I’m one person brought in to do special projects and don’t have the authority of the big guys.

It’s just as likely that I’m wrong as anyone else – both in general and wrt any specific practice or team. So it’s not unreasonable to accept what the recognized industry expert says.

What Can You Do?

Identify the business purpose of best practices. There are many technical best practices that developers do because they work.

When big companies write white papers and give presentations on a practice, there is a business purpose, not just a technical advantage. They don’t dedicate staff without a business purpose. The high-performing little company doesn’t usually have a team coming up with best practices and writing papers and giving presentations. They just use their best practices for the next project and learn from their experiences and each other.

Once you identify the business purpose, see if you have the same needs. I may disagree with a practice that is very appropriate for your team.

Example Business Purpose

The business purpose of the practices that frustrated me could be summarized as

Ensure projects can be staffed

• with minimal effort
• with minimal cost
• with any available resource (not currently on another project)

A company with 1000s (or 10s of thousands) of developers, project managers, DBA, and other development positions is constantly hiring for many reasons

• Most want to grow.
• They all have projects in the pipeline that need to be staffed on a certain date.
• They all have turnover, promotions and other reasons positions must be filled.

They can’t afford to spend a lot of time interviewing candidates for the project that starts next week. Higher quality candidates are harder to find and usually have higher cost. Hire the top of the resume stack, or pull someone from another project.

Being able to pull someone from another project means everyone needs to follow the same practices. If a top performer leaves (or gets promoted), you need to be able to plug in anyone else and hopefully not slip schedule. So top performers are not expected to perform at higher levels. In fact, it’s bad if they do since they are no longer an interchangeable piece and clients will start demanding specific teams or individuals when performance varies.

Summary

• Best practices are valuable and necessary.
• Understand both the business purpose and technical details before adopting
• If a practice is not right for your organization, don’t be afraid to ignore or modify it
• If something doesn’t seem right, you may not understand the business purpose

If you have any comments, questions, or feedback, the way to get to me is @devrelieffred on Twitter.