Ats Spit And Polish

Part of AtsGoesExtreme and the AtsDiary. See also SpitAndPolish?.

I think that's it's crucial that the GoldOwners? on a project be satisfied that the project is being run well. If they're concerned about the competency of the project's managers and developers, they won't continue the project. That's why ATS is using AtsStatusReports?, even though they're technically non-productive overhead.

SpitAndPolish? serves the same ends, although it has benefits other than pleasing the GoldOwners?. Essentially, ATS strives for a high level of polish in its user interface. It has a very clean-looking, attractive GUI, particularly in comparison to most business applications I've seen.

This GUI was developed in the first phase of the AtsProject, and it undoubtably took some time away from developing UserValuedFeatures?. But I think the attractiveness of the UI was a big part of the stakeholders' satisfaction with the execution of the project, despite its cancellation. First impressions count, and ATS simply looks better than the other business applications that are used here.

That's not to say we drew lots of .gifs or anything like that. We just put a lot of effort into making sure fields lined up properly, had the right amount of whitespace between them, and were sized properly. Before shipping a release, we went through the application and identified spelling errors, ugly layouts, and inconsistencies from one window to the next, and other minor UI problems. And then we fixed them, along with any bugs we found during that pass. There's only two .gifs used in our application, but we did spend a developer-hour or two searching the Internet for attractive-looking, royalty free .gifs of the correct size that would complement each other on the screen.

One easy-to-describe example of a polish issue we found and fixed, although it's more complex than most polish issues we dealt with, is the search button on our windows. We identified a natural tendancy to push "enter" to perform a search, so we made sure that the search button would respond to an "enter" keypress.

As I said, this spit-and-polish pass did take time, although I can't quantify how much, since it also included bug fixing. But it paid off in stakeholder satisfaction, and also in developer morale. We had a commitment to quality, and it wasn't just a slogan. It visibly showed in our application, and I think that helped the team jell by providing a feeling of eliteness.

I find it difficult to believe that creating misaligned, inconsistent GUIs is remotely more cost effective than making clean GUIs. As you said, you didn't go whizbang and write WinAmp, for instance, but at least you took effort to make something people could use. This is a very good balance of effort. So, I commend you. Sincerely.