Voice of the DBA

Tag: software development

  • Coding With Music

    Lots of developers use headphones and music at work, though I think corporate life in cubes encourages this, just to block out the distractions. When the walls of your office stop at the 5 foot level, you might need all the privacy you can get from a large set of speakers attached to your head.

    I heard a few programmers debating this recently. One of them mentioned that he often uses music, a soothing melody that helps to block out distractions. Another said that white noise is a help. A few others actually mentioned that a private office and silence was more important for them. I know that in the past I’ve often tried to pick more mellow tunes, often jazz or classical music without a vocal component, when I needed to concentrate.

    Another person mentioned that there has been work that shows music is distracting to people, and it can perhaps occupy a portion of your brain and make you less efficient. You might notice less patterns, or consider things differently with music playing. I found that plausible, and decided to ask the question this Friday.

    Would you prefer silence, music, or some other background noise when you are working?

    I often go to a Starbucks or a bookstore and write on my laptop, just to have the white noise of people in the background. I think I get some level of energy from having other people around, but not interacting with me. I might listen to some music, but often I just sit there and focus on my work.

    When I used to work in a corporate environment, I found that I used music, but it was really to block out the distractions of other people nearby. Being in my own world often helped me get into the zone, and having large blocks of time were essential.

    So let us know what works for you, why, and if you’ve tried anything else. If you have good arguments to present to management for achieving your ideal work environment, let us know as well.

    Steve Jones

  • Google Scale

    I heard someone talking the other day about how Google needs to optimize their code. They really pay attention to low level operation of their software, actually having people spend time writing compilers and ensuring they generate efficient code. This is on top of the idea that they want to ensure data structures efficiently use space, there is no unnecessary network traffic, etc. The reasoning is that at “Google-scale” (Gs) if something takes 10% longer, that’s 10% more electricity they have to supply, 10% more machines, and 10% of the Google IT infrastructure budget is a big, big number.

    I’ve never worked at Gs. In fact, I’ve never worked at 0.001Gs. Most of my work in software development has been to support dozens, or maybe hundreds of users. SQLServerCentral, which was a joint programming project, was my largest piece of software , and that was built on other pieces of software, with little contributions from me and lots of Andy Warren’s keyboard sweat in the early years. Despite working on small projects, I still have always learned to consider the little things.

    When you grow up with compilers that take minutes, as in 10 minutes to compile a few hundred lines of code, you pay more attention to your algorithms. When you grow up with kb of memory, you use it wisely. When you work across a 300 baud modem, you don’t mess around with lots of data transfer. Even though many of those constraints don’t apply, I still try to be careful and watch my data types, watch my round trips, and be aware that there are actually bits being whipped across the ether or in and out of transistors in a not-so-little package on my computer system.

    The argument about “just buying more hardware” has some validity, but it’s not an excuse for not improving your skill and becoming better at your craft. As my friend Jeff Moden often quotes, it doesn’t take any more time to do it right the first time. That’s true, but you need to know how to do it right, we at least well. For all of us, that should mean some regular effort to improve your skills and become better at your craft, just like Google looks to constantly optimize their own systems.

    Steve Jones

  • More Triggers

    In the old days of T-SQL, back when we wrote “CREATE TRIGGER …. FOR INSERT” we could only have one insert/update/delete trigger for each table. Eventually SQL Server allowed us to have multiple triggers, and even have some control over in what order the triggers fired.

    Triggers are often hidden objects that confound DBAs who aren’t aware they exist. It’s not easy to tell when a table has a trigger on it, and since we don’t often use triggers, it’s not the first place people look when something strange happens.

    However triggers are useful, and it seems that there are many people using them. For this Friday, I wanted to ask how people implement triggers in their applications.

    Do you prefer one trigger for each table action or multiple triggers?

    I’m curious what’s the 80 in your 0/20 rule for triggers. Should all update actions be handled in one trigger? Or should there be one trigger for business logic  and a separate one for auditing? I’m not sure it matters a lot for performance, but I can see that it might be easier to manage and track fewer triggers. The flip side is that something like auditing can be handled with one trigger, and business logic with another: a clean separation.

    Triggers aren’t usually my first solution to a problem, but I do think there is value in using them. However I don’t see a lot of guidance about how to best implement them, so I’m hoping your answers today will help.

    Steve Jones

  • Code of Conduct for Software Maintenance

    I ran across this article about a recent symposium for CIOs where a code of conduct for IT maintenance that was developed as a guideline for how companies want their software vendors to behave.  This is strictly a customer driven initiative, organized by the Gartner Group, to try and ensure that software companies treat their customers fairly.

    I was surprised to hear that the CIO of Lowes say that software maintenance costs are the largest growing line item in his budget. If that continues, then the price of maintaining software could be a real issue for companies. If it is, then will they slow down they software upgrade cycles? What happens to the innovation of software if companies expect versions to be in production use for 5-7 years? Will that impact the 18-24 month cycle of SQL Server?

    It’s hard to say what might happen, but I do think that sometimes the cost of software maintenance is out of line with the true maintenance costs. Is a 20% margin fair? Especially when it seems every software package out there needs regular maintenance in order to work well. Is that because software just needs repair and enhancement once it gets used by the public? Or is it because software vendors are not testing enough and expecting clients to just live with their level of quality?

    The code is a good idea, and if enough large companies agree that adherence is necessary for them to purchase upgrades, I can see software companies starting to abide by its provisions. I have to say that Microsoft already follows some of the guidelines, like regular patches for its products. I think Microsoft has fair licensing practices for test and development machines, though it might be nice to see different support levels for different levels of criticality.

    Steve Jones