Voice of the DBA

Tag: software development

  • Fix v. Create

    fix typewriter
    Do you perform more fixing or creating?

    Whether you write code, or administer server instances, chances are that you have a decent amount of maintenance to do. This might be fixing a bug in code, whether yours or someone else’s. It might be reindexing tables or even running periodic maintenance routines that can’t easily be automated. There are any number of tasks that might require an administrator’s attention, but are essentially the equivalent of the tedious activities that are involved with existing items as opposed to new creations.

    I ran across this piece on Ars Technica, and I’ll admit it sounded silly at first, but the more I thought about it, the more I thought that 90% of time spent on maintenance of some sort, and 10% spent on new items might be accurate. After all, it seems there’s not shortage of work being done to tackle bugs, tune code, or enhance a feature that wasn’t quite right the first time. The more I think about my career, the more I think that I’ve spent more time fixing things than actually working on new code.

    If you think about your workload, do you fix things or create new ones most of the time?

    Give us a rough idea of how your coding time is spent. Are you more of a craftsman that develops new widgets for your clients to use, or are you the handyman, repairing and improving things that weren’t built well enough the first time.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Password Resets

    I read this piece from Troy Hunt, which is a long look at the password reset process for a web application. It’s one of the first that I’ve seen which talks about the different implementations, along with the pitfalls and advantages of each.

    It’s a great look at passwords, and there are definitely a few things in there I think should be built into authentication frameworks. I know we need to change a few things at SQLServerCentral and I’ve added them to the list.

    Pass this one along to your developers. They should be aware of this stuff.

  • The Danger of Custom Software

    The Movie Vanishes
    My kids enjoyed this DR tale from Pixar.

    There’s been a great little movie short making the rounds of the Internet from Pixar. It’s called “The Movie Vanishes” and it’s worth a few minutes of your time. Toy Story 2 was almost lost because of a mistake and some bad luck at Pixar.  This was at a time when the company was successful, and certainly should have been able to better prepare for a disaster. If you want a touch more background, there’s a few other notes at Quora.

    A lot of the software that Pixar uses was written in house. That’s a double edged sword because there isn’t anyone that can stand behind the software, other than the people that wrote it. There might not be adequate testing and there are certainly bugs in the software that may lie dormant for years. I have no idea of any of the bugs inside Pixar’s software caused this disaster, and I’m not implying it did.

    The positive side of building your own software is that you know how it works. You have the source code, and if you have a developer that can understand it, you can fix problems, patch issues, and customize it to suit your needs. As long as you have the time and resources to do so.

    I saw someone write recently that building their own monitoring solution for a set of SQL Servers was easy, but that was the smallest part of the job. Maintaining and enhancing it over time were much larger jobs than setting up monitoring. This person said they’d rather buy a package in the future than build their own again.

    If you have a system set up, it probably makes sense to use it, but as you look to develop new software, whether for monitoring servers or handling sales, it might be worth spending a bit of time trying to determine if there is something out there you can buy, which might be well tested, vouched for by other customers, and be easier to integrate than your own system.

    Steve Jones

    SQL Monitor from Red Gate SoftwareIf you don’t have monitoring set up, you should. SQL Monitor from Red Gate software is an easy way to get notified when something in your environment needs to be looked at further.

    If you want to get monitoring setup without minimal effort and immediately, think about downloading a trialof SQL Monitor and testing it with your servers.

    If you’d like to see SQL Monitor working on the live SQLServerCentral database server, go over to monitor.red-gate.com.

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Continuous Releases

    An actual graph of the features complete, but not released.

    One of the interesting things that I find with my iOS app is that they are updated fairly regularly. I have 20-30 apps, and I would guess that 3-4 of them are updated on any given week. Some of those are bug fixes, some of those are enhancements, but they are regularly changing. I don’t update them all every week, but I try not to wait too long between updates.

    Plenty of other software works like this. Windows Update provides fixed to various software on my desktop, I get a list of patches I can download when VideoStudio starts, and SQL Prompt lets me know about updates when I start SSMS. Those are all channels that allow a company to easily deliver patches to customers that improve the software. Usually these are patches, but sometimes there are improvements, like Experimental Features. In SQL Server, we have usually frowned on feature enhancements in patches, but is that what we really want?

    I noticed an interesting metric being tracked when I was in the UK. Development teams were looking at the time between when the completion of a feature (development and testing) and its release. It’s an interesting metric as there are substantial delays, which can be problematic. Users don’t get the chance to test the feature and give feedback. Developers move on to something new and may have trouble going back to enhance or patch the feature later. If there are helpful new features, and turn them on or off, wouldn’t you want to see them as soon as you can?

    Continuous Integration (CI) is a technique to help smooth the process of merging code from multiple developers, and the next step in smoothing the software life cycle is continuous release of software to get your changes in the hands of customers quicker. It’s not suited for everyone, testing needs to be more thorough, and there needs to be a smooth process that allows customers to pick and choose which updates they apply. However this can be a way to get feedback from customers, and even decide on future priorities as customers provide feedback.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.