Voice of the DBA

Tag: software development

  • 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. 

  • Anatomy of a tSQLt test

    I’ve been doing some work on testing database code, and working with the tSQLt framework. I really like the framework more and more, and want to continue to use it. The whole idea of testing is a bit immature in database code, and perhaps software in general, but at least the software people are trying to move forward. At least in places.

    As I’ve been learning, and presenting on this, I’ve started to adopt and follow the simple pattern espoused by the tSQLt framework. It makes sense, and it provides what I think is a good format for unit test. The structure is:

    • Assemble
    • Act
    • Assert

    It’s simple, and it makes it easy to see how a test works.

    Assemble

    Declare variables and create tables you need. Insert data, initialize values and ensure that you have an expected environment on which to base your tests. I think this is especially important for database code tests.

    Act

    This is the place you call your code, or perform some action. Usually easy to do, but there are some thing that might be tough to set up.

    Assert

    This is where you assert, or declare something to be true. A value is equal to another. A result set looks like another. Something that you declare to be true, which could be some condition, like an error has occurred. If it’s true, the test passes. If not, it doesn’t.

    More to Learn

    There is lots more to learn, and I’m trying to do more. However I also need others to not only try to write tests, but evaluate how well they work and also publish some code. Explain to people what has worked, AND what hasn’t. Having that information out there, for a large variety of cases, will help others better test their code.

  • It’s about Perception

    This editorial was originally published on Dec 9, 2009. It is being re-run as Steve is on vacation.

    It’s not just the code. Sure the code’s important, but it’s not necessarily the most important thing. It’s more than just the way something works, even if the code is written correctly and performs all the right calculations. That matters, to various degrees in different applications, but it isn’t the most important thing. The important thing is the way the application gets used, and the way the users feel about it. In other words, the perception of the application.

    The perception of all of our systems and the services we deliver is what really counts. I heard someone recently paraphrase a well known saying. I don’t remember it exactly, but it was something like “People never remember the quality code we deliver, but they never forget the lack of quality in our code.”

    That’s true, no matter what we deliver. Our users don’t remember the 500 days our database server ran without an issue; they remember the day it was down. They remember when our application rollout broke something or made them work more. And they definitely remember when the application is slow or doesn’t help them in their jobs.

    As an IT group, even as technologists in general, we have to  take this into consideration when we design and build solutions. Building great software doesn’t just mean meeting the specifications we were given to  the letter, or duplicating the functionality that we think is being performed or we think is needed.

    We need to make sure that our systems work with the user, that help the user and make their jobs easier. It has to provide some tangible benefits to the end user or they just don’t perceive it as being useful to them.

    I’ve rolled out applications before that had cool, new features that hadn’t existed before, or we had incorporated new functionality they had requested. But for some reason it didn’t work well, or smoothly, or the user didn’t understand how to use the system. The perception was that the application was a failure.

    None of us wants to be in that situation. We don’t want our work to go unappreciated. To do that we need to take the users’ perception into account when we’re designing and building software. We need lots of feedback as we go along and make sure we’re building the application the users actually want.

    Steve Jones