Voice of the DBA

Tag: software development

  • Do as I say, not as I do

    A common saying from parents, teachers, and many managers, is that you should follow their instructions and not necessarily their behavior. This is a very human thing to do, with many of us struggling to follow the behavior that we ourselves want. Instead, we follow the vagaries of our moods and desires. We do this even as we tell others to do things that we don’t bother to do.

    It’s not just human behavior, but it applies to how many companies deal with their customers. Microsoft talks often about taking advantage of new features in code and using the platform to solve problems. They dislike adding simple “syntactic sugar” (like a numbers table), and instead prefer you build the code to handle some of these simple tasks.

    However, they don’t really follow this advice, as Andy Mallon showed with a recent post on why not to use a couple of their “recommended” stored procedures. They’re not well written for modern code, they have limitations (or bugs), and could be considered a security risk.

    To be fair, I know that changing code in something that works is always dicey, but at the very least, moving from varchar() to nvarchar() shouldn’t break anything. If there are edge cases, then write some tests and rebuild the code to work better. Maybe, more importantly, these procedures ought to model good code, as Microsoft would recommend to their customers.

    There are a lot of places where different products at Microsoft might not use SQL Server well, and I understand. These might be software developers that don’t know a lot about how to perform good data modeling or even how to take advantage of SQL Server code. However, at a company with the resources Microsoft has, I’d expect them to form teams to handle these tasks and then review and suggest changes to software like Dynamics, Sharepoint, etc. Even if they can’t use the latest features in the SQL Server codebase, they ought to model good practices for all versions.

    For many of us, we might act similarly inside a company. Often we write code out of habit, and perhaps, to expeditiously get work completed, even when we know better. Using SELECT *, leaving out error handling, and more are habits that far too many of us embrace, far too often.

    Start making some changes today. If you know there are better practices you should follow, then take the few extra moments to implement them. If you don’t know of good practices, start compiling a list, asking questions, even post an idea or question in the discussion for this editorial. We all could write better code, and that starts with us actually making an effort to model the behavior we might preach to others.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • T-SQL Tuesday #138–Technology Changes

    tsqltuesdayThis month the topic for T-SQL Tuesday comes from Andy Leonard, whom I reached out to be a host. I was running low on hosts last year, and Andy agreed to help me out. I had expected something on ETL, but I was surprised with this one.

    Andy asks us about managing technology change. He does mention how SSIS changed as he was writing a book, meaning that things he’d learned while a project was underway no longer applied. That’s a scary place to be, and it’s one I’ve rarely experienced.

    Avoiding Shifts

    One reason I don’t like to test beta software, especially from Microsoft, is that the APIs, the functionality, the effects can change. I prefer to have something fairly well settled before I spend time on it.

    I took a chance early on with Windows 7, when they had the “skydrive”, which become OneDrive. I could sync files from my desktop to laptop, and for someone that travels a lot, this was fantastic. It worked through the beta and until a few years later. At some point it stopped and I moved to Dropbox. I still use DropBox, even though this was reborn as OneDrive and enhanced to allow me to have  personal and business “OneDrive” running at the same time.

    Moving on from Immature Software

    I don’t like to abandon software, and sometimes I can’t. For me, I’ve been involved with some of the products that Redgate Software has built. I often see things early and test them to give feedback to developers. This means I sometimes see things before they work well, or even before the development teams might know what they want to build.

    This has happened a few times, but a couple years ago we were evolving one of our products to expand capabilities for customers. I thought we were moving in a good direction and spend quite a bit of time evaluating how the software worked. I was even starting to incorporate this into some automation pipelines and build demos, when the product direction shifted.

    A fair amount of code I’d written had to be abandoned. I felt as though I’d wasted some time, but as I stopped to think, I realized that I’d been learning and growing in this area. I’d understood how things worked, and while I had to write new code, I was able to write it quicker because I understand the general problem space already. Even though I had to expend other effort, I’m not sure my early work was wasted.

    Fortunately, I didn’t have deadlines for a deliverable. If I did, I might have been more upset. If it happened in the future, while needing to work more to get things done might annoy me, I’d likely understand that the growth and knowledge mean I don’t have to double my investment, and likely I’d be better positioned to write better code the second time around.

  • Holding Code in Your Head

    It is hard to write software. Many of us write lines of code, and often if we go back, we find flaws and problems in our code. As I look at the solutions others might give for the same problem, I’m sometimes amazed at the way they tackle the problem and what language features they use. I’m especially always intrigued when I see someone using STUFF() or APPLY in their queries. I know I have a bit of a hole here, as I haven’t done enough work with them in my career. It’s a tool I just don’t think to reach for.

    Part of that is that I don’t know I completely understand how they work in my head, at least not without effort. The lack of familiarity hurts me here, but it’s part of the issue that Paul Graham expresses in this essay about holding a program in your head (essay via Brent Ozar).

    I certainly have held entire programs in my head, and when I do, I think I work a little more efficiently. Certainly faster, and I can change things as I refine the solution I’m aiming for. I also find that when someone else is touching the code I’m working in, even lightly, it is distracting. The differences in reading my code vs. someone else’s are noticeable.

    I think this is where working in a team, unless you are pair/mob programming, can be challenging. While discussing issues with others might help find solutions, I do think that groups need to subdivide code into sections and allow each person/pair/mob to work on that code alone for a period of time. Some organizations do this well, but plenty do not.

    Perhaps one of the best reasons to be careful about touching the same code in a database is the last writer wins. While some tools might work with the code in memory on your workstation, many of the ways we capture and track T-SQL code come from the database itself. If multiple people change the same object in a shared database, we can easily lose code or frustrate programmers seeing strange behavior.

    There are a number of items that Mr. Graham thinks will help programmers write better, or more, code. However, I also think that his problem space is focused more on startups and new applications rather than the legacy code on which many of us work on every day. However, I do take the point that having a more succinct language might allow a programmer to hold more in their head and get more done.

    If they’re are intimately familiar with the language itself. I think that is a skill managers should promote in teams. And something I need to work on with STUFF and APPLY.

    Steve Jones

  • No-code Software Engineering

    Low and no code applications have been around for a long time. In my career, I’ve seen Access, Delphi, PowerBuilder, and various 4GL packages used to build software for business users. Some worked well, some didn’t, and often many didn’t scale. Not all, but many.

    The problems in many of these tools, at least to me, was that many of the “developers” using them weren’t developers. They were business people trying to get something done quickly. Often these weren’t people thinking about performance or software engineering in the way that many developers think of those topics.

    Arguably, there are plenty of Java, C#, and other developers that don’t think things through either. However, many developers do want to solve problems and build interesting solutions. They don’t (often) want the drudgery of moving around UI elements or reinventing CRUD data operations.

    I saw an interesting piece this week noting that No-code doesn’t mean we avoid software engineering. The author praises some of the no-code platforms because they allow developers to do the fun part of building logic and solving problems without the tedious nature of writing an IF statement with the correct syntax. There are a number of reasons given, which sound good.

    I don’t know that I think that no-code is the way to go, but I do get the idea of using lots of proven and tested components, features, services, and more rather than reinventing them. I think that connections to database objects, RDBMS or NoSQL, ought to be easy, and lots of the mundane work of plumbing systems together could be centralized and reused. I certainly think that LINQ or simple query languages make sense, though likely having a way to more quickly and easily build/test/refactor and deploy database methods as well as make them more flexible (select col from @table, anyone?) might simplify database coding.

    I doubt we’ll get rid of C#, Java, or other fairly low level code anytime soon. I write about better programming languages recently, and I can see us moving to more succinct languages over time, but that will take decades. There is far too much invested in current codebases by developers and organizations to think about quick switches.

    The best way to build better applications is to have developers continue to learn, practice, test, and change their coding. They need to seek to be better, which I think most of them do, but management and leaders need to demand this and invest in staff (time and money) to help them improve. Then I suspect that whether you use lots of code or none, all your applications will work better.

    Steve Jones