How Long is Too Long?

After SQL Bits this year, there was a discussion on Twitter about the length of the sessions and what attendees would like to see. The event ran 50 minute sessions, and that wasn’t appreciated by some speakers. It’s an odd length, and one that few events use. Even SQL Saturdays often do at least 60 minutes, though often I find larger conferences do 75 or 90 minute lengths. In response to some of the debates about short vs. long sessions, Brent Ozar Unlimited is running a poll as well. I’d encourage you to participate and help shape how conferences structure their schedules.

I’ve somewhat argued against the shorter session for a conference, or really, at SQL Bits, because the short length is disruptive for me. I’ve got sessions I’ve prepared and given elsewhere. Some I’d like to give at Bits and some I’d update and adapt for the event, but cutting down from a 75 minute talk to 45 or 50 minutes is quite a bit of work. I know because I had a session last year that was accepted at multiple events. I had to give this in 30 minute, 60 minute, and 75 minute lengths, which was a challenge. I ended up building the 75 minute version and cutting things out, but it felt like I lost some flow and continuity at the different events. I think this was because it is just hard to practice different lengths and deliver them well.

That’s me, and I’m a speaker. If I want to present, then I need to adapt, so some of my argument is because I would like to avoid some work. I practice sessions many times and work hard to build a smooth flow that attendees follow. Changing lengths means more practice for me. I’ll do it, but I’ll also think about skipping events that use weird times. 60 minutes isn’t too hard to get to from 75 minutes, but I still find myself rushing at the end. I know trying to fit down to 50 minutes would be hard. I definitely see lots of speakers that struggle to get their talk going, and often run out of time, which I think gets worse with shorter time frames.

For the attendee, I have a different view. I actually think that shorter is better. At our SQL in the City Streamed events, we’ve experimented with sessions at 25, 35, 45, and 60 minute lengths. I like the shorter ones, which are more focused, and I do think that we can focus down on a topic more tightly in a 30-45 minute session. Strangely enough, I find the 15-20 minute sessions the hardest to build, often because I feel I have to jump right into the topic and the demos have to be very tight and reliable.

SQL in the City Streamed, however, has no audience. No one to ask a question or slow the session down. Also no feedback to understand if I’m losing people because of a poor explanation. In a live event, I find that my pacing will vary slightly as I take questions or elaborate on a point. The shorter the session, the less time for this, but perhaps that’s fine. Questions can be handled later, or maybe even submitted to speakers who can publish answers on their blog or an event site.

We deal with a lot of complex topics in technology, and I’d agree that many aren’t handled very well in short sessions, but I also think that complex topics aren’t handled well in 90 minutes either. Going to shorter session lengths means more slots during the day, maybe even more networking, and perhaps best of all, more breaks to stand up and move. If I were designing the ideal length, I do like 50 minutes, with a 10 minute break every hour. If a speaker needs more time, then build a 100 minute session and present in two parts, still with a break.

Selfishly, I like longer sessions as a speaker where I can dig into topics and spend more time explaining concepts, demoing solutions, and developing a pace of delivery. As an attendee, I prefer shorter sessions, but I do expect more effort from speakers to be on point, have demos that flow smoothly and quickly, and don’t waste time on items that the audience should be expected to know. However, I’m also a member of the community and I’ll work with whatever decisions conference organizers make. I’d just prefer they stick close to each other with similar session lengths.

Take Brent’s survey, but let me know in the discussion here what you prefer and why? Should you get shorter, more tightly focused sessions? Think about something you’ve seen recently and how it would be if you cut the length down or made it longer. Would the talk have been better or worse?

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 6.7MB) podcast or subscribe to the feed at iTunes and Libsyn.

Posted in Editorial | Tagged | 3 Comments

The Soft Skill of Respect

When I started to work more closely with the product development teams at Redgate Software, I found it interesting that we devoted so many resources to user experience, testing, and other non-development tasks. Coming from more focused groups, this was new to me. At times this felt like an indulgence, and at times a lot of overhead that slowed down the coding process. Over time, I’ve grown to appreciate having different skills in our teams.

Not that we build software in the best way possible, and certainly not the quickest, but we have some well coordinated and knowledgeable teams. We’re still evolving and learning how to put together teams of people and effectively build software, but I think we’re moving in the right directions.

As soon as I read this piece on hard and soft skills, I thought of Redgate and all the non-coding people that build our products. What struck me was how often I’d devalued non technical skills, but the more I work with our (and other) software, the more I appreciate that those other roles are important. The piece rambles and wanders around the point, but I do see that there are a couple important takeaways I get from this.

First, we need to respect others that perform different work from us if we are going to build synergy in our teams. The synergy is creating something that none of us could do individually, or even separately. We get more done by working together and that means we must be a team. Teams only come from respect between individuals, and that includes the managers.

