Still, if the original choice works and there is no real ‘external’ incentive to change it, then we tend not to. Until there is enough technical debt, the choice stays the same but the defensibility of the choice is considerable eroded.

I tried to explain my above rational once at an interview for a consulting job, only to have the interviewer (rudely) tell me that I was “wrong” (one should NEVER create their own database, ever).

I believe that nothing about software should be picked randomly (or by habit), but that doesn’t always mean that my rational for making a choice will remain reasonable over time. Sometimes I can’t defend myself (so I always try not to).

The changing requirements are something that completely changes a project. At the time it may have been completely reasonable, but if assumptions or requirements change, then your technical decisions may become an issue. Decisions need to take into account what purpose is as well. Internal applications have different restrictions that applications being sold as an installable product.

I once had an application that needed to be designed so that connectivity would not be required. As the project progressed, the basic assumption had changed due to some connectivity contract that was made. We had to change our design of a large portion of the project in order to work with the new assumptions. It happens.

When I started the project, it was going to be a stand-alone web appliance that operates outside of the normal IT infrastructure. Just plug it in, and it works. Because of this, I picked a custom data-persistence approach. I basically built a simple, but hugely flexible quasi-relational database that required absolutely no human management. Since the data itself was mostly read-only, not only did this make the solution super-fast, but it was also super-expressive (and very simple to build on), and super-reliable. It worked exceedingly well.

The product morphed into an enterprise-based software product, and the first question everyone asked was “What is the database you are using?” In those days, the mantra was “relational or death” (or something equally extreme), so every time I tried to explain how the database worked and that it needed no administration, I was often shouted down by IT insisting that I use their X-brand database. It was a sad introduction into how inflexible people could be.

From a commercial product perspective, it’s easier and way better to just go with the established technology of the day. It’s what they want, and it’s what they know (even though it might not be what is right). A crappy product that sells (unfortunately) is better than a great one that doesn’t.