The “bring Amazon Web Services mentality back home” blog post generated the expected comments, from “developers have no clue about networking or network services” to “we went through the whole thing and failed badly.”

Well, even though it might have seemed so, I didn’t advocate letting the developers go unchecked, I was just pointing out that double standards make no sense.

The Dunning-Kruger Effect

The world if full of over-confident people who think everyone else’s jobs are so trivial they could easily excel at them if only they would care enough to tackle them (and the highly intelligent people are the worst, not just in IT). This behavior is so widespread there’s an official name for the “I can do it even though I have no clue” behavior: the Dunning-Kruger effect (read the full article, it’s a masterpiece; there’s also a shorter summary).

IT is full of such people:

• Network “architects” and “designers” who start designing new networks solely based on the information contained in vendor whitepapers (actual question I got: please send me step-by-step procedure that will result in optimal data center design for my customer);
• Engineers who deploy totally unknown technology by finding random configuration snippets on Google and blindly apply them to their networks;
• Engineers with no cloud buiding experience who plan to download OpenStack source code and have a working private or public cloud in two weeks (been there, seen that);
• DIY engineers with the not-invented-here syndrome who claim they can reinvent every solution proposed by a vendor (our Flip-IT guys have dozens of stories to share – in most cases all the DIY engineers managed to do was to waste 2-3 years);
• People who blindly download scripts and use them without even checking whether the scripts are applicable to their environment;
• Application developers who think they can deploy complex applications on AWS without having any networking or network services experience just because “it’s all point-and-click anyway.”

Would you let your kids drive your car?

Letting people suffering from Dunning-Kruger effect go is like giving the keys to your car to your kids. Some of them might have hidden talents and will bring back the car in one piece, but you can’t count on that. There’s a good reason we have driving schools and driver exams.

The same reasoning should be applied to application development teams (or anyone who starts building a new network by googling for “network design”). They have to be interested in getting independent (they all are on a verbal level), get proper exposure to the challenges of designing and operating cloud deployments, virtual networks and network services (avoiding designs like this one), and then slowly let go with someone carefully watching the results.

For example, the very first technical lesson in my Designing Scalable Web Applications university course is TCP, HTTP and SPDY; the course also covers security, load balancing and cloud deployments.

Investing into an equivalent of closed course driving always makes great sense. Fortunately it’s really inexpensive to do that in the application development world; instead of developers working on their local workstations and servers, give them a full-blown cloud-based virtual environment including firewalls and load balancers.

Does it make sense to invest in that process? Ask any soccer mom who wants to have something else to do in her life than driving kids around. Investing into the application development teams and making them more independent will make your IT better, more flexible, and eventually reduce the costs as the developers realize the craziness of pushing the problems down the stack.

Will it work in every environment? Most probably not, but then maybe it’s time you start looking for a different company to work for. Will it work with every team? Of course not, there are still programmers out there who think they’ll reach retirement age writing COBOL applications… but if you manage to optimize just a few application development teams, it’s better than nothing, and their success might trigger a mandatory reorganization of other teams.

Finally, keep in mind that great power brings great responsibility – like kids sitting at the driving wheel, developers who want to get faster deployment by controlling their own virtual networking environment and services must also take full responsibility for the results of their actions.

Oh, and last but not least – my kids always had to pay for their own gas. Looks like a similar approach would help in some cloud deployment debacles.

Need more information?

Check out my Building a Private Cloud Infrastructure webinar and other cloud computing and networking webinars (and make sure you start with the business needs).