Succeeding with mediocrity

One of the criticisms of engineering practices like XP (and Agile for that matter) is that success is only really possible with strong, experienced developers.  But is it really possible to succeed with mediocrity?

In my experience, teams have a certain amount of potential.  Conditions can be optimized to maximize their potential, as well as grow it.  But mediocre teams will only produce mediocrity.  No process, nor tool will change bad developers into good ones.  Can anyone expect a mediocre wood craftsman to produce good furniture?  The most you can hope there is that the chair won’t collapse when you sit down, or a nail won’t poke you in the ass.

It’s also true that strong, experienced developers are more likely to succeed no matter what the process.  But given a strong team, I’d rather continuously improve the process with regular feedback to improve my chances, rather than assume that a strong team will automatically succeed.  I’ve been on the other end of that stick, on a strong team that failed because of bad process decisions.

I think we have to move past the idea that success is attainable with mediocrity.  The way I see it, the most we can hope for in mediocrity is to not fail, which is quite different than success.  On that note, check out Jeremy Miller’s article on continuous design in this month’s MSDN magazine.  If your team is not able to achieve this kind of design, it’s probably a good idea to start lowering expectations now.

If it’s part of our company’s business model to need highly successful software projects for the company to succeed, the company would need to decide to either a) hire/nurture developers if software is the company’s core competency or b) outsource to smart people.  For either a) or b), a company has to be able to hire folks that have both the desire and capacity to become strong performers.

I think, as an industry, the pool for those types of folks is quite small.  On the other hand, many other disciplines have created professionalism where none existed before, so software development doesn’t need to be any different.  So how do we get there?  Professionalism should be the accepted standard of employment, not what TLA tools you’ve learned recently.  Know WCF?  Who cares, can you make the informed decision to know when RPC is applicable.  Anyone can read a book and sling software, but creating maintainable code when it counts is something else entirely.

Software development is still a young industry, and we are still figuring out how to maximize the value of our efforts.  But I don’t think we need to accept mediocrity as the norm, our customers demand better.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Misc. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Quite an interesting idea. Instead of relying on the “you need to define success” idea which every agile evangelist is bugging me with, why not define failure and just make sure you don’t reach it? That would be a good intermediary step.

  • Hi Jimmy,

    I think it’s a myth that you can take a sub-par team, throw agile practices at them, at them suddenly turn into an amazing team.

    In fact, the studies show not that, but instead that a well functioning team can beat the productivity of a single rock-star developer. Of course it helps to have good developers. But I have seen first hand that you can take a team of middle-ground developers and turn them into something great.

    It becomes, then, a balance of the needs in the organization. Teams with developers who understand principles like SOLID, or who do things like TDD are already going to care more about their code, which means that the focus can be on continuing to grow them. In a team without that, you have to have a solid coach who can build the group together to a team, then improve their practices. Oftentimes the engineering practices aren’t the only ones suffering – it’s also the requirements and the overall organizational vision and agility.

    I absolutely agree that process by itself won’t change a team. But with the right practices, the right coach, and the right sponsorship from management, you can take a mediocre team and turn them into a high-functioning team. I’ve seen it first-hand. They may not have been as good as some of the incredible teams I’ve been able to be a part of, but compared to the industry norm, they were head and shoulders above the rest.

  • Phillip Jackson

    Siderite: Defining failure and trying not to reach it reminds me of a motorcycle riding concept. On a motorcycle, you will go where you look. If you stare at the ditch you will soon find yourself in it. If you focus on the criteria for success you will be more likely to achieve it.

    Dare I say that defining failure and trying to not reach it is the definition of mediocrity.

  • It is a bit of a myth that Agile processes require great developers. As Cory said, with the right environment, a mediocre team can become a great team. I see orgs seeding teams with one or two great programmers, and the rest are fresh college grads, or people who seem to qualify as “mediocre.” Usually this is a recipe for disaster.

    But when they are given the right tools to communicate and collaborate, we discover that a large number of cross-trainings occur spontaneously (and in surprising directions), and the quality of the product, its design, and the team all go up considerably.

    Few people really want to settle for career mediocrity, but they have to have an encouraging environment where they can grow. It’s also downright cruel to take great developers and toss them into a mediocre process.

    So you need both: A good process that allows true collaboration to occur without teammates competing amongst themselves, and one or two strong leaders or technically strong developers to spread their wisdom and to mine for hidden gems of knowledge.

  • Charl Victor

    I in principle agree with Rob and Cory. If the environment and requirements do not give you space to grow and improve it is unlikely to happen and the result will suffer.

    Saying that, it also depends on the kind of developer. Are they willing to grow and improve themselves or to they just the kind that are happy to just come to work everyday. You need those go-getters (not the arrogant, i know it all type) to drive innovation.

  • Marc Lawrence

    Do I have this right. Agile requires strong developers, so we need a professional designation to weed out mediocre developers?

    Developers reach the level their “manager” lets them get to.

    By “manager” I mean person who removes obstacles, coaches teammates and fights for the project to make reasonable choices. Interestingly a great deal of agile is aligned with modern (post Drucker) management, someday I’ll write some post on it. But from what I’ve seen it’s just to big a leap for most “used to be a developer and now I run the shop” managers to understand how run things without defining all the little details.

    Agile requires a good “manager”, who isn’t afraid to lose their command and control. I think it’s funny that when things go wrong everyone says “we need more control”, better specs, _a clear professional designation_, bigger sticks.

    With a good “manager” mediocre developers can be grown to great. A good team can be grown from the average. Agile can flourish, with developers taking ownership and be pushed to learn new things. They might even become so engaged they do it on their own.

    And that is the problem with mediocre developers. No one helped them become great. Its not that they are incompetent.

    Look it… Everyone is good at something and bad at others. Everyone. Great developers found those things and worked hard at them. Some people are great at deployment or installs or algorithms or UI. No one is a 10x developer at everything AND all teams need all those role filled one way or another.

    Individuals and interactions over processes and tools

    -End Rant

    Marc Lawrence

    PS I think some of the other comments are on the right track, just not the OP.

  • @Marc

    I think success requires strong developers, not really Agile. I was thinking more along the lines of – can you be successful with a mediocre team? Depends on how you define success