Disappointment, frustration, and diminishing patience marked the world’s experience with BP’s recent oil spill. If you’re an entrepreneur whose web development team web development project has hit a snag, you probably feel all the same emotions. The consequences of launching a website late are negligible compared an oil spill, but that’s little solace when your reputation and money are on the line. Yes, you’re experiencing your own mini oil-spill.

Everyone Wants To Know When The Problem Will Be Solved.

In the days after BP’s April 24, 2010, explosion and spill, BP estimated one week to find a solution. This rosy estimate may have caused more damage because Gulf residents couldn’t plan for a protracted response, the government couldn’t assess the real scope of the damage, and BP set themselves up to fail. BP executives probably knew all along that the leak would take months to fix, but that answer was politically impossible to give. It reminds me of the web development project manager who, facing an unknown and unforeseen challenge, gives the client the most optimistic date possible to keep the client from freaking out.viagra

Everyone Has A Solution But No One Knows If Their Solution Will Work.

Countless experts and non-experts shared their opinions as to how best to solve the problem. BP no doubt brought in outside experts, consulted with the Army Corps of Engineers, and added to the response team. It’s not clear whether adding people to the team slowed or sped the solution. In web development, adding people slows the process.

When web developers hit tough problems, they stop, panic, and then try everything possible to fix the problems. The client, thinking the developers are in over their heads, starts searching for better developers. Unfortunately, adding new developers only slows the process.

Adding People Slows The Process.

A simple explanation of why more developers slow the process can be found here. Basically, more people means more communication.

  • In a team of 1, the developer can make the change without communicating with anyone.
  • In a team of 2, the developer must inform one other person.
  • In a team of 3, there are two others to inform.
  • Instead of replacing the whole team, try to bring in one ninja. One ninja – a super-effective developer – can spot the problem and make changes by himself way faster than a team can collaboratively solve problems. So if you need to supplement a dev team’s work, do it by bringing in one ninja.

    Implement, Test, Fail, Repeat.

    Expect some solutions to create more problems. The first BP solution involved high-tech underwater robots; no one expected the robots to collide underwater and break. Similarly, some development solutions trigger yet more problems. This happens often when new developers work on old code.

    The Leak Might Be A Symptom Of A Larger Problem.

    BP’s spill reveals the haphazard, hands-off approach the US government takes to oversee off shore drilling. It also reveals that BP prioritizes rapid oil extraction over safe or sane procedures. In web development, one small problem may reveal more systematic failures in how the code was written overall. One of the phrases clients want to avoid is, “we need to refactor.” Refactoring is basically re-writing and re-organizing all the code written to date. It takes time and money.

    Avoid refactoring code by using the same team and following best practices from start to finish. If you stop and start development, the chances of keeping the same team on board are low. The code suffers and will eventually have to be refactored.

    There Will Be A Solution, But It May Take Longer Than Anyone Expects.

    There’s always a solution, but it also always takes time. The lesson here is to budget for the worst-case scenario and avoid announcing deployment dates. Hope for the best but brace for the worst. In BP’s case, the seven-day solution actually took 102 days.

    • http://ua.linkedin.com/in/pavelreva Pavel

      Thanks for posting this cognitive article