The second thing that I realized, is that it is important to understand a basic level of what other jobs entail. Too often we data professionals have been upset that application developers don’t know more SQL. Many of us learn some of the domain specific knowledge of the data we deal with, in order to talk with customers, produce reports, etc. Following our own advice, we ought to know more about the development platforms, the challenges, their testability, and more, if for no other reason than we can better understand how the entire system works and can talk about it with others

I certainly know that relationships and people are incredibly important in larger projects, which is another important takeaway from the article. We all do need to improve our hard skills, learning to code more efficiently and securely. We also need to remember the importance of softer skills, and the need for a wider variety of skills in our teams. A little appreciation for the need for more than expert level coders might help us create better teams that function more efficiently and help us produce better software.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 3.8MB) podcast or subscribe to the feed at iTunes and Libsyn.

Posted in Editorial | Tagged | Leave a comment

Dealing with Technical Debt

Stop for a minute and think. How much technical debt do you have in your code? Let’s make this easy, take a break from this, close your eyes, and take thirty seconds or so and think about just your code. How much would you rewrite or redo if you could?

Now, stop and think for another minute. How do you measure the amount of debt? What’s your metric? Leave a note in the discussion after you finish this and let us know.

There’s an article from a project manager about technical debt and how his team decided to measure this in their organization. They actually set a series of metrics for things they cared about and assigned an actually dollar, well, pound sterling, value to each. They then totaled these for all projects and came up with a total debt number. They then track this, incurring new debt or paying off older debt over time.

I think that’s an interesting idea. I don’t know that the debt needs to be money, but I do think money is a little better than some abstract metric like tickets or requests. Money is something many of us are familiar with and we hold debt. Assigning a concrete value does let us measure where we stand in a way that we can better relate.

Just like financial debt, not all technical debt is bad. Sometimes debt lets us get more things done sooner than we might otherwise be able to do. We do need to take shortcuts at time in development to get a prototype working, or deliver a feature or meet some other goal.

It is easy to overdo things, and just like with finances, overextend ourselves. Paying down that debt can prove to be a struggle in both cases, perhaps even crippling our ability to tackle any other projects.

If you think about technical debt now, do you view things differently? Do you have a measurement system? Can you tell if your incurring or paying down debt? It might be valuable to implement something and ensure you don’t keep building up more than you can handle. It might even be something to show your manager and get some time to fix a few bugs.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 3.6MB) podcast or subscribe to the feed at iTunes and Libsyn.

Posted in Editorial | Tagged | Leave a comment

Badly Encrypted Databases

I ran across a blog about encrypted databases linked from Bruce Schneier’s blog. I follow his musings and writings on security ,and he recommended we read it with this sentence: “Even the summary is too much to summarize, so read it.” Good enough for me, so I clicked the link and read about encrypted databases.

I like the idea of stronger encryption in databases, and I’ve given a few talks on the subject. At times there are attendees that will debate that encryption in the database doesn’t do a lot of good. Often they dismiss the idea of TDE, since administrators can still read the data and break the encryption, and normal users aren’t affected. Many also note that database encryption does nothing for data on the wire, which is true. Most people want to do the encryption and decryption on the client, which has other challenges and is fairly hard to do well.

I think that security a series of layers, and as noted by the author of the blog, most criminals are lazy. If they can copy a backup file or data file, they’ll just do that and read the data. TDE isn’t perfect, but it does limit these simple attacks. Always Encrypted was developed to try and make it easy to include encryption from the client side, but in SQL Server 2016, it has lots of limitations. In SQL Server 2019, we get secure enclaves, which should help adoption somewhat, but we will see once developers start to experiment with the feature.

The blog talks about problems with encryption, spending quite a bit of time on approximate database reconstruction, which is essentially guessing data values with some information and by watching queries and results. It’s somewhat fascinating, and also scary, but complex and likely requiring lots of queries. To me, this is an area we ought to focus, and really an area that all our protocol libraries and possibly database firewalls (or built in limits) ought to focus efforts. We shouldn’t be most clients to make large queries of all data in a table. Really at this point, we ought to have build in limitations of queries to ensure that users are exporting all data from a table. I’d like some throttle that might prevent the return of very large result sets to clients.

At the same time, there ought to be some way to analyze the queries coming in and see if an attacker is “guessing” values. I won’t pretend to know how we might do this, but it would seem that in the same way we detect lots of login attempts, we could have some alert being raised when we had xxx of the same type of query in yyy time. That might alert us to potential problems.

Or users running lots of searches.

I don’t know the best way to protect data, but I do know that too many of us aren’t doing a good job of this. We need to get better, both in production and development environments. We need to be better at protecting databases and the data within them.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 5.0MB) podcast or subscribe to the feed at iTunes and Libsyn.

Posted in Editorial | Tagged , | Leave a comment