Every software developer wants to work on challenging projects that expand their horizons. But it’s better to buy a wheel than reinvent it.
Charlie, a senior architect at a medium-sized software development organization, sat at his desk going over the specifications for the latest development project at his company. As he was taking a high-level look at how to break down the work for the first phase of the project, Janice, a hard-charging, early-career developer walked into his office.
Janice doesn’t hesitate. “Hey—I see that our new project is going to require some encryption. I’d like to take a stab at writing the encryption library for the project. I’ve been looking at various algorithms lately, and I’d like to give it a go.”
Charlie, of course, admires the enthusiasm, but knows right away that this isn’t going to happen.
“Janice, thanks for the offer, but I’m going to give you a flat no on that. And here’s why: Encryption is really hard. Encryption is fraught with peril. Encryption attracts all kinds of bad actors who will try to decrypt whatever it is that we are protecting. Any hole, any bug, any problem at all could expose us to huge security risks.”
“Okay—so why can’t I do it? I’m up to the challenge!”
“Well, with all due respect, you aren’t. Shoot, I’m not even close to being up to it. In fact, precious few developers are. See, encryption is one of those things that you absolutely, positively should leave up to the experts who have built public, well-vetted, battle-tested, open-source solutions. Encryption is something that needs to work perfectly, or at least as close to perfectly as the real experts can make it. The bad guys are just as smart and capable, and proven solutions are the only way to go here.”
“Hmmm. Okay, I guess that makes sense. But I still think it would be fun to do,” Janice said with a smile as she walked out.
But Janice’s enthusiasm inspired Charlie, and he got an idea. He walked to his boss’s office and sat down. She looked at him and said, “What’s up?”
“Allison, I don’t get to do much greenfield coding anymore, so I personally want to build the message queueing system for our new project. I know the classic ‘build vs. buy’ thing is always a tough decision, but I would love to take this on.” Charlie was feeling pretty good about the whole idea.
Allison sat back for a moment and looked at him with a slight smile. “I know how you feel, Charlie. It would be fun. But I’m going to give you a flat no on that.”
Charlie smiled inwardly at the irony.
“Look, I know you are good, but even you will have to admit that you aren’t that good. Message queuing is complex. Getting it right is tough, and optimizing that correctness is even tougher. There are any number of fully functional, complete, working, and proven message queues out there in the open source world. Sure, you’d probably get something working, but we aren’t message queue experts around here. It would take a very, very long time to make sure that you covered the entire surface area of the requirements, and even then, we wouldn’t be completely sure.”
Charlie nodded his head knowingly, admitting to himself that she was right.
“And then, when a bug is found, we have to fix it. That’s expensive. And the unknown unknowns of doing it are, well, unknown, right? If we go with Kafka or RabbitMQ or a commercial solution, we know that it will work right the first time. They’ll fix bugs and stop leaks before we even know they are there. I’d much rather you spend your time working the guts of our application. You’ve been here 14 years, and you know our business and our code base inside out. I know you’d love to do it, but I just can’t let you take that time. And I think even you’d admit that the risk and the downstream costs are just too much.”
Charlie sighed. “Hmmm. Okay, I guess that makes sense. But I still think it would be fun to do.”
You can’t blame Charlie and Janice. Everyone wants to work on challenging projects that expand their horizons. And its tempting to think that they are smarter and can do a better job than some company with a generic SaaS solution. However, ego-driven programming rarely ends well.
Even an expensive subscription to a solution written by a team that knows the problem domain inside and out and that has the core competency and motivation to provide a complete solution is almost always going to cost less in the long term than the unknown cost of building and maintaining your own solution.
Unless there is a very compelling reason to build your own solution, and you’ve done the due diligence to make sure that the available solutions truly won’t fit your needs, deciding to build and not buy will almost certainly turn into an unexpected splash in the dunk tank.
