You have a people problem, not a technology problem

Stop me if you've heard this one before. Things are going poorly in your world of software development, and someone makes a suggestion.

"If we just use [framework or technology here], everything will be awesome and we'll cure cancer!"

I like new and shiny things, and I like to experiment with stuff. I really do. But every time I hear something like the above statement, it's like nails on a chalkboard. You know, most of the NoSQL arguments over the last few years sound like that. It's not that the technology isn't useful or doesn't have a place, but when I'm looking at it from a business standpoint, I have a perfectly good database system, that happens to be relational, that could do the same thing, is installed on my servers, will scale just fine for the use case, and I employ people who already know how to use it. Maybe I have something in production that uses it wrong, but that isn't a technology problem.

I'm sure we're all guilty of this at various points in our career. We've all walked into situations where there is an existing code base, and we're eager to rewrite it all using the new hotness. It's true, there are often great new alternatives that you could use, but I find it very rare that the technologies in play are inadequate, they're just poorly used. That kind of thing happens because of inexperience, poor process, transient consultants or some combination of all of those things.

The poor implementation is only a part of the people problem. There is a big layer of failure often caused by process, which is, you know, implemented by people. For example (this is real life, from a previous job), you've come up with this idea of processing events in almost-real-time by queuing them and then handing them off to various arbitrary pieces of code to process, a service bus of sorts. So you look at your toolbox and say, "Well, our servers all run Windows, so MSMQ will be adequate for the queue job." Shortly thereafter, your infrastructure people are like, "No, we can't install that, sorry." And then your release people are like, "Oh, this is a big change, we can't do this." You bang your head against the wall, because all of this kingdom building, throw-it-over-the-wall, lack of collaboration is 100% people problems, not technology. Suggesting some other technology doesn't solve the problem, because it will manifest itself again in some other way.

What do you do about this? Change itself isn't that hard (if you really believe in the Agile Manifesto), but people changing is hard. If you have the authority, you remove the people who can't change. If you don't, then you have to endure a slower process of politicking to get your way. It's slow, but it works. You convince people, one at a time, to see things in a way that removes friction. Get enough people on board, and momentum carries you along so that everyone has to follow (or get off the boat). I knew a manager at Microsoft who was exceptionally good at this, and his career since has largely been to convince teams that there was a better way.

At a more in-the-weeds level, you get people engaged beyond code. One of the weakest skills people in the software development profession have is connection with the underlying business. Mentor them so that they understand. Explain why the tool you use is adequate when used in the right context and will save the business time and money, compared to a different technology that has more cost associated with learning new skills, licenses or whatever. It's like the urge to buy a new phone every year to have the new hotness... It's fine when it's your money, but not so much when it comes at the cost of your employer.

As technologists, yes, we want to solve problems with technology. Just don't let that desire obscure the fact that the biggest problems in our line of work are rarely technological in nature.