A teams maturity shows in its choice of tools.

I have seen quite a few different development teams in wildly different environments and the single fact that really stands out is that you can tell how good a team is by the tools that they use. It isn’t always the specific choice of which tools they use, although that can be important, it is the fact that they evaluate and chose to either use or ignore new tools.

This is basically my personal maturity model for sql server developers, I think it is quite important because it is a measure of effectiveness of a team. It should be pointed out that some teams have no need to be effective whereas other teams are vital to how an organisation runs.

If we take a few examples, the first shows where a team has no need to be mature at all:

Team one, no one cares

Team one supports a vendor supplied application and the database is SQL Server, the vendor supplies an upgrade script to run every 3 months and the team is not allowed to make any changes to the application. In this scenario, there isn’t really any benefit in the customer having the database in source control - any problems are dealt with by the vendor and any scripts can equally be run in SSMS or sqlcmd.exe or a custom application. Even though the application is critical, the vendor supplies all support for the application and the team just need to keep it updated.

The second one, is a team that is important.

Team two, everyone cares

Team two develop and support an in-house electronic medical record application. It was first written in the late 90’s and has evolved to a include a number of SQL Server databases and .net services. All the code from the .net services, the databases and the tooling that the developers use is critical and hacking together a release is not going to wash it when a nurse might not be sure if something needs to be adminstered to a patient or not.

Team three, not critical but the team care

Team three develop a website that generates revenue for the company. Revenue is the most important factor but the team has good people in it who care and want to do the right thing for the company, not at the loss of revenue but with the idea to increase revenue and deployments.

Maturity Levels

OK so this is pretty simple, we have these levels:

• Low
• Medium
• High

Wow. Just WOW

That is an amazing list, how did you come up with it? Did it come from some phd study on the effectiveness of lists in the internet age? No.

So a little more detail…

Low

The low maturity team is one that uses basic tools or no tools at all. They probably do all their development in SSMS without any of the refactoring or intellisense helpers that are available. If they do use source control then their database is not likly deployable in any form just purely from source control.

This could well be perfect for team one, there is literally no need for them to spend any time on anything that other teams might require as an absolute basic. There is nothing wrong with this if the development and deployment is genuinely not important.

If you have a database and you don’t care about it then the best maturity level for you is low. Don’t feel bad about it, it is awesome in its own way and we love awesome.

Medium

This is where it starts to get a little bit exciting, the team probably has some tooling - they might have sql prompt for ssms or use another ide like jetbrains datagrip. For deployments they could use a tool such as redgate readyroll or perhaps they have written their own deployment tool.

Why is ready roll in the Medium maturity level?

The main reason is that in a medium maturity team deployments, both creating and managaging them are critical to how the team develops and deploys changes. Readyroll helps teams to generate deployments, it is a tool to manage changes and deployments.

Thinking about deployments and having deploying changes is not necessarily a bad thing - if you are not team one then you should absolutely be thinking about deployments and if you did have a low maturity it is a great step to getting more mature in your SQL Server development.

Why is datagrip in the Medium maturity level?

Ok, since you ask - if it was another database then I would put it in the advanced section but the tooling for SQL is great so unfortuntly it goes into Medium. If there was a genuine reason why a team used it I would be tempted to throw them a High maturity level bone but no guarantees.

High

For a high maturity team I want to see good IDE’s being used - so SSDT or datagrip or something similar. It doesn’t have to be SSDT but if not then there needs to be a valid reason why. I also want to see code checked in (not changes checked in) and then the code being built, tested and deployed either straight to production or possibly prepared to be deployed later. If it is to be deployed later I want to see a plan in place that will get them to continuous deployment.

Where do teams two and three fit?

I would hope between Medium and High - if not you have to ask questions as to why not. It is 2017 and there are pleanty of resources available out there.

Show me a chart

This is really begging for a cool matrix helping people show what all the criteria are (there must be more of course) and where they fit, but hey, this is a low-medium maurity blog so maybe one day in the future.

---

Comments:

Peter Schott

April 25, 2017 - 16:47

I generally agree, but SSDT

I generally agree, but SSDT has some real concerns when you have to support giving this to clients. DB Refactorings alone make it painful for use. It’s great for CI/CD work when you control the DB and releases, but having to know the current customer version and work them up to your current version makes this a more painful process. Either you have to increment them through releases, which defeats the purpose of SSDT’s design, or you have to know what version(s) contain those refactoring scripts so you can run those separately or otherwise work around them. I’d love to be able to use SSDT but can’t count on our customers being on a given version to ensure smooth upgrades. :( As such, tools like ReadyRoll are my next best choice.

Ed Elliott

April 27, 2017 - 21:46

Yes! I think that you need to

Yes! I think that you need to allow room to say “we evaluated tool x but went with y because…” and that would help guide the maturity level :)