This is an excerpt from Enterprise Sofware Confidential, my white paper on buying enterprise software without making a huge mistake.
In this article, you will learn:
- solid business reasons to care about developer happiness – even when they’re not your employees
- why so many enterprise vendors produce piles of garbage that still sell
When making a major software purchase, you have a lot of questions. But there’s one that nobody asks, yet is so critical: what’s the developer experience like?
As you read earlier, enterprise software is all about configuration and customization. Your company has proprietary processes to which the software must conform. Or it should. Granted, many times the software is in line with industry best practices and you are not. Changing your processes to match the software is a win/win. But if you’ve invested time and money to create competitive advantages, you don’t throw them away to save engineering dollars.
So no matter the core feature set, there will be a bunch of custom programming to get this thing off the ground. Yet nobody asks if it will be pleasant for the developers. Yes, pleasant! Maybe you don’t care if the programmers like their job. Maybe you don’t like your job. Misery loves company, right?
Kidding! Of course, you care about the happiness of your employees. But in most cases, these are not your employees. They’re at the system integrator or vendor, and you’re paying them a lot to power through it without complaining.
In reality, there are solid business reasons to care about developer happiness, even if they’re not “your” developers. (Note: I’m going to use the word integrator to denote anyone customizing your software. Short for system integrator, but often referred to as professional services or solutions consultants in the biz.)
Golden Handcuffs
Golden handcuffs are what we call the high salaries paid to good engineers so they don’t leave because the work sucks and they are not learning anything new. This cost is passed on to you, of course. And sooner or later, they are going to leave. Maybe in the middle of your project. Probably to a better platform in the same industry. A lateral move pay-wise, but a raise in enjoyment.
Ill Communication
The experience could be bad because the vendor doesn’t support system integrators well. Poor documentation, no access to the bug tracker, and firewalls between the integrators and the product team. When something goes wrong, it’s on the integrator to prove it to the product team, which is a long and painful process when you can’t talk to them directly. Many eye-rolling questions. (“Have you tried turning it on and off again?”) And that time is billed to you!
A Pile of Garbage
Often times, the reason it’s a bad developer experience is because it’s bad software. It didn’t start that way (I assume). The 1.0 version was pretty good, used the latest and greatest frameworks and incorporated smart design decisions.
Then the sales division took over. If the vendor has to spend a lot on sales, and that team is credited with driving revenue, they amass power. When that mindset grows to the point where engineering can’t make a stand for quality, you’re on a path to a pile of garbage.
Sales will push for new features over fixing bugs. Marketing will mandate deadlines to meet their initiatives (trade shows, commercials, etc.), rather than how long it takes to do it right.
Have you heard of the term technical debt? That’s what you get when you rush developers instead of giving them time to do it right. Quick and dirty is expected every once in a while, but they need time to clean up the mess. In sales-driven organizations, that rarely happens.
Unfortunately, piles of garbage can have pretty long shelf lives. Prohibitive sales costs keep out challengers, and customers rely too much on social proof. Waaay too much.
From a technical perspective, however, I have not seen a product recover from pile-of-garbage status.1 They become notorious among engineers. The problem you’ll have is that engineers aren’t terribly confrontational. Notice that I have not called out any bad actors. Engineers love the truth and want to be honest, but they’re unlikely to openly bash products, especially the ones paying their salary. The good ones simply find better work.
What to do?
I started writing a comprehensive list of questions you want to ask when choosing software. But I don’t want to mislead you into thinking a list of questions off the internet prepares you for shelling out megabucks on software, with answers from dubious sources. If you have a software development background, and bought that type of software before, and oversaw its implementation and use, you’re in good shape. Otherwise, hire a consultant. Doesn’t have to be me, just someone with that experience. Then get them
Then get them to act like a seedy private eye. Wine and dine developers to get them to open up about how much they enjoy the platform. You will be shocked at how many vendors you eliminate this way.
You can comment on Hacker News.
- If you have, I’d love to hear about it. [↩]