Voice of the DBA

Tag: software development

  • 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

  • ConFoo–The Future of Database Development in Containers

    I delivered a talk at the ConFoo conference. I’ve never been to this live, and when I submitted last year, I was hoping this would somehow be a live event in Montreal. It didn’t happen, but I joined the virtual event and gave my presentation.

    The deck is here: FutureDBDevelopment_confoo.zip

    No real questions, but lots of interest, which is great.

    If you didn’t stay near the end, I talked a bit about the Spawn.cc project and the journey the research group has taken to learn about Kubernetes and file systems. It’s been fascinating to watch the project evolve. The API used to change almost weekly as it was improved and enhanced.

    A few resources: