Voice of the DBA

Tag: software development

  • Rating Bugs

    Is this a big deal? Michigan is the wrong shape, reported on Connect as a problem with the Report Builder 3.0. I guess is depends on whether or not you are showing Michigan in one of your reports. If you are, it’s probably a big deal, and no matter what data is on the report, plenty of people will never get beyond the incorrect shape.

    Is this a critical bug? Is it a must fix for SP1? Does it deserve a high level of priority?

    Triaging bugs like this and assigning a priority has to be extremely hard. On one hand this should be a simple fix, but after the maintenance plan fiasco in SQL Server 2005 SP2, I’ve heard a few SQL Server developers say there are no “simple fixes.” However this bug is not critical to most people; it won’t cause downtime or data loss. For those people that need it, however, it could be extremely critical. It also a little embarrassing for any report that has the wrong shape visible in a map control.

    Should this be fixed before bugs that cause downtime? What if this takes 2 days and those bugs take 2 weeks? Or two months? You could easily get into the situation where a low priority bug keeps getting pushed back because there are more important issues to deal with. I’m not specifically talking about this bug, but rather using it as an example of an annoying, but otherwise non-critical issue.

    As companies work on software, I’m sure there’s some developer on every team that finds items like this one to be very annoying bugs, and would probably just fix it if they had time. Or permission. To me, this is a great reason why you ought to give developers some free time to work on things that they find interesting. My guess is many little bugs like this that can be fixed quickly, would get worked into the schedule.

    Developers like fixing things, and they like easy wins. Give them a chance to work on them.

    Steve Jones

  • Beyond Automation

    Are there some processes in an organization that are beyond automation? In this blog, the author talks about how some processes might be so embedded, or so complex that you could not automate, or change them. I think that example gets a little off track as it examines left hand driving v right hand driving, but it’s still something to consider.

    In my experience, there are many ways to use automation to assist people with work, and reduce the load needed, but ultimately we always need a human in the loop. Someone should be available to check that the calculation or the change in process is the correct one. Someone also has to be able deviate from what seems to be the rule for some process and override it.

    I’ve seen this in the past in a few places. Once where I worked with a chef trying to automate his ordering process. He was sure that he could input recipes, make guesses about usage, and then inventory constantly, adjusting his predictions and a well designed inventory system would calculate purchase orders for him. I don’t know if his predictions were poor, or if the logic wasn’t correct, but he didn’t ever seem to have as good a hand on his inventory as he needed. I used that as a basis for a liquor inventory system when I was bartending, but took the “recommendations” from the system and adjusted them based on intuition. That seemed to work out much better.

    Real life if messy, and often I think we try to simplify it so much with our models that we don’t build a system that really works well. I’m of the opinion that technology is here to assist us, not do the work for us, and we need to keep that in mind as we design software. Allow for the experienced professional to override things and use their experience to make the final decision.

    Steve Jones