Voice of the DBA

Tag: software development

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

  • Is Software Engineering Dead?

    Software Engineering
    Are textbooks like this obsolete?

    Is Software Engineering dead? It’s a premise that’s in this article from Bloomberg. It calls the job a career dead end where job prospects decline after one reaches 35 years of age. I think that’s a naive view of the industry, despite the quotes from Craig Barrett and Mark Zuckerberg. While the best of the best might peak in their careers at the same age as many athletes, that doesn’t imply that the career choice is a poor one.

    There’s a discussion on Slashdot as well, and I was struck by a few of the comments, which seem to suggest that if you are still just a “software engineer” at age 40, you aren’t very good at your job. It seems that some people seem to think that everyone in this business is constantly looking to move to a new job and advance into management or they aren’t successful . I saw analogies with other industries thinking that same thing, that experienced people would not still be doing the same job after 20 years.

    That seems crazy to me. So many people in various industries continue to improve at their jobs, and do the same work for decades. Carpenters, doctors, accountants, all continue to improve their skills over time, and while some may more into management or open their own firms, many will continue to do their same jobs until they retire. And they’ll enjoy their careers.

    I don’t deny that ageism exists, and that older programmers often can’t, or won’t, work as many hours as younger ones, but that doesn’t mean they aren’t worth their salaries. Good, experienced programmers produce better code, with fewer bugs. Once managers learn that working more hours doesn’t equal better code, or even more code, the entire industry will start producing better applications.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Being Responsible for Code

    I read this great account of how Facebook releases new code, and found it to be very interesting. Apparently the entire FB site compiles to a single 1.5GB binary at this time. That in and of itself is interesting, but their deployment strategy caught my eye as well. They use bittorrent to deploy the large file to all their servers. Very creative and interesting look at things from one of the largest web sites in the world.

    The process is interesting, but one of the comments caught my eye. It includes a quote from the article:

    developers must be held responsible
    I’m sure many DBAs wish developers were held responsible for issues.

    I know there’s no shortage of developers that make mistakes and don’t want to have responsibility for the code they release. I like the idea of tracking these metrics, and letting people’s actual performance being a part of their evaluation each year. Not trusting the manager’s memory, or the recent complaints from co-workers, but actually looking at the relative mistakes being made. This leaves out scale, but I’m not sure the scale of the mistake is as important as the frequency.

    However this is a double edged sword. Some people will perform worse if you place them under this pressure and may find it too stressful an environment. If you don’t have the same pressures as a company like Facebook, you might end up driving away good employees that could fit in elsewhere.

    My recommendation would be that you hold people accountable for their work and use metrics like this to actually track that back to specific incidents, but that you use this as only a portion of someone’s evaluation. Track other measures available that help you determine if a particular worker is contributing value to your company outside of the bugs they might have in their code.

    Steve Jones

    The Voice of the DBA Podcasts

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