There Is No Silver Bullet

Mitchell Sinclair
3 min readOct 21, 2020

People who pursue a career in technology tend to come from diverse backgrounds, but they do tend to have a common personality feature. They are a hammer in search of a nail. Those of us who make this our life’s passion love to find problems and solve them. As such, we tend to love it when we come across things that solve problems for us. However, we can tend to go a little overboard when we find something that we love. Then suddenly the industry is aroar with “The Next Big Thing”. However, I think the industry has taught us that there is no silver bullet. Let’s just look at two examples, one from a few decades ago, and one from more recently.

Object-oriented programming (oop) was once considered one of these “Next Big Things,” and by all accounts, it was. It has become one of the industry standards that, like it or not, will be around for quite a long time. However, if we remember back to the time when it was first coming around, then we see a time where oop was going to save us from all of our woes. Oop was supposed to erase spaghetti code, make refactoring easier, and make it easier to reason about programs. But as we can see today, code can still become jumbled, internal coupling is still a thing, and programs are still as convoluted as ever. Not only does industry experience tell us this, but we know from resources from the time. We see from the advent of UML, best-practices around oop, and “OOP Gurus” that it has been a bungle from the start. While it gives us another tool in our tool-belt, programming still requires good engineering and a steady mind. It didn’t solve any problems, just gave a tool that works when applied to certain projects and not to others.

We also see this with the modern architectural trend of micro-services. This is an architecture that when applied to your project modularizes parts, gives a standard communication method, makes refactoring easier, makes the application scalable, and helps to eliminate the learning curve to new engineers on projects (I feel like I’m hearing some echos here). But again, we see that this is not a silver bullet. While it promises many things, the realities of micro-services are that they are very well equipped to handle certain types of applications, but not others. And getting this wrong upfront can lead to a lot of headaches down the road. Things like performance issues, bungled api docs with confusing interfaces, and the impossibility of keeping dependencies straight so that you can actually test locally in some reasonable capacity. Micro-services were supposed to help to solve our backend woes, but again we see that it is mearly another tool in our tool belt.

Now I know that I am probably preaching to the choir. Many engineers already know this. But especially to young engineers and fanatics out there. Just remember that while new technologies are interesting and help us solve certain problems, they are not the be-all end-all for every problem out there. And to nosey project managers, how about you leave design decisions to your professional staff.

--

--