Like much of the software that Red-Gate develops, SQL Response somehow demanded to be written. It coalesced from a large number of conversations with DBAs, both professional and accidental, who knew what they wanted in order to turn the tide in their battle with increasing workload. It had to be both simple and completely robust, and needed to alert the administrator of all the most common events that needed attention on any of the database servers for which he, or she, was responsible.

“
In the end you can’t sell rubbish.
 It has to be good stuff and it takes
 pain to get there
                            “

Where a development team starts with a fixed idea of what it wants to write, then the process is easy, though the results aren’t always right. Where it has to meet the needs of its users precisely, require as little training as possible and demand minimal attention, then the going gets tough. Added to that, the remorseless testing, and obsession with quality, and the development process can be long and unremitting.

It is apparent that the heroic age, where software was written in bedrooms by geeks fuelled with pizza and coffee, is long gone. SQL Response is the result of teamwork, where technical authors and designers take some of the lead, rather than follow, and the end user has the final say about how the product works. Testers will then make darned sure that it works. This is a world of development famously described by Linus Torvalds as being ‘100% perspiration’.

To find out more of the details that went into the long process of developing SQL Response I decided to talk to two of the developers in the team; David Connell and Nigel Morse, over a Dim Sum lunch in a Cambridge restaurant.

---

RM:

Nigel, how, and when, was SQL Response conceived?

NM:

It started around 14 months ago after some in-depth conversations with a number of customers. Our designer (Dom), the product manager (Colin), the initial project manager (Dan A) and myself went out to talk to customers; and we built up a picture of a tool that they wanted to use that would make their job easier.

RM:

Is that the usual Red Gate way of doing things? You visit customers first to see what they need in order to do a specific task; and if there’s a missing tool you then develop it?

NM:

Well, it’s our customary way of working. We go to see the customer in their job, work out what they’re doing, hear their opinions, what they want to see from us and then go off and design software on the back of those conversations.
We start with the input of our user experience designer. The very idea of having a user experience designer was a whole new experience for me. It was fantastic to have someone whose main interest is the look and feel of the GUI and whose expertise lies in its design. In the past, in my previous job, I had to come up with my own UI.
The best way to describe it is that Dom designs the ‘User Experience’ and it’s very much this design that drives the way we build the product. What does the user want to see, what do they want it to do when they see it?
Obviously you can’t just throw this together –
The fruits of the first ideas meeting

 

there’s some sketching and ideas and research about what we can/can’t do. I dug up the fruits of our very first ideas meeting.
‘Obviously, you can’t just throw this together’

DC:

One of Red Gate’s priorities is usability, so we do a lot of usability trials, but even so it was quite unusual for us to speak to as many people as we did during SQL Response’s development.
Obviously we have to produce tools our audience wants to buy. So our rather simple philosophy is that it’s a good idea to have a dialogue with those people first.
Here at Red Gate we exclusively use scenarios and personas. There’s lots on the web and in books about this topic. It’s worth a separate discussion another time.

RM:

When you had discussed and agreed the personas and their experiences, what was the next stage?

NM:

Well Dom started to design the interface. He doesn’t write code, he just cares a great deal about the aesthetics of the interface, so he begins mocking things up using Visio. He comes at it from what the user wants to see. Every dialog is constructed. We discussed what is possible and impossible from a technology perspective. Then we analyse what could be implemented and refined. Finally, we have to actually cut some code.

RM:

Where did the name ‘SQL Response’ come from, because it doesn’t actually respond, does it?

NM:

Well, there was a long debate about the name. It was called SQL Camel at one point because we could never come up with a name for it. There was also SQL Monitor. In the end, we settled on SQL Response, as the tool gives the DBA information to respond to problems that SQL Response detects.

RM:

It’s taken 14 months of development to get everything right for release. Did you expect it to take that long?

NM:

Actually no. The beta was ready after around 6 months. We then spent around 4 weeks gathering feedback on that and watching people use the product, doing remote usability trials through online sessions.
This is where we can view a person’s machine and ask them about improvements we could make. As we watch the person working the interface we can also see things that could be improved for the user experience.
Nigel and Colin phone a customer

We made a sample of perhaps 10 phone calls to follow up the online sessions. After taking lots of notes we were confident that we could modify certain things.

RM:

I’m interested in the online sessions. How do you coax people to tell you just enough information?

DC:

You have to be careful because you can’t say too much in case you influence their answers! They explain to you what is going on in their mind with the tool and there are plenty of ‘what ifs’. We then go back and draw up more trial designs. After the comments from beta-testing, it can take a long period of time to get the product right – for us this meant months of critical redesign work.
That’s the interesting thing with SQL Response. Neil and Simon took a really brave decision in February this year not to release it when they could have done. It was already a good piece of software and Red Gate could have made money straight away, but instead we all listened to the user responses and made the decision to go and redesign the interface in order to meet what the users wanted. So Red Gate’s invested a lot of money making SQL Response an even better product.
This still meant though that Neil and Simon didn’t just want us to keep on developing it for development’s sake. There was a tight time-scale too.

RM:

Is that a common thing to happen in software companies?

DC:

No it’s not at all. It’s unusual to say ‘No you can’t put this out now because we want to make a better product’, because essentially you’re not making any money, perhaps even losing some if you felt the product could have been released earlier and still sold.

