Voice of the DBA

Category: Editorial

  • Why Would You Move?

    I was reading a thread on Quora about why SQL Server is chosen by companies, and another on StackOverflow about why Oracle is a good choice. As much as I sometimes joke about the Oracle RDBMS, I think it’s a solid platform, and certainly wouldn’t resist working with Oracle databases if the opportunity presented itself. I like working with technology and enjoy learning about how different platforms work. However I also know that if I started working with Oracle, I’d be much less efficient, and certainly quite slower, in producing work than with SQL Server.

    I’d also probably make a lot of relatively poor decisions about how to run the database instance.

    I’m sure I’d get better writing PL/SQL, but that would take time. And in any setting, that also means that I’d be costing my company money while I learned the tricks, best practices, and skills needed to produce a well tuned, efficient Oracle-based application. It’s really no different than the way I have seen many highly skilled Oracle developers and DBAs come to work with SQL Server and try to treat SQL Server as if it ran the same way as Oracle (<shudder>cursors</shudder>).

    That’s why when I hear about companies making a quick switch to a new platform or language, I question the move. Certainly there are domains of problems that Oracle might solve better than SQL Server. There are situations where MongoDB is better than an RDBMS or Java makes more sense than C++, but there should be strong, solid technical reason why it’s worth trying something new. Not because a manager wants to save some licensing fees or a developer wants to try something new.

    By all means, experiment, but do so in small ways. Try new technologies with limited investments, and if they work, increase the investment. However for large projects, stick to what your staff knows best. Their skills are often the limiting factor in producing well written software, and in almost every situation, their salaries will far outweigh any cost of software that you license.

    Steve Jones

     

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and LibSyn. 

  • It’s about Perception

    This editorial was originally published on Dec 9, 2009. It is being re-run as Steve is on vacation.

    It’s not just the code. Sure the code’s important, but it’s not necessarily the most important thing. It’s more than just the way something works, even if the code is written correctly and performs all the right calculations. That matters, to various degrees in different applications, but it isn’t the most important thing. The important thing is the way the application gets used, and the way the users feel about it. In other words, the perception of the application.

    The perception of all of our systems and the services we deliver is what really counts. I heard someone recently paraphrase a well known saying. I don’t remember it exactly, but it was something like “People never remember the quality code we deliver, but they never forget the lack of quality in our code.”

    That’s true, no matter what we deliver. Our users don’t remember the 500 days our database server ran without an issue; they remember the day it was down. They remember when our application rollout broke something or made them work more. And they definitely remember when the application is slow or doesn’t help them in their jobs.

    As an IT group, even as technologists in general, we have to  take this into consideration when we design and build solutions. Building great software doesn’t just mean meeting the specifications we were given to  the letter, or duplicating the functionality that we think is being performed or we think is needed.

    We need to make sure that our systems work with the user, that help the user and make their jobs easier. It has to provide some tangible benefits to the end user or they just don’t perceive it as being useful to them.

    I’ve rolled out applications before that had cool, new features that hadn’t existed before, or we had incorporated new functionality they had requested. But for some reason it didn’t work well, or smoothly, or the user didn’t understand how to use the system. The perception was that the application was a failure.

    None of us wants to be in that situation. We don’t want our work to go unappreciated. To do that we need to take the users’ perception into account when we’re designing and building software. We need lots of feedback as we go along and make sure we’re building the application the users actually want.

    Steve Jones

     

  • Mercenary

    I was listening to a few people talk at an event about the software they were working on. For some of them, there was a true passion in solving the problems they faced. However these weren’t applications that eased poverty with cleaner water, or more efficient transportation. These weren’t applications that dealt with medical issues impacting human health. In many cases these were simple, consumer applications that entertained people, but these developers were quite proud of the applications they worked on.

    However the challenge of practicing their craft well elicited quite a bit of passion from these developers. They not only took a lot of pride in building an efficient set of methods in Java or C# quickly, they really enjoyed the process of taking a development task, writing code and tests, and delivering software that worked. They would even find pleasure in receiving a bug report, finding the issue, and delivering a corrected version of code. Most of all, however, they believed their software was making the world better in some way.

    There were also plenty of developers that didn’t really care what they worked on. They didn’t find anything special about software development, and were happy to get assigned a task, write some code, and deliver it. They weren’t looking to produce shoddy applications quickly, and many of them were talented developers. They just didn’t much care where they worked or what the function the software performed.

    Is this you? Are you willing to work on whatever application comes your way? Or do you have a passion to build something in particular, to work on projects that have some meaning to you? I think I’ve usually been one of the former, willing to work on any application. I’ve always been more concerned about the coworkers I have than the project we work on, but there are times I’ve felt our applications were a little special, and made a difference in some way.

    Without a doubt I think most of us would prefer to work in an area that means something to us, an area that elicits some passion. I just wonder how many of us actively seek out such positions or projects.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Document, then Install

    I saw someone post a note that they had installed a new SQL Server and wanted to document the install. Did anyone have a good script or process for doing this?

    I’ve done this myself, but lately it seems to be the wrong way of actually building systems. One of the things I have started to feel is important is that I should strive for consistency and known states for systems rather than works of art.  However if I’m installing systems and then documenting them, I think that I’m doing things backwards.

    There has been a trend towards declarative actions in technology, whereby we tell the system what we want and it configures itself to arrive in that state. An example of how some this can be done is with Puppet. This is a case of the administrator essentially documenting what they want to be done first, and then letting the system put itself in that state. It’s almost like programming the installation and configuration of software, but with tools to make the process much smoother.

    In this model, administrators don’t need to document the installs. They’ve already declared what needs to be done. If vendors change defaults in the future it doesn’t matter, as the installations will configure themselves to the same state, ignoring defaults and human expectations. This also results in much more consistently configured systems, something that’s critical for building a smooth software delivery pipeline.

    The closest thing I’ve seen to this for SQL Server is the Finebuild project that Ed Vassie set up. That’s much better than unattended installs and I’ve seen Finebuild demo’d, and it looks good. I need to set it up so that I can ensure that every instance I set up is in a known configuration. I can have multiple configurations ready, but I’d rather choose one of my choices and then let the system apply the settings than remember to click a particular check box or change some item manually. I’d also appreciate this for DR and auditing, with some list of settings for each instance or host.

    That just seems more like a 21st century way of working to me.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.6MB) podcast or subscribe to the feed at iTunes and LibSyn.