Blog Post

You’re doing your POC wrong! : T-SQL Tuesday #152


It’s T-SQL Tuesday again! Deborah Melkin (blog|twitter) is our host this month and she’d like to hear our opinion. A strongly held opinion. Something we can talk forcefully about it. A rant if you will. A friend of mine pointed out recently that I can be a bit preachy here (they aren’t wrong) so this should be easy!

I’ve done more than a few rants in my time blogging. One more should be a piece of cake. Interestingly the day I read the invite we were discussing a POC (proof of concept) being done at my company. And me being me I started a bit of a rant, realized what I was doing, and that I was ranting at people that agreed with me and shut up. But, it did give me a good idea for this post 😁.

If your POC does not follow your companies best practices and standards then it is not a valid POC.

There are way to many settings that will change it’s performance, cause security issues, etc. On top of that, almost every POC I’ve ever seen ends up becoming the test environment if not the actual production environment. So all of those little compromises end up in your actual, non POC environment because it’s way too much work to fix them now. You should have said something when we set this up.

“Oh, this is just a POC, I don’t really need backups.” Six months later and the POC is now a production box and there are still no backups.

“Of course I gave the service account sysadmin. It’s a POC and I didn’t want to mess with security.” Six months later and the POC has been moved to a regular production box. “Hey, it’s crashing and says I don’t have sufficient permissions.” “No, I have no idea what permissions I need. Just give me sysadmin!”

“Why would I run the standard setup scripts? It’s just a POC.” Six months later “What do you mean the security updates aren’t being applied!?”

“For my POC I’m going to install Enterprise SQL with 128 cores and 4 TB of memory. That way I don’t run into any problems while I’m testing.” Six months later “Hello, this is the licensing department ..” “It’s going to cost HOW MUCH?!?”

“It’s just a POC, I’m going to put 4 cores and 16gb of memory on it. My test database is tiny.” 6 months later “What do you mean it’s crashing in production?!? It worked fine in all of my tests!”

Long story short, your POC should match up with the environment it’s going to be running in. That means follow the companies standards when creating a new machine, new instance, new database, whatever. So a) it actually runs the way you expect it to when it winds up on a standard environment, or b) in case this becomes the standard environment you aren’t scrambling to get things straight.

Thank you for coming to my Ted Talk.

Original post (opens in new tab)
View comments in original post (opens in new tab)


5 (2)




5 (2)