Voice of the DBA

Tag: software development

  • Better Comments

    I assume most of your comment your code.

    Well, you probably comment code most of the time.

    I’d bet your comments have quite a bit of detail.

    And you do this completely inconsistently.

    That’s what I’d think, or maybe just what I want. Even the best developers I know will not consistently comment code. You can drift through any project on Github and see this. Those projects on GitHub might even be better documented because people know they are public. In most corporate environments I have worked in, I’ll find that when people get busy, or distracted, or even when they’re experimenting to find a solution, and they don’t write detailed comments. Usually only when someone fixes a bug, with a solution found quickly, do I get a really useful comment.

    There are all sorts of ways that people think about commenting their code. I ran across a post from Annette Allen about adding comments. She noted that she has headers in her stored procedures and other comments. However, after a few months, she wasn’t sure that the comments actually helped her. I’ve had that same feeling at times when looking back at comments, both mine and others.

    Do you have a method for choosing the words you use to comment code? Jeff Atwood says to comment on why you did something, not what. I’ve seen that before, especially with version control commit comments. We often can look at code to determine what it does, and if you use a VCS extensively, then you can always see the changes that were made between versions. The comments typically give me some rationale for the work I did. Over time, I find that if I think about how I’d explain my reasoning to myself in the future, I come up with a good comment.

    You might feel differently, and if so, please let me know. Perhaps there are some good ideas you have about choosing comments, and perhaps you have examples. Some might include a bug or Jira number, which I like, but others may hate. These could be comments inline in code or those you use when comimtting to a VCS.

    Share some thoughts today, and if you have any entries for the best code comment, drop them here.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Will Coding Be Less Important?

    How many of you can read Greek? I can decipher the alphabet and pronounce words, but that’s about it. I thought about this after running across an essay that says that coding will eventually be as important to most people as ancient Greek, which is to say, hardly important at all. The author seems to suggest that eventually we’ll tell systems what we want and they’ll build algorithms. I guess that’s what we do in code, but the impression I have from the piece is that we’ll use natural language to inform some AI system that will actually produce the code.

    Possibly, but let’s set that aside for a minute. Assume that we could have an AI that removed the need for us to code the corporate CRUD systems or most of the websites we have. Could such a system be adapted to manage data?

    Possibly, and maybe more consistently than we can. Certainly plugging in RTO/RPO values and HA needs might allow an AI like system to schedule backups, build up or tear down new nodes in a cluster or Availability Group, and certainly respond to DBCC errors, reindex systems, and more. I certainly could see that we could request a system to do X and lots of the background details would be handled.

    There are some other thoughts about this piece that I tend to agree with. The ability to easily specify the way in which a system can work, for the average or even above average user, isn’t coming soon, if ever. The thing is, I’ll take solace in something that I truly believe.

    Writing the code isn’t the hard part.

    Sure, syntax can be challenging, and working out the mechanics of how modules interact, and building MAKE-like scripts, and deploying changes are difficult. We forget about the differences in environments and configuration, and I bet better static analysis and AI might help here. The thing that’s really hard, that is likely to still exist even if we specify the way something works is that it’s really, really hard to be specific.

    We struggle to express the exact way that systems should work. We struggle sometimes to communicate what “a discount for more than 10 pieces” means. Is that a discount at 10? At 11? what if there are 20 ordered and 10 returned? Do we remove the discount or pro-rate the return? We can solve the issue, but so often, we don’t know there’s an issue until the system gets into production. Changes in rules/regulations? We don’t often know about them, much less know how to express those changes in plain language.

    Even if we could get by without writing code, the expression of “how” something works likely requires a lot of detail, a meticulous person, and endless patience to get the machine to understand. Something many developers do now. I suspect the same thing would be necessary for database development. Even if we could specify the result set, would we really trust the machine to query the source and not come up with multiple ways to get this result set, which might not be valid for another?

    Call my cynical, but coding isn’t going away, even if the syntax changes to English (or some other spoken tongue).

    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.

  • Taking Shortcuts

    Many of us work in situations where we feel pressure to get work done at a pace that’s faster than we might like to move. In some sense, this is the nature of life, where customers and clients always want something done immediately. Whether they’re ordering food or building a house, it seems that quite often the customer expects the creator to just work harder and faster, without making mistakes, and deliver the goods quickly.

    That may or may not work, but if does often result in issues in software. While we can fix them, there can sometimes be larger issues, especially where sensitive data is involved. There was an incident recently that reminded me of this, though fortunately, it appears the data loss was minimal in scope and sensitivity.

    The mobile app at a recent security conference leaked data. The builders of the app embedded security keys and passwords that allowed anyone that registered to download a database of attendees. Fortunately this was a limited set and it appears only names were exposed. However, it could have been much worse, especially if this were a typical non-normalized database that might contain all data about an attendee in one row.

    I don’t know the timeline here for development, and I certainly don’t know the requirements. I do know that embedding keys and passwords into application is a bad idea, and even worse when those applications are going to be installed on customer devices. These are fundamental rules, and I certainly hope that whoever worked on this application, and anyone reading about this story, knows not to do this again.

    No matter how rushed we are, it’s important that we follow some practices and include some seucrity in our systems. I’d argue that data security ought to be number one and built into the system from the start. As the GDPR asks, we should be ensuring this is included by design and default. As much as it might seem that new legislation is overreaching and burdensome, I’d argue that mistakes like this one are all too common when we feel pressure to get work done. We shouldn’t be making these mistakes, nor should be be pressured to ignore security for the sake of expediency.

    Steve Jones

  • New IT Departments

    I had a friend that used to run an Exchange system. Actually, he was part of a team of four that managed a 50,000+ mailbox system for a very large company. In 2000 or 2001, he told me that his job would be done by computers in a few years and he had decided to leave the industry. Over the last 15 years, he’s worked in another field.

    I have no idea if those Exchange systems are still around, and I would concede that mail is better purchased as a service for most organizations than managed in-house. However, I think my friend made a mistake. There are still plenty of people working in technology infrastructure in companies, making a good salary in good working conditions. I’ve spent my career in IT in one way or another, either as a developer, Operations staff, or manager. I see no sign of this going away quickly, though certainly many menial, simple tasks like checking logs and backups are being increasingly handled by automated systems.

    When I see articles like this one (Why IT as you know it is dead), I’m not sure what to think. One one hand, I do think IT is changing, especially in larger organizations, where there is pressure to reduce costs (often labor) as well as increase the speed of output. DevOps is one way that we try to improve our systems, though the cultural change is very hard. Often this means that developers produce work in smaller chunks, and may release more often, but don’t get more work done. This is because the cultural change is hard, and most of us don’t want to change our habits.

    On the other hand, I also think that in many ways IT is the same. We can’t respond as quickly as business analysts or customers come up with ideas. I know most of those ideas probably aren’t great, and IT doesn’t want to waste resources on something that will not prove to be valuable. Just as happened 30 years ago, departments will create their own POC applications. This used to happen in Lotus 1-2-3, then Access and Excel, now it may happen with low-code development tools, whatever those are.

    I don’t really worry about this, as I’ll find ways to make things better. If someone wants an Access or Power BI application, let them build it. If it’s really useful, and others need access, we can upgrade and invest in a better system. I’ll go along and get along, working to build the things that the organization finds useful. I just realize that my time is limited, and if someone else can prove a concept is valid, perhaps that means I should spend time ensuring that works or gets rebuilt in a better way. I also know many of those ideas and concepts won’t prove themselves, so it’s fine if there’s some sort of citizen development (or shadow IT) in an organization.

    To me, the key is that we enforce security for our data. If anyone wants to build software, that’s fine. They just need to ensure that they use the same security and authentication mechanisms that other systems use. We need to protect the data, no matter what application is going to be used to view, analyze, or manipulate it.

    Steve Jones

    The Voice of the DBA Podcast

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