Voice of the DBA

Category: Editorial

  • 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

  • Hiring Heterogeneously

    I wrote recently about tech interviews and hiring, and even on an interesting interviewing technique for senior people. However we need to hire more than just senior people. We need to hire junior people, and intermediate people. Those roles are important for both growing the experience of your staff, and not getting caught with a “” as a bottleneck or single point of failure. Not that’s not Brent Ozar, though someone with his talent might be the single point of failure in many organizations.

    Not everyone can be a superstar-expert-architect that decides how the system is built. Not all architects should spend time coding basic insert/update/delete code or adding clustered indexes to tables. We need a variety of talent levels that can get complete different types of tasks. There is tedious administrative work, supporting roles, necessary, though unexciting work like reviewing security, logs, audits, and more. While you can automate much of this busy work, there are still tasks that we must assign to people.

    There’s another consideration as well in hiring that all too often people overlook. Hiring too many people that are too similar, who may think alike, who may view problems the same way can lead to an environment that doesn’t grow and expand, that loses it’s creativity over time. There’s a great quote that says “Where all men think alike, no one thinks very much” (Walter Lippmann). It’s important to have a diversity of opinions, and when you hire new people, you should consider this. You want talented people, and people that get along, but not necessarily all thinking about problems in the same way.

    The world is a richer place for the diversity we have, and varying opinions, thoughts and ideas. We don’t all get along, but many of us can work together with mutual respect, considering each others’ viewpoints as we work to build solutions to the problems we face.

    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 ( 14.8MB) feed

    MP4 iPod Video ( 19.6MB) feed

    MP3 Audio ( 3.6MB) feed

    Feeds are available at iTunes and Mevio

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

  • DR Failovers

    failureAlmost everyone struggles with setting up disaster recovery plans and resources. There are a few companies that take their DR seriously, but for most organizations, it’s an afterthought. It’s an insurance premium that can easily be avoided if there are not pressing problems and your past experience with disasters is minimal. After all, it’s rare that any of our data centers shuts down because of an earthquake, hurricane, fire, or other similar large scale event.

    However most of us try to have some type of disaster recovery in place. We may have cold or warm systems available. Our companies have funded an AlwaysOn Availability Group, or more likely, mirroring and/or log shipping for critical systems where data is moved to a remote location on a regular basis. We monitor these processes, and we try to keep them running, though I’m sure if they break, many people don’t give the repair top priority in their daily work.

    A DR environment is like a backup. If you don’t test it, you’re never sure if it really is something you can use in a disaster situation. You may periodically test your fail-over, like you test a restore, but do you ever really lean on the secondary system? This week, I wanted to ask you this question:

    Do you fail over to your DR system and run your business from the system for a day (or week or longer)?

    I know a few companies that consider secondary systems to be critical and will actually fail over, and then run the other system for a few months, failing back to then retest the primary system. In this case, there really isn’t a primary and secondary system, but rather two systems that can work, being alternately used throughout the year.

    This is actually moving closer to a cloud architecture model, where you don’t place high importance on any particular system, you assume any system can fail, and you have redundant systems that can pick up the load. In a cloud environment you might have more than two, relying on dozens of systems instead, any of which could fail, but with a small interruption in service.

    I’d hope that SQL Server, the version of the platform I can install in my data center, would get close to this, allowing me to serve database services to clients, but seamlessly moving those services across instances, with clients unaware when physical machines have crashed because their services just moved to another host.

  • Password Ninjas

    For the time being, passwords are the way that we authenticate users and secure most of our systems. There might be a better system in the future, but for now everyone needs to manage a series of logins and passwords, even if you have authentication for many systems linked through an internal domain or external system, like OpenID.

    I think password managers are almost required these days to manage passwords for most people. I recently ran across an article on ArsTechnica where five security experts were asked how they manage their complex passwords across a multitude of services. Four of these experts use password managers of some sort, though there is quite a variety of them. One actually remembers passwords, though he tries to use proximity tokens and one time passwords when possible.

    Bruce Schneier, one of the security writers I’ve followed for a long time uses Password Safe, which is what I use. However he also likes to use his own advice of long sentences turned into passwords and keeping backups of passwords on physical paper. I don’t like writing down passwords, but if you can keep the paper secure (not stuck on a monitor or under a keyboard), it’s an easy solution to use.

    There are various ports on different operating systems and different methods to keep your files in sync, if you choose to do so. Two others use competing products (1Password and KeePass), but one uses a text file in an encrypted virtual disk image that he keeps on a USB key. I’m not sure I like that, but with proper backups, it’s not a bad solution.

    There is a variety of advice, but overall there’s one thing to keep in mind: security is serious business. All the more so as we use various services more and more to conduct business in our daily lives. Losing a password that you share across multiple services could severely compromise your life. Whatever method you choose, stick to it and be careful in choosing your passwords.

    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 ( 14.5MB) feed

    MP4 iPod Video ( 20.2MB) feed

    MP3 Audio ( 3.6MB) feed

    Feeds are available at iTunes and Mevio

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