Voice of the DBA

Tag: software development

  • The Human Touch

    How often does human error cause issues? Recently we had a rocket crash in Russia,there have been numerous incidents of drone crashes as more and more unmanned aircraft take to the skies, and a few years ago we had an Air France disaster that might have been cause by humans making poor decisions or engaging the wrong controls. Those are incidents where the wrong button press has large consequences, either in physical damage or the loss of life.

    Many of us make mistakes constantly as we work in the various tools and environments we need throughout our day. We click the wrong button in SSMS, we connect to the wrong server and run a script, or we fail to test a change. All of these are mistakes made by humans, and often are mistakes that can be prevented if we did a better job or sticking to routines and processes. That can be hard, but perhaps checklists can help here, along with some double checks by coworkers.

    That’s why I think using scripts in T-SQL, and using the Script button in SSMS to generate the code that you can run (and save) is the best way to work with your servers. As much as I think Powershell (PoSh) can be a pain to write and debug, there’s a good argument to be made for using it when performing complex administrative tasks, especially across servers. Using code rather than forms and buttons is just a better way to accurately and consistently make changes in a controller manner.

    This is an area where everyone could work more efficiently. Developers are usually used to working with version control systems and tracking all their changes. However they often will make configuration changes to their machines, SQL Server, IIS, or some other software, and forget to track the changes. Making these changes in code, through T-SQL or PoSh, and tracking these items in VCS, would help with smoothing software deployments. DBAs and other operations staff should learn to use version control systems  as well, helping to track down root causes to issues.

    Ultimately humans are often the weaknesses in most systems. We should understand that, accept it, and compensate as best we can.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 15.5MB) feed

    MP4 iPod Video ( 19.7MB) feed

    MP3 Audio ( 3.9MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Less QA?

    Throughout most of my career, people have complained that software is never tested enough, not tested well, and certainly not enough time is allocated in project plans. I’d also argue that all too often we don’t have people building software with experience in how to perform extensive testing. Most developers only have a rudimentary knowledge of software testing and that part of their skill set doesn’t receive constant training. However I’ve found plenty of QA people that were in the same situation. Some educate themselves and learn how to test better, but many go through the motions. They don’t take pride in their role as a software tester.

    There have been lots of advances in automated testing and TDD methodologies over the years, which means that developers have been taking more of the responsibility, and effort, for testing code. It’s hard to know if this has resulted in higher quality code, lower quality, or a mix. Overall I think that the latter is likely. Code quality is all over the board, probably based more on the skill and talent of the individual developer than on any process.

    That’s good for the companies that have hired strong developers, but not so great for our industry as a whole. We still produce lots of software that takes too long to develope, costs too much, and often has too many bugs. Overall we are sloppy and inconsistent in how we build software. Some of that is the nature of our business, one with such a low bar of entry that anyone can give software development a try.

    I don’t know how we improve the quality of software, though I do think continuing to educate and train people on what works well is a good start. However I also think that we still need QA groups. We need people that will use software in ways that automated tests won’t. People that will press buttons, enter values, and push software in ways that developers would never consider using it. Most of all, we need QA and testing to be treated as a valuable part of our industry. We need QA people that view testing as a valid career path, not a stepping stone for junior developers that look to move on as soon as possible.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 15.7MB) feed

    MP4 iPod Video ( 20.2MB) feed

    MP3 Audio ( 3.9MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • The Agile Cult

    This editorial was originally published on Sept 23, 2008. It is being re-run as Steve is on vacation.

    Can developers change the way they build things? Can corporations?

    I’d like to think so. After all there are companies and developers that get more efficient as they evolve their development practices. I know that I’ve gotten better at building software over time, getting more efficient as I learn better ways to actually write code, keep track of changes, quickly build and test, etc. Or maybe it’s that I’m more disciplined about working carefully and actually doing things like checking in and out of version control, writing better test cases, and actually following the plan I’ve setup.

    The Capability Maturity Model (CMM) from Carnegie Mellon University that measures the ability of a software development group to better build software. Most software teams rank very low on their scale, requiring much effort to move up the model to a more mature style of development. I’m not sure of those groups at a CMM level or 4 or 5 produce better software than those at level 1, but I’d like to think that they do.

    There was a blog post about Agile development, which is a method of software development that I think can help one build software in a quicker and more flexible manner. In the post, which is a look back at an attempt to build a project using this methodology. It didn’t work out, though they did complete the project on time.

    It’s an interesting read to see a nice self examination of how their culture actually failed them. They couldn’t really build Agile software, mostly because of the culture at the company. Despite the desire to change and the buy-in of the technology team, many other factors ended up preventing them from really sticking to their Agile plan.

    Well they completed their second project successfully, albeit with some overtime involved. They recognized that they hadn’t used the Agile methods and they’d fallen into an Agile Cult instead. It seems the author was a little disappointed in the result, and perhaps in their inability to deliver with Agile methods.

    Personally I think that even partially adopting Agile methods results in benefits. Just because you can’t deliver incremental releases or change your focus quickly doesn’t mean there aren’t benefits. Having a different mindset and trying new techniques can have a lot of benefits for your team. Just thinking about building software differently can let you re-think the way you do things, allowing you to be more self-critical and look for ways to be more efficient.

    Constantly trying new methodologies might not sustain you for the long term, but trying different development methodologies can help you find the things that work best in your environment. Once you know what works well, you can then set about changing the culture to become a more efficient software development team.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 20MB) feed

    MP4 iPod Video ( 18MB) feed

    MP3 Audio ( 4MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Programming

    programmingTechnology is here to stay, and those of us working in this business probably realize more than most people how dependent and integrated our lives are with technology. Even in countries that don’t have the infrastructure or economies of first world nations are using more and more technology in their lives. Mobile technology seems to be at the forefront of much of what we do, but I’d argue that data is fast becoming more important than the software itself.

    The one thing I’m becoming more convinced of is that this article is right: programming is a core skill. It doesn’t matter if you’re a developer building mobile apps, or a contractor scheduling workers, or a homemaker that wants to balance a budget. While there is software that might help, it seems many people are quick to open a spreadsheet, add some data, and start building formulas. These days the jokes about people not understanding how to program a timer on a DVR are fading quickly as more and more non technical people are using technology to make their lives easier, or perhaps, more complex, as they manipulate data and software.

    I suspect the fundamental skill of logically analyzing a problem and coming up with a set of steps to solve it is becoming more important all the time. In many businesses the ability of workers to think for themselves and handle a variety of situations is more desirable than the ability to follow orders. Even in industries where workers need to follow instructions, those instructions might be coming from computers more and more often. There will be a huge gap between workers that can think for themselves, perform data manipulation and make business decisions and those who cannot. That gap might take the form of compensation differences, opportunities, or something else, but in many industries, those that can build their own programs, whether in code or processes they follow, will advance faster and further.

    Not everyone will want to be a computer developer, but most everyone can benefit from understanding how calculations and instructions can be chained together to build a process or workflow. With newer generations becoming familiar and comfortable with technology from early ages, my vote would be that we should add programming to the three Rs for future generations.

    Steve Jones

    The Voice of the DBA Podcasts

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