Voice of the DBA

Category: Editorial

  • Kanban

    With more and more software developers trying to find ways to better build software, we have seen many new methodologies and processes being used for managing workloads, tracking development progress and more. Perhaps one of the most interesting adoptions for companies looking to speed up their development has been the use of kanban boards for tracking work in Agile or Scrum systems. Kanban came about as part of the manufacturing process at Toyota and proved very valuable for them.

    We use kanban boards all over Red Gate, for everything from software development to marketing campaigns, to books we’re publishing. It’s kind of amazing. However I hadn’t thought about using one personally until I saw this piece on LifeHacker (a related piece on visualization as well). It’s hard to know how well this would fit for me to manage my workload at SQLServerCentral. While we use a kanban board for a few tasks, like Stairway Series, I think this would be a bit complex for the variety of tasks I deal with on a regular basis. I suspect I’d need a number of kanban boards, a separate one for each type of work, and then I’d be trying to somehow manage my workload between all of them.

    However I do think that for software development, and for a limited set of tasks that you want to track and organize, kanban is a good way to easily visualize the workload. I also think this could be a good way to manage your career learning. Set a list of things to learn, break them down into tasks (watching videos, reading an article, writing a CTE) and then track your progress across the year.

    Having a visual reminder can be motivating, as long as you can make progress and see work moving through progressions. If not, it can be another source of pressure or stress that you avoid. However it’s an interesting technique that might work well for teams that are focused on a single set of work.

    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.

  • The Devil’s in the Details

    This week I was scanning through a number of SQL Server posts (in between working on April Fool’s Jokes) and a couple of them caught my eye. They dealt with simple subjects, but subjects whose details are important. I’ve often found people have had performance issues in SQL Server because of simple misunderstandings of how the system works, or because not enough weight is given to the impact of small details.
    Kimberly Tripp (of SQLskills) wrote a basic post on parameters, variables, and literals, which would think most programmers would understand. However I realize more and more that lots of people that write code in the world taught themselves. That’s amazing, but it does mean that people have many different holes in their knowledge. What I might consider basic or common knowledge might be something that another person never had been exposed to. In any case, Kimberly does a fantastic job of laying out the differences in these three concepts, how they work side by side, and how the choice can dramatically impact performance of your code. Read this one.
    The other post this week was a fairly simple post on data conversions by Rob Sheldon. Again, precedence and conversions are something I dealt with when writing C code, and you do not want to get things wrong there. However many people might not have the same background and wouldn’t understand by varchar and nvarchar wouldn’t be a basic, simple conversion with little cost. Or why the type of conversion might result in far different results than you expect. Since we often test with one set of data and our application work with a (much) wider set of data, this one is a must read as well.
    There are so many things you should consider when writing code it’s really a constant and regular effort to improve your skills in this business. You won’t learn everything, or learn something every day, but pick things up and practice with them. Learn to build better code, one technique at a time, and cement that knowledge with actual implementation in your work.
    You’ve got at least two new things to look at this week, so pick one and try to ensure your code next week considers these details.
    Steve Jones

  • Large Chunks of Data

    This editorial was originally published on Sept 17, 2010. It is being re-run as Steve is on vacation.

    I saw a post recently where someone talked about trying to get better performance from a report. They were selecting 5mm rows from a table and wanted to see if there was a more efficient way to chunk out this data so that the instance would not report memory errors.

    My first question is what kind of report has 5mm rows of data? That’s just too much data.

    How long can a report be?

    From your experience, talking with people, looking at what they analyze, how big is a report? How much data can you really display on a report and make it useful for users?

    I’m thinking here in terms of the raw data you show. A pivot table can summarize millions of records, but realistically I thin kit becomes hard to examine more than a few hundred data points on a page. Whether they are raw data or aggregates of other data, it seems there’s some limit to what a report should provide.

    After all, that’s why we have drill-down 🙂

    Let us know this Friday what you think; what you have observed? Maybe we’ll  help others to build better reports that are more practical and useful to end users, as well as easier to develop.

     

  • Microservices for Databases

    I ran into a talented developer last year that was talking about microservices. It’s an interesting concept, one the Netflix has adopted with success. I was excited about the possibilities of using microservices until this guy said that everything could be a microservice and the day of the RDBMS was over.

    That was silly, and I’ll admit I struggled to remain polite in the discussion. Eventually I had to walk away because the idea of no RDBMS for any application is a ludicrous as the concept of using an RDBMS for every single system dealing with data. It’s frustrating to talk with someone that views our industry as too black and white. There are many ways to solve any problem and many problems can be handled by a variety of techniques.

    However I am intrigued by microservices. It’s an area that I want to continue to research, as I suspect that the idea of small, loosely coupled applications, working in a service-oriented architecture, is a great way to scale systems.

    From scratch.

    I’m not sure that many of the monolithic, large applications we have in banking, in retail, in supply chain, in a variety of industries are worth rewriting to use SOA concepts. The return just isn’t there, as many of these systems can be served with bigger, faster hardware as they upgrade.

    Microservices are interesting, and I suspect we’ll see more of them in the future. I also think that SOA, using messaging services like Service Broker, are a very robust way to build applications. I hope that more developers out there learn about SOA and find ways to start building system that can work well together, but aren’t so highly dependent that changes are difficult or stressful on everyone.

    Steve Jones

    The Voice of the DBA Podcast

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