Voice of the DBA

Tag: software development

  • Encryption in Colorado Springs – Encrypting in the Application?

    Last night was my annual presentation at the Colorado Springs SQL Server User Group. I try to make sure I get down there at least once a year, and it’s been only once a year for the last few years. Far too busy, and I’m sorry for that, but I am glad I get invited to go down.

    I presented The Encryption Primer, and there were a few interesting questions asked. Always good to see people debating and asking questions.

    One interesting one from a developer – If I can perform encryption in the application, why would I do use something like TDE or column level encryption?

    To me, I prefer to do encryption as close to the source as possible. If I can do the encryption in the application front end, I’d do it there. It reduces the chances of having the data accidentally disclosed. I don’t have to worry about having data read across the wire, or in a backup tape, or anywhere else.

    However that takes time and effort. Developers are expensive, and they have to write good, solid, secure code in the application. They also have to write this encryption code in every application that accesses the database (reports, ETL, etc.).

    Something like TDE is much easier to setup and use. Column level encryption, while still coding, is centralized.

    It’s a balance, and one you need to consider carefully and thoroughly. It also helps to debate and discuss the decisions about what you protect, why, and what it costs.

  • Double Up During Trips

    Would you do this? Combine two calls, like an INSERT and then a SELECT, into the same batch sent from a ADO.NET client? It’s a proposal from Visual Studio Magazine to combine code into one batch instead instead of making two query calls (and two round trips).

    It’s an interesting idea, and for those programmers that are older, we probably unconsciously think about this all the time. We still remember when bandwidth was measured in kbps and processing power in MHz, and we often consider those resources to be valuable. We try not to waste them, precisely because they impact performance. Perhaps that’s why we recoil at some of the ORM frameworks and other programming structures that make development easier but are tremendously chatty in how they communicate with our servers.

    I know that programmer salaries are high, and that labor is one of the more expensive parts of building software. However rather than building inefficient applications that will create customer complaints, shouldn’t we be educating our developers more to ensure they write efficient applications? They can still use a framework or template of some sort, but they should do so in an efficient way. Along with training, using code reviews and keeping everyone on a central VCS where all code is visible can help spread knowledge throughout your staff.

    I realize that many managers are loathe to invest in developers’ knowledge when those developers might leave your company for another position, but imagine that a manager elsewhere is investing in his developer. It’s entirely possible those other developers then come to work for you. Ultimately we all benefit if we work to spread and build better software development practices throughout the industry.

    Steve Jones

    The Voice of the DBA Podcast

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

     

  • Connection Issues

    Recently I was practicing for the keynote talk at the 2014 SQL in the City events. There were three of us in the “Ship Often, Ship Safe” talk, and we’d been practicing remotely. For the most part that meant a Skype call where we could work on timing and a Join.me share of a remote desktop to work on demos. The whole delivery became smoother and smoother as we got closer to the event, and I’m glad we spent a few weeks practicing (that’s important).

    However, we had an issue when we all arrived in London to practice. The first few run throughs, using a live laptop instead of a remote session, went much slower and less smoothly. In fact, the entire timing of the keynote was a problem because certain tasks were taking entirely too long. We were starting to think that we’d have to rewrite the talk in places, or take screen shots and show those.

    One of the presenters then suggested that we find a working network connection and retry our demos. It sounded a bit silly, but we relocated to a hotel room and connected to the network. Sure enough, everything ran faster.

    It turns out that there were various services, our own products, IE, and a few more that all had a few delays built in to check something across the network. Together, those delays added up to substantial time lags for various processes.

    While I think we’ve come a long way towards building amazing connectivity at high speeds, there are still plenty of times, including common tasks taking place in server rooms, where we don’t have a live connection to the Internet. I would hope that people would consider that the network might not be live and allow their services to continue to function if Internet access is not a core requirement. I suspect far, far too many developers still do not think of this.

    I don’t know that we’ll get better written software to allow for a lack of Internet access, but if you find things running slow, you might try enabling an Internet connection and seeing if your performance improves.

    Steve Jones

     

    The Voice of the DBA Podcast

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

  • CI and CD Aren’t Magic

    I’ve been studying and talking with lots of developers and DBAs about Continuous Integration and Continuous Delivery for a few years. Many technical people are excited about the possibilities and look forward to trying to automate their builds, their testing, and improving their software. However there are no shortage of concerns about the cultural problems of getting both technical staff and management to change the way they perform development.

    These are very valid, and very real concerns.

    CI and CD aren’t magic. Just like Agile, Pair Programming, or any other methodology, these development techniques don’t produce better software by themselves. There need to be cultural changes in how an organization views software and an investment in learning to adhere to the process and apply solid software engineering processes throughout a project. Merely adopting new process without changing your view on testing, and on accepting and using the feedback, will not create better software.

    It’s a bit of a leap of faith to agree to implement testing earlier in the development process. The results of that additional work don’t readily appear, and certainly code will be written slower. It’s a stretch for many people to think that fixing problems returned by a CI process and maintaining a clean build will pay off over time. I agree, and I’ve questioned the value myself. However I also see that companies implementing these changes produce better software over time, and more reliably. If they really change their culture to believe in CI and CD.

    However the better evidence, to me, is that companies that continue to produce software the way they have for years, continue to produce software with lots of bugs, that’s also over budget and late. Perhaps that’s good enough for many companies, and that’s sad. I hold out hope that anyone producing software, from managers to developers, and everyone in between, would want to do a better job with their next project.

    Steve Jones

    The Voice of the DBA Podcast

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