A common trend nowadays is to follow a specific development path, especially if your survival depends on it.
This can be applied in any aspect: personal, work related, professional, communal etc.
And why would it be different? For us as humans, having a goal seems to be the usual cure for boredom. (An old Chinese proverb says “Gods, please keep us from being bored!”)
Having a goal and an agenda is essential, but this leads to a few other fundamental questions:
- how do we start
- how do we get there
- and how long should / will it take
The big question usually is: how do we balance well enough our achievements?
If we think we are achieving too much, then we call ourselves overachievers and this brings us stress; if we achieve too little then we call ourselves underachievers and this also brings us stress.
This stress can be a positive thing or a negative thing, depending on who is looking at it. In either case, stress is tightly related to money (making it or losing it, oh well, these are the times we live in).
Let’s take the example of Microsoft and specifically of MS SQL Server.
Microsoft’s SQL Server is, in general, a product which is used for working with data. It is not the best product, and it is not worst. We should not even talk about ‘best and worst’, because different scenarios have their own requirements, and one product or another can have different perks or flaws.
But, from the other side, Microsoft’s SQL Server is one of the most popular products. And it definitely has the biggest (and the greatest) community.
The SQL Server community is a two-edged sword: it makes the product popular (which means increased sales), however the community also has demands for product improvements.
(And by the way, here is the main difference between open source products vs. non-open source products: the ease of pushing changes along.)
So, if we have a great community which gives free support and ideas and it also increases sales, life is good.
But if the same great community has demands, what should we do with them?
And here is the key question: what is the optimal development path speed for SQL Server as a product, so the maximum resources are utilized?
(Let me translate the question to simple English: how do we make most money?)
Let’s start with who is we:
- Microsoft and the sales department
- third party companies, providing services within SQL Server scope (companies hosting SQL Server databases, developers of 3rd party tools for SQL Server etc)
- third party consultants, working as SQL Server developers, admins, community members
- Microsoft’s own consultants (called PFE – Premier Field Engineers)
- and others
So, all of the above make a living out of SQL Server.
And, obviously, in the case of the disturbance of this micro cosmos, a lot of people lose money. In other words, the underachieving – just as well as the overachieving – in the development of the SQL Server as a product can mean huge losses for everyone.
Here is how (and keep in mind that this is a circle (vicious or virtuous?), so if your head starts spinning, just look away from the monitor or navigate away from this page):
Microsoft wants sales, third party companies also want sales because they make money from their products, consultants want sales because they make money after investing time to learn the product, PFEs make more money as well if the product is popular; the community members want new features to improve their daily work, new and improved features make better sales, but perfect product sells once, it is harder and harder to sell an improved product if the users already have something that is ‘good enough’, and go back to the start: Microsoft wants sales etc…
So, what is the answer? The answer is to ‘keep ’em coming‘. This is the oldest trick in the money-making: always leave room for improvements and don’t make a fuss about the bugs, but keep the audience hungry for new releases.
If you deliver a top product which has no bugs and no demands for future improvements, then you will sell it once and you as a vendor will seize to exist shortly after that.
So, what happens in the case of underachieving: the community shrinks, less third party products are developed, the sales shrink.
What happens in the case of over achievement: the community is happy, but shrinks (because of the lack of demand), the sales increase temporarily, but then drop, and almost no one is happy.
This is why SQL Server as a product has been evolving slowly so far. Not too fast, and not too slow. Just keeping the pace of the other products on the market combined with the customer demands, delayed with a few years.
And finally, let’s give some examples:
- extended events could have been easily released in a much better shape in SQL 2008. But it was strategically a better move to make a buzz about the feature in SQL 2012
- SQL Server has been using the functionality of resource pools internally for about a decade now, but the Resource Governor did not become available until SQL 2008, and still only in the Enterprise edition
- compression has been around for ages, but… same story as the Resource Governor…
- a demand has been expressed for at least a decade to be able to backup a database without backing up the non-custered indexes
- and so on
Anyhow, hope you feel better after this lesson from Economy 101.
Do not despair if you think that SQL Server is developing too slow or too fast.
The product is developing at its own pace, and there is nothing you can do about it.