When You Realize that your development Geniuses are really Asses

So you have a development team. Yes. They are smart. But perhaps not as smart as you think. Regardless they swagger and talk. Controlling your projects and plotting down a path of doom.

But what are the signs that they have gone too far.

Could it be when:

1. They complain of out of town managers (you know, the  ones from head office) arriving and appearing at meetings and asking questions when they don't know anything about how your destroying the projects?
2. They claim they can rely only on unit tests?
3. Perhaps its when they think they can stovepipe code straight to production without a system level test in a staging environment?

If its any of these it probably already too late for you. Controlling their incompetent urges now that the arrogance is out of the bag will just mean they will leave to go destroy another project.

Or perhaps that would not be so bad after all.

Has Your Company made this Traditional Mistake Managing a Team

What traditional mistake is this? Search through your history,  you know its there....just lurking below the surface. Ah. There it is.

The Myth of the Genius Software Developer.

Sometimes it goes beyond myth, to adulation, subservience, and worship. Managers, the incompetent ones, prostrate themselves to the genius software developer thus leading them and their project down the path of doom.

Managers become lackeys.  Sorting the technical laundry too scared that all those eggs that they put in that one basket will fall. Scared that they would loose their genius.

Losers.

All of them.

The Crisis in the Software Industry

To be fair I have not seen this at any one company. I have seen it at every company I have worked for. And as a software developer with 20+ years experience I can also say, in my more immature days, I was guilty of the same sin.

What is that problem that I observe?

Just the arrogant self absorbed know-it-all behavior of  software development shops. Sure, some may be nice people. Some even care.

However I have a slightly different perspective. I have this perspective because I have been within development teams and outside development teams. I was known as the software developer/architect that talked to QC. Talked to support. The response I received from these teams that this was rare behavior.

My observations of development teams are as follows:

1. Do not consult, even if others outside development may have more experience on the technical issues they are working on.
2. Get easily impressed by "cool" technology. Nay, they are a slave to it.
3. Only address problems in how that cool technology can solve it.
4. Are easily impressed by technology that they think the "cool" kids are using.
5. Cannot address the core problem or use case. Unless it is in terms of that cool technology.
6. Cannot address problems with humility and respect. Are treated like unicorns and as such behave like unicorns.
7. Some even have a know-it-all behavior to the point of absurdity - such as the time a colleague announced that HE was a breast feed expert. (His wife was expecting and he read a book on it).

The end result of these issues is a product that has security (amongst other) flaws. By design. Combined with a FISI (F*ck it ship it) management methodology you can understand why shipped or cloud based software is garbage that customers end up becoming the quality testers.