There is No Silver Bullet In Software Development

In my 30 years of programming at or near the leading edge of software technology I've seen a ton of ideas, tools, languages, processes and methodologies appear that each claimed to be the ultimate solution for improving how software is written.

Not one of them ever got beyond marginal success and many actually made things worse.

There isn't anything wrong about new ideas; each one represents a datapoint in an ever expanding search for a better way. Writing software is still hard and with each generation of technology expectations of the industry or the market often increases faster than the ability of programmers to keep up. So new ideas are necessary to find some way to get things done and stay one step ahead of the technology steamroller.

The assumption that there exists one idea that will revolutionize programming is what never seems to vanish despite decades of examples that prove there is no such thing. Even what amounts to the biggest change I can remember during my career, Object Orientation, which still dominates the programming language universe, isn't a panacea. Like so many other ideas it's only another tool in the toolbox, not the holy grail.

The one thing that unites all the great projects I have worked on over the years has always been the ability of the people involved. By people I mean everyone from managers to developers to architects to testers and often the customers as well. The best ones were able to communicate well, had both imagination to figure out how to solve tough problems and the discipline to know what to keep and what to reject, enough experience to know when a direction was going to work, the freedom to find and use the best tools or ideas to get the job done, and enough leadership to get the project complete. Sure it sounds pretty vague but during my lifetime of work nothing stands out but the people involved.

What has irked me most of my time is when people stand on a soapbox and say things like "if you don't use X then your code will suck" where X could be almost anything. I've heard this for so long it goes in one ear and out the other.

For every software development idea X that was invented at time Y people were still able to deliver excellent software long before Y.

For example I never heard of the term "unit testing" until the mid to late 90's. Yet me and the team I worked with on Trapeze, Persuasion and Deltagraph shipped 13 major releases of the 3 products (only 1 for Persuasion) with a nary a single unit test. The software was shipped on floppy disks (10 in the case of Deltagraph) where each release generally cost at least $10 to duplicate plus shipping. Deltagraph at its peak had 100,000 customers so the publishers entire profit for the year might be the eaten up by having to ship out a whole new set of disks if something major went wrong -- but not once did we have to do it. Today you can patch a bug online instantly (or not if you have to wait on the App Store review).

For Trapeze and Deltagraph the final ship decision was mine but the whole team knew and understood how to produce something that worked with no UML, no unit tests, no test first development, no design patterns, etc. and in C no less. Of course we weren't alone in that.

Would we have produced more quality or taken less time with all the modern ideas? Maybe, but it's always hard to compare different eras. Would doing things the way we worked back then work today? Tough to say as today's marketplace is so different. The point I am trying to make is that it's not the tool or the methodology or the language or the flavor of the month that matters but the people and how they go about getting the software done.

Over the years listening to software tool vendors was always a fun thing to do. Each one sold their products or system as if they were the final answer to all of life's programming problems. They never were of course but the fear of every programmer was that some manager would believe the hype and we'd all get stuck with something hopeless.

Managers and especially CIO/CTO types with no real technology background are the worst culprits when it comes to buying hype. Some vendors talks them up or they read an article and suddenly the entire company has to switch to something different. I'm sure every programmer has experienced this kind of insanity.

One CIO I worked for bought an expensive technology from a vendor that promised better enterprise development and then was asked to write a glowing report for their website about how it reduced our time to write software from 8 months to 5 weeks. Then that company sent some marketing people to interview the programmers and were shocked to find we didn't use it other than for one simple calculator, done only to keep the CIO at bay.

It's not that you can't improve things with better ideas, methodologies or tools; if not for improvements in how we write software theres no way we could keep up the demands of the modern world. It's just the expectation that something by itself is the perfect antidote to whatever ails your organization that is wrong.

I once spent a long time explaining Agile to the methodology team at the company I worked at (financial service firm) which operated more or less a waterfall. The team (yes there were actually 3 people on it) then went off and a few months later came up with the new methodology. Instead of something lean and agile they had taken the waterfall to a new extreme, basically 15 steps each with documents, meetings and schedule that defied understanding. The funny thing was the the 15th step was basically "write the software". Agile in concrete overshoes.

That's the flip side to new ideas - when people take the idea and recast it in the old idea's form and present it as new.

Clearly everyone wants to write software better and write better software. The issue is that the belief that any one thing will solve the problems is faulty but never seems to go away and probably never will. The real solution lies in the people involved and that sounds too fuzzy to be real so people try to find some technology solution to make things better.

As a final example I point to the original iPhone. Every phone manufacturer in the world had smart people. All of them had successful products and a long history in the industry. Yet Steve Jobs had an idea and a team he picked that he was confident could bring everything together from design to coding to manufacturing to marketing to make a phone with 3 buttons to change the entire industry. There was no single reason Apple did this (beyond Steve anyway) but the right people with the knowledge, experience and freedom to innovate and especially ability to communicate. The team made this happen, not any particular process or methodology or tool or language.

So keep your silver bullets handy for killing Werewolves and occasionally drinking a cold (crappy) beer. Just remember that in checking out something new in the programming universe you might find a better tool for your toolbox but you'll never throw the toolbox away completely and skip magically into nirvana.