Voice of the DBA

Tag: software development

  • 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

  • Always Retry

    When multiple people connect to a SQL Server database and attempt to query or update rows, blocking occurs. This is normal, and we expect a certain amount of this, usually very short lived. If it’s not, then having tools that monitor your database and can quickly let you know which connection to kill is important.

    There are also issues like network hiccups and deadlocks, which can cause a transaction to fail and roll back. In these cases, the application should retry a query, often quickly, without bothering the user. This isn’t something that most developers code into their applications, though they should. However, is this something that lots and lots of developers ought to learn and re-implement over and over?

    Microsoft has released a preview of a configurable retry logic in the SqlClinet driver for .NET (others coming soon). With this enhancement, developers can tell the driver how to react with some types of connectivity errors and perhaps resubmit the query. There are various options you can read about, and you ought to carefully test and you decide to use before you deploy them to production.

    To me, this is long overdue. Software ought to work for us and make our work easier, including easier for software developers. Often I’ve heard many vendors point to the configuration options and flexibility of their software, tool, or framework, while placing the burden on developers to write a lot of the code to actually take advantage of the tool. Whenever possible, we ought to make the preferred choice, the best practice, the most common code an easy choice by making it easy to add to a system. Give people flexibility when they need it, but make it easy for them to see the benefits of your software quickly.

    Steve Jones

  • Bug Management

    All of our software has bugs. Some bugs are just bad code, some are incorrect specs, and some are things the client thinks should work differently than the way the application is built. In any case, we know there are plenty of bugs in software.

    How companies handle bugs is interesting. Some feed these back to the current developer team. Some use junior developers to do bug work. Some have support teams that focus on bugs and coordinate with developers.

    What if you get parts of your software from another source? More and more developers are using open source libraries, packages, frameworks, and more. How do you deal with bugs in those situations? As someone that has worked in this manner, tackling those bugs yourself is problematic and introduces other issues with your software development pipeline when the upstream source is updated.

    Google is taking a different approach, actually assigning developers to projects that they need. One example is in this piece, about a couple developers assigned to the security of Linux. While the headline is that they keep finding lots of bugs, the more interesting part to me is that Google internally builds the OSS they use from source, add in their patches, and then use pull requests to get them accepted into the main project.

    I don’t know that many of us can afford to sponsor a developer to contribute to a project full time, but I do like the idea of using a fork to build your software from source. This might not prevent bugs or malware, but if you are hit in this manner, you know that lots of others will be as well.

    Steve Jones