In Seattle today, delivering two talks, so you get a republish of Data Breach Danger.
Category: Editorial
-
Wasted Work
I’ve been re-reading some of the manufacturing and DevOps books that I’ve collected over the years. In these texts, there are a number of concepts that stand out, but one that resonates with me is the concept of waste. There’s actually a good article on LinkedIn about waste that’s worth reading as well. While it’s easy to start spinning in circles and thinking everything is waste around you, step back and keep some perspective that some waste is inevitable because the world is messy. Don’t get too caught up in waste, but try to reduce waste where you can.
One of the areas that I think contains a lot of waste in software development is the effort to build features that won’t be used. Like many of you, I have been asked for no shortage of changes to software in the past. Often those changes require both application and database changes, usually to support a new way of conducting business.
The interesting thing to me is that often I’ll work my through a queue and get changes completed, a percentage of which rarely, or even never, get used. What seemed like a good idea when it was requested, specified, and scheduled may not be a good idea weeks or months later.
In other cases the latest request is labeled as important and needing to be completed ASAP. This might displace older work, perhaps even pushing it to the lowest priority level where it may never get completed. That’s fine, as if the work isn’t important enough to be pushed by someone, perhaps it isn’t needed.
To me, this is one of the advantages of working in a DevOps style flow, with small changes being developed and released. If clients start to use the feature and need additional development, we can continue to enhance the feature. If the users don’t use it, which we know from either future requests or instrumentation (the latter is preferred), then we can put more effort into the areas that are more important to our organization.
With less waste.
We don’t work on large projects to completion, wasting work on the parts of projects that will not be used. Instead, we complete small parts and keep shifting our focus to the areas that are most important to clients.
Steve Jones
The Voice of the DBA Podcast
Listen to the MP3 Audio ( 4.7MB) podcast or subscribe to the feed at iTunes and Libsyn.
-
Break Problems Down
Recently I was pouring over a few questions in the forums and noticed something that I would think is obvious, but apparently it isn’t so for other people. A poster was attempting to run a query across multiple databases and needed help structuring code to work in the context of each database. The poster was going back and forth a few times with others that were attempting to help them, struggling to get suggestions implemented into their code. That’s typical, as someone that needs an answer often doesn’t understand the solution and is learning. In this case, I found that the original poster was losing some of their troubleshooting skills in the process.
Years ago I read a piece on Simple Talk from Kathi Kellenberger. She is now the current editor of the site, but at that time she was just a SQL Server MVP and expert that was looking to help others learn more. The article was called Solving Complex T-SQL Problems, Step by Step, and it stuck with me. There wasn’t any knowledge that I didn’t know, but it was an organized explanation of the Kathi’s steps that I found refreshing. This was a nice reminder to me to not move too fast, but ensure that I really understand what the problem is and work in stages.
I’ve certainly been guilty at times of moving too fast and glossing over some details. That might be fine in some cases, but if I produce code that’s doing that, likely I (or someone else) is going to be rewriting code later. That’s not what we want to do, especially if this is a logical error. I might understand some less than optimal code from a performance perspective, but there shouldn’t be logical errors.
In this case, the poster had incorporated some changes into code and kept running the entire script, getting bad results. They even started to pinpoint a few areas where data wasn’t correctly being returned, but couldn’t solve the issue. This was a somewhat complex script, and it could be easy to miss some mistakes. This was also a dynamic SQL script, which often means that we have to extrapolate from our code to understand what the engine will actually execute. There’s often a simple solution to help you break the problem down: use PRINT.
I’ve done this for most of my career, in many languages. Even today, I sometimes use this in PoSh to ensure that I’m not missing something being done. Watch windows and other debugging tools are great, but they sometimes are more difficult to understand when there are long strings of data. Print often simplifies the process.
No matter what tools, languages, problems, etc. you are working on, breaking things down is often the best way to tackle a complex task. You might be surprised how much clarity this can bring to a tough problem. Even if you need to ask for help, having a list of things you’ve tried, and some data on the results is very much appreciated by those you ask. That way they know what you’ve tried and what to recommend.
Steve Jones
The Voice of the DBA Podcast
Listen to the MP3 Audio ( 3.9MB) podcast or subscribe to the feed at iTunes and Libsyn.
