Voice of the DBA

Tag: software development

  • Saying Thank You

    This plane left without me 😦

    Recently I had problems with one of my flights. That’s nothing new, and as Grant Fritchey noted, I tend to anger the travel gods for some reason and often find myself in situations that make me regret ever leaving the ranch. In this case, I flew to the Dallas-Fort Worth airport, which was fairly close to SQL Saturday #63. I attended the event, and drove back early Sunday morning in time to have some coffee before my flight. I walked in, went straight to security with no bags to check and a mobile boarding pass. I scanned my phone 4 or 5 times before the security guard told me to leave.

    Actually he didn’t tell me to leave, and was very polite in asking me to go check with the airline for a new boarding pass. The airline agent informed me that my flight was out of Love field (new service starting that day) and despite my early arrival, I wouldn’t make it to Love field in time.  I was stunned as I had booked a flight like I normally do: pick an outbound flight, then an inbound one. I  have never been presented choices from a different airports for the return flight, but in this case that was what happened.

    I could have gotten upset, especially after spending 5 hours in the DFW airport waiting for another flight. Instead I tried something else. I sent a nice note to Expedia, letting them know that despite my issues, I am pleased with the way that they provide a booking service on the web. I have used their site for years, and it’s been a nice tool for me, allowing me to keep all of my data in one place. Their services have expanded over time and I like their service. I then told them of my issue, and noted that it might have been a bug or a glitch, but in any case, it was an inconvenience for me.

    It was a strange situation for me, and a convergence of a few things. My inattention to detail, new service for an airline, and a large city with multiple airports. I rarely fly to cities with more than one airport to choose from, and was willing to accept some of the blame. However I also know that application developers try to build applications that work, and a little praise is always appreciated.

    Steve Jones

    The Voice of the DBA Podcasts

  • You Don’t Know Enough

    Always be learning

    We always expect developers to test their own code and be sure that it works as expected before they release it for anyone else to use. However we should be aware that developers won’t think of all the edge cases that might break their code, so a good software process includes another group (QA) that tests the software separately, and hopefully also reviews the code as well.

    Why do we do this? It’s because you can’t be sure that just because code passes your own tests that it is well written. You can only be sure that it passes the various tests you have designed, which is likely a subset of all possible tests it ought to pass.

    Bruce Schneier wrote a piece that talks about this from the security perspective. If a system fails initial testing, we know there’s a problem. However if it passes those tests, we still don’t know it’s secure. There still might be other vulnerabilities, perhaps even obvious ones. Only through exhaustive testing and review of the code, can we gain any sense of confidence in the security of a system. Even then we would still want to include some monitoring of the system as vulnerabilities might be discovered at a later time.

    Each of us has some limited amount of knowledge about the technology we work with, but there is one common thing we all share: we can all learn more.  Those limitations of our knowledge carry over to the code we write, and mean that we won’t necessarily completely test our code to cover all possibilities.  We might not even remember to test for some things as our work gets more complicated.

    We need to work with others to ensure enough code coverage and have some level of confidence in the quality of our work. Today’s systems are just too complex for one person to completely understand. Once you accept that and learn to work in a team, critiquing the code of others and accepting criticisms from them on your work, you will find the quality of your software will rise.

    Steve Jones

    The Voice of the DBA Podcasts

  • How to Fix Connect

    Microsoft Connect is the place to submit feedback

    The Connect system is the main way that all of us can feed back information on SQL Server to Microsoft . You can use this system to submit a bug or a suggestion, and your submission will go to the SQL Server development team so that they can respond. There is the ability to comment on other people’s posts, view workarounds that Microsoft or another user have posted, and vote a suggestion up or down. A great example that’s one of the most voted on items is the Create or Replace idea.

    Recently a large number of Connect items were closed, including a few that I had submitted. Based on all the Twitter comments, it seems that most of these items were closed and marked as “Won’t Fix”, which I assume means these will not be fixed for SQL 11.

    That’s good and bad. Having watched the Connect Feed for SQL Server, I’m surprised by some of the suggestions that I see come through. While I can appreciate someone wanting to know when SQL 11 “Denali” will be released, I’m not sure it’s worth a Connect submission. Or this brilliant duplicate indexes note. I feel bad for the people that triage these requests since these not-very-well-thought-out submissions create ill will and waste time. How would you like to get these type of suggestions for your software? My guess is most of these suggestions ought to be closed and this was a good thing.

    But it’s also discouraging for those of us that submit feedback and don’t necessarily get a good response on why our feedback doesn’t make sense, especially when you have dozens of people voting for the idea.

    For a long time I really liked the SQLWish email address where one could send ideas to Microsoft. That was discontinued in favor of Connect, which I think is a good idea. However I think Connect has a scale problem and doesn’t necessarily work as well for “ideas” as it does for bugs.

    I’m not sure how we can fix it, but one thing I’d like to see is a ranking of the top xx items that could be considered for the next version. Feed that back to the community and let us give you opinions on whether or not those items are still important. I know we can’t necessarily drive development, but I do think that SQL Server can evolve into a product that we are more likely to upgrade if our feedback is visibly and obviously considered.

    Steve Jones

    The Voice of the DBA Podcasts

  • Quality Over Timing

    Is quality job one?

    Is quality really the number one job of software developers? I think we’d all like this to be the case, but I suspect that in many companies it’s not. This piece is a few years old, and it talks about how quality has become more important at many large software vendors. Looking back across the five years since the article was written, do you agree?

    Whether you are a commercial software company, or building applications for internal use by a company, there are so many external pressures to finish or ship an application that quality becomes a second, or even third, tier goal. The need to have people begin using the software, with those last minute features added, means that quality gets cut in some areas.

    We build software with the best of intentions, and I understand that there must be a deadline for the software to start being used. However I think that the balance between finding a finishing point for a version of software and quality is leaning a bit too often towards the deadline taking priority.

    In my ideal world, we would pick a stopping point, and then ensure that the development and testing of everything in progress before the stopping point is completed. In other words, we can’t pick a ship date, but we can pick a design end date, and from there work through the proper build and test from that point forward to a well built piece of software.

    I don’t know if we’ll ever get to the point where the overall image of software is that it is mostly well built, but I can hope we do.

    Steve Jones

    The Voice of the DBA Podcasts