Voice of the DBA

Category: Editorial

  • CI and CD Aren’t Magic

    I’ve been studying and talking with lots of developers and DBAs about Continuous Integration and Continuous Delivery for a few years. Many technical people are excited about the possibilities and look forward to trying to automate their builds, their testing, and improving their software. However there are no shortage of concerns about the cultural problems of getting both technical staff and management to change the way they perform development.

    These are very valid, and very real concerns.

    CI and CD aren’t magic. Just like Agile, Pair Programming, or any other methodology, these development techniques don’t produce better software by themselves. There need to be cultural changes in how an organization views software and an investment in learning to adhere to the process and apply solid software engineering processes throughout a project. Merely adopting new process without changing your view on testing, and on accepting and using the feedback, will not create better software.

    It’s a bit of a leap of faith to agree to implement testing earlier in the development process. The results of that additional work don’t readily appear, and certainly code will be written slower. It’s a stretch for many people to think that fixing problems returned by a CI process and maintaining a clean build will pay off over time. I agree, and I’ve questioned the value myself. However I also see that companies implementing these changes produce better software over time, and more reliably. If they really change their culture to believe in CI and CD.

    However the better evidence, to me, is that companies that continue to produce software the way they have for years, continue to produce software with lots of bugs, that’s also over budget and late. Perhaps that’s good enough for many companies, and that’s sad. I hold out hope that anyone producing software, from managers to developers, and everyone in between, would want to do a better job with their next project.

    Steve Jones

    The Voice of the DBA Podcast

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

  • When Work Gets in the Way of Work

    It seems I find myself in this situation more and more. I’ve got work to do at SQLServerCentral. There’s a constant stream of articles to edit, content to review and schedule, questions to build, and of course, writing these pieces on data related topics. That goes on 220+ days a year, as we keep the site going and send a newsletter every weekday of the year.

    However the last few years I find myself crunched to get work done in my work week with the addition of other tasks to my routine. I’ve moved from 2-3 events and 5-6 presentations to 20+ events and closer to 40 talks a year that I deliver. Not only is there a high frequency of events, but there’s also a number of new presentations to build. It seems I have 3-4 (at least) new talks to assemble, which can be quite time consuming. That’s in addition to keeping SQLServerCentral moving.

    This isn’t different than many of the jobs I’ve had in the past. Often I’ve had a set of tasks that I need to work through regularly. Whether these were admin tasks, or development projects, I usually have found that I can develop a routine throughout most weeks. However things crop up. Bug fixes are reported, or hardware fails, or some other project takes some priority, but I need to somehow fit this into my week, along with everything I normally do.

    It’s tough, and I think far too many people with salaried jobs try to just work harder and longer to complete their work. That makes some sense for a short period of time (2-4 weeks), but after that it’s a mistake. Productivity declines and people burn out. They become cranky, and more importantly, they lose a substantial portion of their life over time.

    I’ve learned to push back when things become too busy, and while I’ve had managers that weren’t thrilled, even angry, almost all of them understood the problem and worked with me and others to change things.These days that means I cancel or skip events. More often I decline to accept engagements in the future to bring balance into life. 

    This month is tough, with a lot of commitments made months ago, and flying to the UK this week doesn’t help. However I’ve learned a few things about scheduling my time this year and hopefully I’ll do a better job next year.

    Steve Jones

    The Voice of the DBA Podcast

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

  • 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