Life is too short to be spent developing (and using) mediocre software. To produce great software requires more than a couple screens and buttons. It requires the work of people who care about developing a product to be proud of; a product which people love to use; a product that works just as you expect it should. It requires craftsmanship.
So what exactly makes great software? For starters, it has these four qualities:
Most of us have used software for awhile. We have basic expectations for how things should work. For example, we expect search to match words even if the capitalization is different, and expect suggestions to be displayed as we’re choosing people to send email to. There are lots of these types of things, and if the software doesn’t match your expectation, you won’t love it.
I was just reviewing an app with a search screen which had four sentences of text describing how it should be used, what it will return, and (worst of all), how it returns results “based on exact character matches”. What exactly does that mean? Does the end-user know what that means? And what should the user do, based on this information? It would have been better to just design the app so that it just makes sense.
The initial time to develop software is nearly always less than the time spent adding new features to it. So it needs to be simple to add things to it. This doesn’t mean spending a month planning before doing anything, and it doesn’t mean building a massive framework that can do everything under the sun. It means building something simple and well-designed, and because of this, having the confidence to make changes that won’t destroy the whole thing.
Software which is well-designed is almost certainly extendible. When I first started at IBM, I was given a task to design a query optimization engine. The first time, I built something that worked, but it just didn’t seem right. It wasn’t beautiful. So I threw it away and tried again; better, but still not there. I went through this a couple more times until finally deciding on something that I was proud of. When the next release came around, of course it needed to have new features added to it. And because it was well-designed and extendible, it didn’t take long at all.
Sure, most software works well in ideal conditions. But what about in the real world? Networks are inconsistent, GPS is spotty, and servers get overrun. The software needs to handle these situations and handle it better than showing an error message the user can’t do anything about. If your app pops up little error messages randomly, users will just uninstall it.
It’s thoroughly tested.
A typical developer will try a couple things in their app, make sure the basic scenarios work, and then say it’s done. This typical developer doesn’t really have confidence in her app; rather, she knows that someone else will test it. And if they don’t catch all the problems, then someone else will figure it out. And if it ever comes back to her team, then someone else can fix it because she’ll be at a new job somewhere else.
To be done right, testing needs to be done early and often. Testing is the key to having confidence in the software, and automation is the key to doing it early and often. If test automation is built early, then developers have the confidence needed to make incremental changes and improvements. It’s testing which ensures that when it needs to be extended, all the old stuff still works.
We build confident software.
We work hard to build software that we are proud of. From how it looks to how it is coded, you can trust that even an obsessive person (like myself) can love it. This means working closely with clients to understand who will be using the product, what are their motivations, and what are the most important features to include. We use automated test tools to ensure the highest quality and reliability. And we love to add new features to software which we already developed. But most importantly, we want you to be happy with the final result.