Let’s Call It What It Is: Complexity Debt

Technical debt get deprioritized too often because business sees the word, “technical.” It doesn’t matter what the true meaning is. And it’s a big problem. It really needs proper governance to make it a priority.

“Lack of governance over technical debt is also a problem.”

Michelle Leroux Bustamante, .NET Rocks!

Reading through The Unicorn Project, which is a newly released companion to The Phoenix Project, I came across this great nugget that might help others view technical debt properly.

“I’ve started calling all of these things ‘complexity debt,’ because they’re not just technical issues—they’re business issues. And it’s always a choice,” he says. “You can choose to build new features or you can choose to pay down complexity debt.”

Gene Kim, The Unicorn Project

Yes! When we replace the word “technical” with “complexity” we reframe the discussion. That may help discussions about what to prioritize and getting what we call technical debt paid off in a more timely fashion.

Happy Thanksgiving

It’s Thanksgiving again here in the United States. Throughout the years, the IT community has been awesome. I have been blessed by you all. I can certainly point to milestones in my career and list the folks who have helped me get to each one. 

But outside of work and technology, there are some folks I first met in the tech community that have been there when I and my family needed someone. I’m not going to embarrass anyone, as I’ve thanked them privately over and over again. 
Thanks, all. You make this community fun and rewarding. 

Webcast Tomorrow: Building an Auditing Framework for SQL Server

Faced with auditing SQL Server on a regular basis with no 3rd party tools? Where do you start? That’s what this webcast is on. Come watch on October 13, 3 PM Eastern time. 

Webcast: Building an Auditing Framework for SQL Server
There will be some code samples, but this is about how to get started and what you need. 

Protecting Against Delete without Where

If I’m doing any manual work with T-SQL, I always begin every set of data change operations with BEGIN TRAN and I have the COMMIT TRAN commented out at the end of my script. Why?

Quite simply, because I’m wary of having a DELETE clause without a proper WHERE clause. I’ve made that mistake in my career and it’s easy to do if you are tired, pressed for time, or both. This allows me to verify I’ve only changed what I intended and then I highlight and execute the COMMIT TRAN to finish the operation. However, there have been times when I neglect this habit. 

Which is why seeing Steve Jones’ post about a new feature in SQL Prompt made me smile. If you have it installed and are about to execute a DELETE without a WHERE clause, it prompts you to verify this was your intent. As Steve writes, sometimes it is. But when it isn’t, that warning can be a life saver. 

I won’t abandon my BEGIN TRAN habit, but I will certainly take advantage of this new feature in SQL Prompt. 

Congrats to MSSQLTips on 10 Years!

MSSQLTips has posted about their 10 years as a resource to the SQL Server community. It’s where I do the bulk of my writing these days, mainly because I like the problem/solution format. However, the folks at MSSQLTips didn’t just write to acknowledge their 10th birthday. 

They also posted about donating to charities and making this a global effort with the hashtag #MSSQLTips4Change. MSSQLTips is donating $10,000 over the next year to various charities. They are hoping we as a community will also help spread word of these charities via social media. Also, if we feel inclined, to donate ourselves. 

The first charity has been announced: Soles4Souls. Please spread the word!

Cleaning Data

We spend a lot of time and effort trying to clean data. Anyone who has worked on ETL (Extract, Transform, and Load) has wrestled with trying to get good data for downstream systems. Maybe this sign is appropriate after all. 

Continuous Integration/Delivery without Testing!

Anything we can do to automate our builds and deployment should be considered. After all, the point isn’t just to write code, but to deploy working code. So what if we did the automated builds and deployed them to development or QA? No errors, so I’m good, right?

Not so fast. Go back to what Martin Fowler says about testing in continuous integration. Builds should be self-testing. For instance, simply deploying T-SQL code to a database without errors is not the end. That’s merely the beginning. At this point you know that there aren’t any obvious syntactical errors. That doesn’t mean the T-SQL code works according to specification. It doesn’t mean that a view that you didn’t drop and create is okay. After all, if you change the underlying objects, that view might not work any more. Testing the build is important. And having all the tests needed to sufficiently check out the functionality of the code is essential.

Actually, more testing should be done that just checking bits of functionality like we typically do with unit or module tests. At some point during the process you should also be testing in production-like conditions. Can you have Continuous Integration (CI) or Continuous Delivery (CD) without proper testing? No, you can’t. You can have something that looks like CI or CD, and you may even call what you have by one of those names, but you don’t have CI or CD.

The fact of that matter is that you want testing; actually, you want as much automated testing as is feasible. Speeding up the process doesn’t mean end users are suddenly okay with getting buggy code. And we as IT professionals shouldn’t be okay with that, either. We can still ship and test. We just have to commit to test. Yes, testing will add time to every build cycle. However, it’s a necessity for every build cycle if you’re doing builds right. Simply compiling the code isn’t adequate testing. It’s merely the first test of many more.

Previous Older Entries