Silver bullet anti-pattern
I will continue my little serie about anti-patterns of decisions and activities that may screw up projects and make developers (and why not also others) life hell. Now let’s look at silver bullet anti-pattern. It is about using unknown tools and technologies in the place where one shouldn’t never do that.
Okay, suppose you start with a larger project and you have one week of analysis and design meetings behind. Your team must use some new technology but it is okay because most of your developers have used it and you have also some more experienced developers on that technology. Everything seems okay and everybody is full of power to build up a new killer solution.
Now, about third week, there is meeting where one guy introduces new idea – why not to use related technology XYZ? He tells that he has even book covering that technology, it is about 800 pages – average programming book – and this technology looks very promising. At least introductions found from internet suggest this new related technology. Because this new technology looks promising and it seems that this technology solves many problems you say okay, let’s use it – team has found the silver bullet for this project.
After two months you feel that this bullet is not so silver anymore and also you feel like this bullet is shot to your head. Project is out of schedules, there are weird problems related to technology XYZ, it is not easy to find any documentation or other helping stuff about it and nobody knows when project may get back to track.
It is always good to remember: if you want a silver bullet you will get it straight between your brains.
I agree. We may think that technical decisions are always the programmers responsability but has you has described they are not always the ones that should decide.
The project manager should see the high risk involved in accepting a major change like this one and inform the stakeholders. Technology is not important. What it is important is to build a software solution to solve a real world problem.
The guy introducing the new texh in your scenario sound like a case of “Drive-By Architecture”.
“This product does 90 percent of everything we need, lets use it”.
The reply : “Sure, but it only does the easy 90 percent, its that last 10 percent that we need help with”
Thank you Andrew for a good point. One thing I forgot to mention is subversion of this anti-pattern: technology XYZ is applied in the middle of the project or in the finalizing phase.