Opinion: Don't reinvent the (database) wheel
There is an old saying about not reinventing the wheel yet this is something that I see happening at client sites every day. I see two main reasons why this happens:
Discoverability
[caption id=“attachment_2809” align=“alignnone” width=“339”]
Image by Nathan Dumlao[/caption]
There are so many tools and frameworks in this industry, that you can’t be expected to know them all. I remember when I worked a lot with the .NET framework. I’d go into client sites and see them designing and building classes that were already in the framework. Worse, the framework classes were usually very well designed and tested.
The challenge was that with thousands and thousands of classes (at release I think .NET was over 6,000 classes), it’s hard to know what’s in there.
[caption id=“attachment_2810” align=“alignnone” width=“469”]
Image by Rafael de Nadai[/caption]
I see developers working with SQL Server and creating tables to hold queues. A table seems the natural way to store queue data but the problem is that it doesn’t have many of the semantics that are needed for a great queue.
When I describe Service Broker, the developers are often very surprised to learn that SQL Server already contains a fully transactional queue, already there, right in the database. Often it has all the capabilities that they are trying to implement themselves.
More importantly, Service Broker includes support for things they hadn’t even considered. Building a queue sounds simple, but it really isn’t.
For example, if you take an entry off the queue, try to apply it, and the transaction rolls back, what happens next? Does your application just stop? Does it try to take the entry off the queue and apply it, only to go bang again?
Service Broker includes poison message support. It lets you control what occurs.
The biggest problem I’ve seen with Service Broker is that Microsoft promoted it to database people, as it was part of the database. That’s completely the wrong target market. It should have been promoted to developer leads and technical architects. I think the marketing for this was completely misdirected.
Not Invented Here
[caption id=“attachment_2811” align=“alignnone” width=“383”]
Image by Roman Mager[/caption]
The other common reason that I come across is the “Not Invented Here” syndrome. There are clients who simply won’t ever use code that someone else has created. They are usually concerned about one of these:
- Takes too long to learn
- Won’t do exactly what I want
- Don’t want a dependency on it
I can’t always dismiss this but I do note that the same people won’t write their own database management systems or operating systems. (Although I think many of them would prefer to if they had time)
The problem with this is that the outcome for their own clients is usually substandard, and worse, their products are likely to become noncompetitive.
For example, you can write your own reporting system and/or dashboard system, but you’ll probably get a better outcome if you use Reporting Services and/or Power BI. I’ve seen some of my own clients write their own reporting systems, but they are extremely low-functioning, and are generally unable to be integrated with any other tools that their customers use.
When you are starting to create new functionality, at least please consider that what you’re after might already exist, and in a better form than you would ever have time or experience to create.
2018-03-06