RM:

Is there a typical customer for SQL Response?

DC:

I suppose the typical purchaser would be a DBA or a team of DBAs already looking after several SQL Servers – ten or more – and the DBA also has other things in his or her working life such as, Exchange boxes. They might not be purely a SQL Server DBA; they might be developers in their full-time job and a DBA on the side.
But the most significant thing about them is that their day would be time-poor. They wouldn’t have much time to do anything more than they are already doing, so a tool that would help them cut some of the repetitive tasks down in time would be beneficial.

RM:

Did you look at what was already in the the market?

DC:

No we didn’t, More important for us on the development and design side was usability, and this was the major thing that came out of our discussions with customers; that and a no-nonsense style of monitoring. What customers said they wanted was a minimum amount of information to make the right choice, relevant to the problem that needed solving.
At the beginning I decided not to look at what competition because I needed a clear mind. We developed SQL Response based on what our customers told what they wanted to see: Nothing else.

RM:

How does SQL Response point the user towards possible problems?

NM:

An alert appears in Response’s GUI – you can choose to receive an immediate email alert as a problem occurs which can also be sent out to other email addresses. But you won’t then get another email about the alert if the problem persists.
A lot of people who have tried other tools were telling us that they are deluged with emails telling them about problems, but the email isn’t specific enough and they can’t use it to solve the issue.
The emails in SQL Response give the user a brief summary of the information. It will also have the server name in it and a link on it telling the user where to look. If you have the client on the server, and click on the link it will bring up the necessary details in a brief message, and take you to the appropriate problem. DC. It is actually possible to solve some of the problems using the summary information in the email alone. Some problems are always going to be tough to solve, but getting hold of the information to begin resolving it should be a piece of cake, really.

RM:

What is the difference between an alert and a recommendation provided by SQL Response?

NM:

Well, it provides both alerts and recommendations so users can, if you like, increase SQL Server availability. Both alerts and the recommendations work as alerts to problems on your SQL Servers, but the difference between them is in the information that accompanies each type of information.
A recommendation provides you with suggestions, based on best practice, for how you could resolve the problem, and an alert contains useful diagnostic data to help you resolve the problem.

RM:

You must have altered the documentation because of the stall in releasing it. When did your technical author pick up the threads of the documentation?

NM:

Right from the beginning. Rather than ask Brian, our technical author to write documentation right at the end of the release cycle, he came in from the start. He went over all the designs and the early builds to make certain that what we wrote was not only correct but was easily understandable by the user. That’s something we sometimes forget. As developers we know what it is and how it works but that has to be translated into the right terminology to make sure the language is consistent. Pretty much all the text has come from Brian’s hand. So this means he has a great understanding of the product and is able to put the interactive help in the right places. He also wrote solid and helpful online documentation.

RM:

What about testing? Red Gate has its ‘relentlessly tested’ strapline, but how far does this go with SQL Response?

NM:

All the way! Almost as soon as the first code hit the build server and a build came out, the testers were all over it.
To get this kind of feedback early on was an absolute revelation because it means that someone is pointing out errors straight away. It might not always be easy as a developer, but the benefit of this is enormous because the earlier you find issues, the earlier you can fix them, and the easier it is then to modify the structure and design of code – if it’s necessary. Of course this is far, far better than finding it several months later when you discover that one thing you either didn’t realise or forgot about means you have to rip out and re-factor your code. After all by that point there’s no time or it’s just too painful to do that so you end up hacking round the problem. Catching the issues early is so much less painful.
After a month or two, other testers would join in the testing, in one of our celebrated ‘bug hunt’ sessions (complete with cookies and donuts for sustenance over the hours of testing). Someone would open a bug, you’d ‘fix’ it, then another person would come along with some extra small detail and you would need to ‘fix’ it again. Relentless is the word.
The great thing is that other people come at things with a different perspective. They can see a whole world of cases you didn’t consider. Testers at Red Gate have access to versions of Windows and SQL Server, and they use every synapse to bring your code to its knees.

RM:

Is this sort of testing rather painful?

NM:

It is painful but it makes sense and it changes the way you code. You start to think in other ways as well, how to outwit the testers, how will they test this, and how can I deny them opening an issue? It’s very good practice and certainly sharpens the mind. I find it fascinating just having my stuff tested instantly. I love it.

RM:

I don’t want this to sound too cheesy but it sounds as though you detail the release to near perfection as possible before you ship?

NM:

We do. I think the steady and persistent work of developing software is actually life-enhancing. If I wanted to earn piles of money I’d go off and do contract work somewhere but I actually like writing software programs that people want to use. It’s so rewarding. It’s just something I love to do.

DC:

I think it’s true to say that as well as relentlessly testing the software we relentlessly design it too.

RM:

A lot is made about how easy SQL Response is to use. How hard is it making something simple?

DC:

Really hard! One of the most difficult things to do is keep something simple and achieve the right balance of complexity into the configuration level without making it all overly complex. This isn’t easy, but the whole team has done an excellent job in getting there.
In the end you can’t sell rubbish. It has to be good stuff and it takes pain to get there.

SQL Response is now released. For more details, or to download the 14-day evaluation, click here