Voice of the DBA

Tag: software development

  • Working in Smaller Teams

    I don’t know what the average size of a team is, but I know I’ve worked in all sizes in my career. I’ve had teams of 1-3, which is common in database work, but I’ve also been on a 20 person Ops team. I’ve been in 2 person development teams, 25 person teams, and everything in between. At Redgate, it seems most of our development teams are less than 10 people, but I’m sure we’ve exceeded that at times.

    I do think smaller teams are better, and they are certainly easier to keep track of what everyone else is doing. Once a team becomes large, even with regular status reports or meetings, there is too much information to easily hold in one’s memory about tasks other than our own. Knowing what others are working on can be invaluable in coordinating and avoiding conflicts. This also ensures that the team can more easily ensure code is written in a similar fashion and knowledge is easily shared.

    There is research that seems to indicate that smaller teams are better. This article talks about some of the reasons small teams seem to perform better. These all seem to intuitively make sense to me, and I’ve certainly experienced people behaving in these manners. In the second piece, there is advice on how to get teams to be more effective. The biggest advice seems to be a lot of what we do at Redgate. We empower teams, give them tools, and don’t manage them in traditional ways. We hold them accountable to get work done and meet goals, and we challenge them, but we want them to move forward, not work in a particular way.

    Building a team is hard, and getting a team to perform at a high level is very hard. I do think that the internal talent and motivations of individuals can make a big difference, but I also think that management can bring out the best in people, or it can ensure you never get anywhere near the potential of team and encourage under-performance.

    It constantly surprises me how often I find managers and their organizational culture built to control and not inspire employees to do their best. I think it’s a holdover of years of working a certain way, rather than supporting and encouraging each person supervising others to get the best from others. I hope this changes, but it’s certainly something I try to detect in interviews before I ever commit to a new position. I hate working for micromanagers and never want to do it again.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • What You Should Know About Coding

    What are the important things you should know about writing T-SQL code for an organization or on a team? I’m sure that many of you have ideas, and please, feel free to share them with us with a comment. As you think about your answers, think about this as well: what do you wish you’d have known when you started writing code?

    I went through university quite some time ago, over 30 years ago, and some things have changed in this industry. Not so much in the way we structure the code we write, though we have gotten much better in some ways. Rather the way that organizations work has dramatically changed. It’s not just this new DevOps thing, but more that many organizations are starting to expect developers to do more than sit in a cube and react to a set of tickets or a specification written months ago.

    More companies are expecting developers to think and interact with others, knowing more about other parts of their environment and application. More developers work in teams, and perhaps very interesting to me, the once dreaded and heavyweight code review that seemed to die during the middle of my career has become a commonplace, quick task that developers do every day now.

    There’s an interesting piece, written by Ryland Goldstein, about the things he thinks developers should be learning in college or early on. I thought it was interesting to see him open with lines of code (LoC) as a metric, and show the growth in code for some large applications. To me, LoC hasn’t been important at any point in my career, but I know it was talked about while I was in school.

    He does talk about some things that good code should have, and I agree that most of the time the language doesn’t matter. I do think his points on reading code, and learning to work with other people’s code is good. To me, this really means we want to adapt and learn to write code in the style that our team uses. That can have a huge impact on group productivity, when we can write in a similar style, and then also read (and review) code quicker because it’s all the same style.

    Perhaps the best line is this: ” Every single member of our team (including me) would have a full blown panic-attack if someone ever suggested committing un-reviewed code.” I think too often the database side of things ends up committing (and deploying) un-reviewed code too often. We could to better, even if we need to teach someone how to review our code. Having a second set of inexperienced eyes might not prevent mistakes, but it certainly might help others learn to write better database code.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The First Rule

    A long time ago I read a book called The First Law. It’s a legal thriller, and I’d recommend it. It has nothing much to do with databases, but I was reminded of the book and the rules of any particular process when I saw a post called The First Database Rule.

    The post is from Seth Godin, who is really a marketing individual, but I do think his rule makes a lot of sense for clients. I also think that as both developers and database professionals, we forget that most of our clients would prefer to have our systems follow this rule: it should be as simple to fix an error as it is to make one.

    I’ve worked in many systems, and with many people, that expect data entry or loads to go perfectly. They expect things to work and want to blame the process, the person, the file, or something else when something doesn’t work well. What might be worse sometimes is that we expect some data in the database to be immutable, like a PK, assuming that clients will have and enter all the correct data at once. Most of us do allow changes in our databases, but we don’t make it easy, especially if it’s a piece of data like a primary key.

    This is one reason I dislike many natural keys as PKs. We make mistakes when we enter them. Heck, I’ve probably typed my name a million times on a computer keyboard, and I still make mistakes. Even in data entry forms. What’s worse, I have some auto-fill selections in my browser that are incorrect and I’ll select the wrong one at times.

    Fixing mistakes ought to be easy. We ought to expect that we will get data wrong. We’ll load it wrong, we’ll transform it wrong, and our DBAs will type corrections wrong. Design the system to account for mistakes and ensure that problems can be quickly fixed. Whether by a client or a sysadmin.

    Agility ought not to be just how quickly we can change the software. It needs to include the ability to change the data, which is the most important part.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Microsoft, Think DevOps First

    This post from Melissa Coates is a good example of not thinking through your product architecture early on. The short version of the post is that Power Bi Desktop is a better place, perhaps really the only place, to author your Power BI Reports. Melissa covers a few potential issues while using the Power BI online editor, but the big item is that you cannot easily prevent conflicts and track versions there.

    Power BI started as the online service, with the Power BI Desktop tool seeming like a bit of an afterthought. At least from the marketing perspective as all of the early demos and media from Microsoft was about the online report service. Since then it’s evolved to become the primary way we will build reports in SQL Server moving forward, which I think is a good move.

    While I can understand the developers at Microsoft not really thinking that the service would on-premises and maybe not considering the need to provide some text format for the reports, I can’t understand why they didn’t learn from the Integration Services team and realize that binary versions of programmable items don’t make sense. We need a format that can be easily versioned, and maybe more importantly, stored in a VCS and diff’d in a way humans can understand.

    When building a format for storing code, please consider the need to work in a team and version the changes made. This means any format should not be a) binary and b) difficult to decode. Separate visual elements from logical elements and ensure a text version of this can be examined by developers. You can use XML, JSON, YAML, or any other text based format, but choose something that makes sense. Even if you add your own extension, ensure that standard tools that work with code can use this.

    I do know the PBIX format is a ZIP file, but zip files don’t easily integrate with a VCS. We could use hooks to extract/rebuild out files on commit/checkout, but that’s cumbersome and silly. I’d rather that the PBIX were a folder with the files inside. Users, including my Mom, can zip a folder and email that if needed. To me, that would have been a better structure from the beginning.

    Microsoft is supposed to be a company providing platforms that we build upon and use in our work. The decisions for the Power BI service seem to be poorly thought through with that in mind. I’d urge them to create a baseline set of rules for future products that consider DevOps, teams, and the need to track code.

    Steve Jones