Tag: software development

I typo things. I make mistakes in the QOD, checking the wrong box. Even in a browser at times there’s a button or hot area too close to the bookmarks bar and instead of completing an action, like checking my VSTS control panel, I’ll end up on some other website. It’s really annoying, but it’s also an issue that occurs when my muscle memory takes over with my fingers not moving as expected, or moving quicker than the system expects.

In Star Trek or media, we see these flat, touch interfaces similar to smartphones, but there’s never any mention about the missteps or mistakes that could be made by users selecting the wrong item. As we move further from hardware controls to software selections, are we worried about issues? Is this something we run into with our interfaces?

I certainly think so. No matter how often I can do something correctly, I make mistakes. Often simple mistakes, born of impatience. This is especially apparent in Azure and online interfaces where the control, or the browser, might not respond as quickly as I expect. As a result, I might click something multiple times, spawning more actions than I expect. Or I might have an unexpected action occur.

This is one of the great arguments from me for having local software. The interface interactions tend to be more reliable and expected. If nothing else, a local process can allow control of the input buffer, discarding or limiting the multiple clicks that cause issues.

As we move forward, software designers should expect that users will make mistakes and ensure there are ways to cancel or undo accidental mistakes made in an interface. This isn’t always possible, and certainly there are some actions that might not be easily undone, but as we become more dependent on software, we need to consider the potential mistaken actions that users will make and provide methods to correct issues. Especially where data is involved.

Steve Jones

The Voice of the DBA Podcast

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

When I read this blog post, I was transported back to simpler times, when I learned to develop applications on 8088 processors. Back then, to make the system go faster, we learned to do less. It’s certainly true that the less work a system performs, the faster it can complete the limited set of things it must do. Working within C code, most programmers I knew back then tried to optimize algorithms by reducing the amount of work that our CPUs needed to perform.

In T-SQL, we don’t have the low level of control we might have in other languages. In fact, our language has a relatively small number of instructions that we we use to build queries and applications, though that number continues to grow and expand over time. I am grateful for that, but also realize this brings with it additional chances for developers to write code that does more work than necessary.

For much of our work, optimization consists of finding ways to group our operations together. Building a set-based solution takes advantage of the way in which SQL Server most efficiently processes instructions. Far too often there are developers that write inefficient code because they apply techniques they’ve learned from programming applications in some other language, or even from some other relational database.

For a given system, there is a known amount of work that can be done in a period of time. There are also restrictions on the various resources involved (disk, CPU, network, etc). Reducing the load for each of these resources, especially in multi-user systems, can dramatically increase the performance of your system. SQL Server is built to manage concurrency in a variety of ways, but poorly written code is a great way to overwhelm the system.

Do less. Get more performance.

Steve Jones

One of the ways in which many software development teams have tried to improve is by examining what has worked in other organizations and projects and experimenting with ideas. Across the decades that we have been using computers, there have been quite a few models, the most well known of which is the CMMI Model from Carnegie Mellon University.

The CMMI Model contains lots of good ideas and practices, much like Six Sigma, ISO and other frameworks. However we (as a group) often don’t follow many of the ideas. It seems that so many developers (under pressure from managers) work to just complete tasks, without regards to the well known, valuable techniques of measurement, improvement, and more.

However there isn’t much magic in using any of these frameworks. They all cover similar concepts, which are based on measuring what you do, taking that feedback to alter your process and get better, as well as then working within a structured process that is repeatable. Do more of what works, and do less of what doesn’t. Adjust your way of working regularly.

The problem for most of us is getting a group of people to actually follow a process over and over. It seems that we continually want, at least as a large group, to cowboy code our way through development cycles, without learning from the past. Of course, I meet plenty of people that use an ALM (or DLM) process to build software, and they all espouse the benefits, but they do note that it takes a long time to adopt a new process throughout an organization. A year of investment isn’t considered uncommon.

Perhaps that’s the problem? Can management actually make the investment time to build out better processes? The media hype says they want to, with all the DevOps hype. Plenty of companies, including Redgate Software, are selling tools that companies use to help themselves adopt a process. However I wonder how successful organizations are. Is there enough continuity in the technical staff and management to actually make a change? It took Microsoft years to change. Are you moving in that direction? Is there any chance you will?

Steve Jones

The Voice of the DBA Podcast

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