Voice of the DBA

Category: Editorial

  • Technical Debt

    We all experience technical debt when building software, especially software that has been around for years. Most of us have likely encountered code that we are loathe to touch and modify. At least, we don’t touch it twice. We might change things once, but when it doesn’t work as expected, most of us put it back in it’s previous state and move on to something else.

    At the same time, it’s hard to define what technical debt is or point it out to managers, who often can’t grasp the concept of why technical debt matters to a development team. They can’t understand the reasons why new code built on older code takes longer and longer to produce. It’s a nebulous concept that can baffle both people new to software development and those with years of experience.

    I ran across a few articles that talk about technical debt. This one notes it’s commonly used as a phrase and also, it’s inevitable. There’s a short video from Ward Cunningham, who is said to be the inventor of the term. It’s interesting because the explanation isn’t bad code, it’s more that we don’t always understand the problem when we write code, especially at the beginning. As we have a disagreement between what’s coded and what’s needed, we accumulate debt. Ward talks about refactoring regularly as we gain understanding.

    There is another piece that uses the Chernobyl disaster as a comparison with software development. This one looks at cost-cutting in both situations. The emphasis in software development is something Jeff Moden will appreciate: developers not writing robust code. There is also a section on designing to meet only 95% (or less) of perceived use cases, which I think is just reality. We can’t write software, in any practical sense, to cover 100% of use cases.

    The final section talks about incomplete testing. While software development has gotten better here, there is still plenty of work to be done, especially with database software. I find far too few database engineers wrap tests around their code and often have problems with new data or when code is refactored. A few more tests added early often prevent issues later, or at least, save time when debugging. This is one place I think AI might really help with labor savings by writing these tests for us.

    Technical debt is a reality of life. We have imperfect engineers, we have the pressures to get things done, the increasing complexity of software systems, and perhaps most of all, the pressure to keep moving forward with something new instead of refactoring something old. I don’t have any great solutions, but I also do see software developers working better than they did in the past. That gives me hope for a future where software is embedded in more places and used more every day.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Startup Advice

    Many technical people dream of starting a company and having it grow to an IPO. The history of computing is littered with the successes and failures of companies that attempted this. As a young man in high school, I saw the explosive growth and success of Apple, dreaming of working for them or duplicating their success. In the late 90s and 2000s, I tried a few startups before I founded SQL Server Central with my partners. I had success with that company, though no IPO :(.

    I’ve seen many friends start companies, often consulting ones, though a few have built products. Building and running any enterprise is hard, and startups are no exception. There was a post on Hacker News looking for advice and business lessons from others, and I enjoyed reading the responses. I wouldn’t read much deeper than the first level of responses, as many of the subsequent comments are less interesting.

    This response was something that caught my eye, especially as someone that’s had to do more than the technical part of running a business. A lot of the challenges I find in startups are business related, especially when technical people are in charge. It’s good for them to understand that core business, especially sales, skills are important. Even more important, home life matters.

    It’s easy to assume that your technology matters. Is the bidding technology at eBay better than uBid or eBid or even Craigslist? They are now, but 20 years ago many of these sites were similar, and some had arguably built better systems. Was the tech behind Amazon in 1999 that far ahead of Barnes and Noble or Borders? Certainly, Amazon continued to invest in technology at a scale that exceeded many other companies, but they built their success because of execution in business, not technology.

    Starting a company is hard, and it takes a lot of work. Whether you create a product or you are the product. I’ve seen many over the years, worked with some, and often the best products, tech, or people aren’t the ones that succeed. The ones that are best at running a business succeed.

    If you want to try and start a software company, go into consulting, or perhaps create another business, I urge you to learn a lot about how to run a business. Basic sales, marketing, and accounting skills will go a long way towards helping your endeavor succeed. For many of you, the tech is the easy part, so don’t spend all your time there.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • The Public Perception of Security Issues

    It’s my fault.

    That’s what I think if there is a security incident with my employer that involves the database. It’s almost my first thought when I hear about issues at other organizations, thinking a technical person is at fault. Since I’ve been a developer and administrator, and I know how complex systems are, I usually stop myself and try to learn more before I assign blame.

    The public and your customers also think that it’s just your fault. At least, that’s what I see and hear from friends. Non-technical people are very quick to assign blame and get upset. They can’t understand why some companies get breached and others don’t.  To them, it’s because the staff or management are lazy and haven’t done a good job keeping their systems secure.

    However, even my technical friends get upset. I’ve had more than a few of them chastise an organization for getting breached when they themselves haven’t always kept up to date on patches. I mean, how many of you are sure every SQL Server you have is at the latest CU level? How quickly do you patch? Are you sure your firewall people haven’t accidentally misconfigured a rule for port 1433?

    Anyone can get breached, as noted in this article. However, a good response can set you apart, and I wish that more management and technical people would be prepared now for a data loss incident, a ransomware attack, or really any security issue that might occur in the future.

    It’s easy to panic and make rash decisions. The best time to draft your response is now, when you have a clear head and no pressure. Have a few people start to game out how to react, what words and message to send, and who will take responsibility for communicating with customers. It’s worth a little exercise to discuss some possible responses to events and at least have the outline of a plan.

    And no matter what, be sure you have a copy of the plan air-gapped from your network. On a few flash drives, saved to a separate OneDrive/Google Drive/Dropbox account, or even printed out. The last think you need is for all of your work to be inaccessible because of something like ransomware encryption.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Design Lessons for Software

    I play guitar as a hobby. Not great, but I enjoy it and find it relaxing. It’s a good break from my day periodically, killing a few minutes before a meeting. It’s also a nice way to unwind at night. I find it better than playing games or my phone or streaming more Netflix shows. I enjoy those as well, but there is something different about music.

    I tend to use acoustic guitars, meaning no electronics. However, I have had electric guitars in the past, and have even used pedals to alter sounds. When I saw this article about design lessons from guitar pedals, I was intrigued. It has 5 lessons from these devices, which are for other digital gear. However, I think they could apply to software as well.

    The first one is that these pedals are rugged. While I’m not stomping on pedals with my feed, I do think that we could ensure software is more robust and not susceptible to small mistakes by users, especially in the order of their touches/clicks that might cause problems.

    The second is about using more than our hands, which I hope doesn’t apply. You can add voice or gestures but don’t require those. I HATE those features. The fourth is about physical UIs, including physical buttons, which I think is important for cars, but not necessarily for all software. However, if you can give someone a button or knob instead of a touch, it can be helpful.

    The third is to have bold, visual cues. I had a designer once say we ought to build more Fisher-Price software, meaning something obvious and usable by a child. I know some of our processes are complex, but we ought to work to keep things as simple as we can. For databases, I think clear, consistent names help here, especially for indexes, FKs, and triggers.

    The last one is to make things beautiful. I have to admit I didn’t think about this much before coming to work for Redgate Software. Across the last 15 years, I’ve learned to appreciate the value of design, UX, and the people that make things look good. I can’t do that; I have no skill in this area, but I know that having someone come behind me to do this is worth the effort.

    Of course, on top of all this, your software has to work and perform well. If the software doesn’t work correctly or is very slow, none of your clients are happy. Learn to write better code, improve your skills, and listen carefully to those asking for features. If you do that, these design lessons will make sure all your efforts shine through.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.