I’m now at downshiftdata.arksoftware.net!
In the past couple of years, I’ve had the opportunity to speak at a few SQLSaturdays, and presented to my local chapter, IndyPASS, a couple of times. I gained a new experience a few weeks ago, one that I had no idea would be so timely. I presented one of my sessions to YooperPASS, a new chapter in the upper peninsula of Michigan. This session was my first online session for PASS. I’ve presented online before at Salesforce, but that was to an internal audience. This was a new session, presented for the first time, to a bunch of strangers. Fortunately, the YooperPASS folks are very welcoming, and I think it went very well.
I mentioned this was timely, though, didn’t I? Well, that’s because I’ll be giving my second ever PASS virtual session on Thursday, the 20th. I’m a part of the 24 Hours of PASS: Summit Preview 2017! The same session I gave to YooperPASS, A Guided Tour of the SqlClient Namespace, will also be part of this webinar event. Because I’ll be presenting this session to a much wider audience now, I’d like to expand on my approach to this session.
First, I call it a “Guided Tour” because I’m cherry-picking those areas that I think deserve some special attention. A more comprehensive session would be impractical. So I had to cut things off somewhere. What made the cut are four topics that have valuable specific takeaways. A good technical session should give attendees something today they can put into practice tomorrow. I’d like to think I accomplished that with these topics.
Second, my choice of topics also gives me a chance to get across a broader message about how to scale ADO.NET code. Performance is always a focus of mine, and my experience has taught me that there is frequently a trade-off between application code and the database. One piece of code may perform better than another under a microscope, but its effect on overall system performance may actually be worse. In this session, I try to draw attention to this trade-off.
Finally, this is my attempt at an introductory session on an often-overlooked topic. Let’s face it, ADO.NET has been around a while. Because of that, I think the information available on it is inconsistent. StackOverflow didn’t exist until long after ADO.NET was introduced. Yes, there are some fine older resources on ADO.NET, but enterprises have changed a lot since many of them were written. Most current resources focus on Entity Framework, which is arguably just an abstraction layer over ADO.NET. So my session is intended to close the gap.
Anyway, I’m looking forward to being a part of this 24 Hours of PASS. If you tune into my hour, I hope it’s worth your time.
This is what I get for slacking off on my blogging…
So, I totally missed this month’s T-SQL Tuesday. Which is a shame, because it’s an area I have a lot to talk about. Grant Fritchey hosted T-SQL Tuesday #91, which is all about DevOps. There were a lot of good posts. I liked Rob Farley’s comment: “DevOps is the idea of having a development story which improves operations.” Andy Yun had a nice take, closing with “This is what I believe DevOps is all about. The tools and processes being pioneered today help all of us build better, more stable software, which is better for all of us.”
My own personal experience with what I think of as DevOps took a big leap about a year and a half ago when I moved from a product group in my organization to a development-oriented team inside our operations group. That transition both confirmed and challenged an observation I’d made years ago.
My observation was that organizations are all on a track between two extremes. On the one extreme is the legendary “two guys in a garage” story. On the other is a Fortune 500 conglomerate, doing business in tightly-regulated industries. In that garage, Woz was free to design and innovate at will, and what he produced is now the stuff of legend. Apple, on the other hand, delivers a new product only after a monumental expense of time and resources. They still produce remarkable products – one cannot argue with the massive success of the iPhone and its successors. But how those products come to market is a far cry from that Homebrew Computer Club meeting in ’76.
The critical piece of this observation is that all organizations move from the former end of the extreme to the latter. They may move at different rates, even coming to a stop for any length of time, but they never go the other direction. Let me repeat that: They never go the other direction.
Let’s think about database backups as an example. Garage organizations may not do any backups at all. Then something gets lost, and perhaps a weekly full backup task is scheduled. The system grows and taking a simple full backup once a week no longer scales properly, so a better schedule is created, with more particulars about what is backed up, when, and how. This process keeps getting refined, until, one day, there is a standard procedure for performing backups, including off-site storage, regular testing of the restoration process, and all kinds of other aspects that operations people in Fortune 500 companies have to think about.
Many of us are quick to claim that the Garage is better. We love the folklore around how Apple (and other companies like it) got started. We love to reminisce about those times that we turned caffeine into code and all was right with the world. It’s just something about being a coder. But that’s not universally true. Would your organization be better off without a good backup restoration procedure?
The problem is that – good or bad – the processes pile on. Bad or obsolete procedures never get removed, just marginalized until they become an indistinguishable part of the Fortune 500’s ecosystem.
I help administer a database that does not need to be backed up. Yes, that’s correct. It does not need to be backed up. Ever. It’s a data warehouse, of sorts, that is populated by a convoluted ETL process originating from log files. Due to both size and the diminishing value of old data, we only keep data in this database for a short time. If we were to lose the database, we would recreate the structures, and then “re-dump” the log files into the ETL source folder, and let the process churn through them again. That method of recovery would only take marginally more time than restoring from backup. By the way, for this database, the backup process itself is a serious drain on system resources.
Getting our operations group to STOP backing up this database was an adventure, because of all of the procedures in place to ensure that every database was properly backed up. At one point, because it was causing a production issue, I disabled the backup job (thereby curing the immediate issue). For my quick thinking, I was rewarded with having my SQL Agent rights revoked.
Anyway… the moral of my story is that the situation gets more complex over time. Once again, it never gets simpler. At least, that was my theory.
To me, this is precisely the point of DevOps: The ability to go backwards on this track.
Now, here’s the hard part. To do this – to move towards the Garage end of the track – takes people who understand what is important and what isn’t. You can’t trim excess process at whim. You have to know what should get trimmed and what shouldn’t. Because you’re removing processes that protect the organization and limit risk, you need smart and organized people who will do the right thing without a process directing them.
DevOps is all about the people. It takes good communication. In his T-SQL Tuesday post, John Morehouse emphasized it with his call to “Start talking.” David Alcock joked about Dev and Ops going to “couples therapy” (and did indeed make a good point). But it’s not just good communication. It’s good people. For DevOps to work, DevOps people must be smart about what they do and don’t do. And then, if they’re successful, they’ll do what I didn’t think was possible – move from the Fortune 500 end of that track back towards the Garage.
As long as they don’t get their SQL Agent rights revoked in the process.
As I mentioned before, I’ll be touching on a few marketing topics over the course of the next several weeks. Taking a top-down approach, I’m starting with the question, “What are you known for?”
I hang around the IndyCar paddock whenever I can, which isn’t nearly as often as I’d like. At the St. Pete race one year, I remember listening to one of the team PR people talking about how to get into her line of work. I think it might have actually been a Pirelli World Challenge team rep, Kelly Brouillet. She said something like, “Do one thing really well. If I have a go-to person for one thing, that’s worth a lot more to me than someone who knows a little about a lot of stuff.”
She’s right. As I’ve progressed in my career, I’ve noted who the experts are. I tried to do something in PowerShell a little while back, and turned to Mike Fal when I got stuck. When I’m trying to figure out the right direction to go with a columnstore issue, I look up what Niko Neugebauer has to say on it. The reason I was listening to Kelly that day in St. Pete is because she’s a lot more savvy about marketing and PR in the racing world than I am.
Brent Ozar, one of those high on my experts list, had a session at the Summit last year, on the Professional Development track. He called it a “500-Level Guide to Career Internals” but it was really a wonderfully personal “How did I get here?” talk. One of the things he stressed was a consistency in message:
See a trend? Being known for making SQL Server faster and more reliable is Brent’s desired brand identity. BrentOzar.com is where I go when I have general SQL Server performance or reliability questions. It’s often the first place I go. Once I gain a little insight there, I might dig deeper elsewhere. Brent is very good about pointing people to experts in the field, who have a deeper but more narrow focus than he does. As for myself, you’ll find the phrase “fast and efficient SQL code” peppered throughout my online activity. I’m competent at quite a few things, but I’d like to think I really shine at that.
As the communications director for the IndyCar Ministry, it’s my role to get the message out that we are “dedicated to providing spiritual support and counseling to the IndyCar Series drivers, teams, and staff.” But what are we known for? That’s a tough question, actually, and one I’ve been wrestling with. “Being there when needed,” has come to mind. I’ve often joked that IndyCar is a traveling circus. The paddock is very close-knit, and rightfully so. Having chaplains who are inside that paddock, not just logistically, but emotionally as well – that means a lot. It makes the difference between whether or not someone will open up about a problem in their life. In any case, I’m still working on this one. In part, it’s actually what prompted this post.
In a similar capacity, I help Blue River Soccer “provide recreational, competitive, and educational soccer opportunities for the youth of Shelby County, Indiana.” Our tagline, which plays on what we’re known for, is “Ignite the dream. Launch the evolution. Respect the match.” We recognize that soccer is still in a transition period, at least in our area. So we set our sights accordingly. We try to give kids a passion for the game, give them the fundamentals, and set them up to move the needle forward – be better prepared to pass the game on to their own kids. Frankly, we’re not one of those associations with thousands of kids, paid coaches, and a big-time travel program. We’re known for being a place to which parents can feel comfortable bringing their kids, regardless of what they know about the game coming in.
It all comes back to that question. If you’re promoting something – yourself, your company, your product or services – you have to answer that first. So… what are you known for?
I write software for a living, and my posts are generally about topics that I think are useful to other people who do the same. This is the first in a series that is a slight diversion from that. I say ‘slight’ because I think the core concepts of good marketing are useful to everyone in the business world, regardless of your role. Follow along, and I think you’ll soon agree with me.
I think it’s worth explaining where I’m coming from first. I am not a professional marketer. Like I said, I make my living writing code. But I do have some experience in this area, so let me tell you about it.
I started as a software developer at ExactTarget in 2008. ET was a marketing company in Indianapolis that was eventually acquired by Salesforce to become the bulk of the new Salesforce Marketing Cloud. I still work for Salesforce, now in more of a DevOps role in the Marketing Cloud.
Anyway, one of the benefits of being an employee at first ET and now the Marketing Cloud is the opportunity to sponsor a non-profit organization’s use of a free account on the platform. I took advantage of this years ago to help the IndyCar Ministry with their communication and funding efforts. The chaplains of the IndyCar Ministry serve the spiritual needs of the IndyCar paddock, as well as that of the Mazda Road to Indy ladder. IndyCar is a “traveling circus” of sorts, and having chaplains present to counsel and listen and minister to them is more vital than one might think. But doing so takes money – note the “traveling” part of that phrase – and that’s where I come in.
So I use the Marketing Cloud, as well as other tools, to help the ministry communicate with its supporters and spread the word about its efforts. I’ll be frank – I’m no marketer, at least not a paid one. I write software for a living. But I write software for a marketing company, and I’ve been helping the ministry for a long time now. I’ve been picking up some experience and expertise here and there over the years. Like most of life, this generally means the test comes first, followed by the lesson (expect an embarrassing post or two in the near future). But, as I often point out to the chaplains, I’m worth every penny they pay me!
Anyway, over the coming weeks, I’ll be sharing some of those things I’ve learned. Whether or not you realize it, chances are good that you’re actually a marketer too (and that itself is one of my upcoming posts). I hope I help you become a better one.
I’m at another SQL Saturday again this weekend, this time in Phoenix, Arizona. I’m looking forward to meeting the Arizona SQL Server Users Group folks and being back in the Phoenix area for the first time in over a decade.
Since Microsoft was kind enough to open up compression (along with a host of other features) to all you non-Enterprise plebes with 2016 SP1, I figured I’d bring that session back out again. And after some recent adventures with partitioned tables (which I STILL want to write about in more depth here!), I’m also presenting a new session on querying against those.
A while back, I wrote an app that spawned a collection of threads to run some work in parallel, using the resources in the System.Threading namespace of the .NET Framework. Some time after that, I worked on another app that also had a threading component. This second app was reviewed by another developer from outside my immediate circle. He asked, “Why didn’t you use the System.Threading.Tasks” namespace? Uhh… because I didn’t know it existed?
That namespace was introduced in .NET Framework 4 – not exactly recent history – but I had somehow missed it for quite a long time. There are a few causes for that, but the one I’d like to focus on here is a trap that I think catches many developers at one time or another: We think we have it all figured out. While we are, to some degree, practical mathematicians – professionals who assemble algorithms to meet requirements – we are also creators. Our code is our art. And oftentimes, we don’t have the humility necessary to accept the possibility that our art isn’t beautiful. So we shy away from having the right people check our work.
This reminds me of an old saying: If you’re the smartest person in the room, then you’re in the wrong room.*
Now, this is not a commentary on my current team. I work with some really smart people, and I’m very grateful for that. But while my teammate may be one of the best PHP or Node.js coders I know, that doesn’t necessarily translate to an expertise with the .NET Framework. The true test is this – no matter how smart they are, if they’re not catching my mistakes, then I’m not being held accountable.
Lesson 1: Make sure someone’s catching your mistakes. If they’re not, then do you really think the reason is that you’re not making any?
So, back to the two apps… After the other developer’s feedback, I reworked the second one prior to release, and it passed its code reviews. The first app, meanwhile, developed some bad behavior in production. There was definitely a race condition of some sort, but I couldn’t seem to nail down where it was. I made a couple of adjustments to the code, but nothing seemed to bite. Of course, I couldn’t reproduce it in testing either.
Finally, I ripped out the threading code entirely and replaced it with nearly identical code based on System.Threading.Tasks. I was concerned about the risk of introducing more bugs, about the fact that I was still unable to reproduce the problem, and about how long it had been a problem, so I tried to remain as faithful to the original design as possible. And, yeah, honestly, I crossed my fingers.
Once this new version was released, the problem was gone.
Lesson 2: System.Threading.Tasks really is better than System.Threading.
I’ll never know what exactly fixed the problem. I could keep researching it, but the costs to me for that aren’t quite worth the benefits at this point. My takeaway was that the new stuff just simply works better. Whether that’s because it’s easier to use the right way (and harder to use the wrong way) or its internals are less buggy or some combination thereof, the end result is the same. I hope that’s old news to anyone reading this, but I wanted to share my experience just in case.
* I was unable to identify with certainty the source of this phrase. The leading candidate I found was 1962 Nobel Laureate James Watson.