Feeling your users pain (and release notes for Secret Server 1.1)

Published Monday, March 27, 2006 11:44 AM

It is a wonderful feeling to ship software - it has been a long hard slog to get this round of features complete.  Especially while juggling our developers across various projects and client work.  This is also a welcome release as we get to use all the new features in our own company Secret Server instance. 

It is also a relief to finally get rid of those few really annoying bugs that I deal with everyday.  The process of dogfooding your own application really makes you feel the users pain - there was a funny (although silly) movie at PDC last year of Microsoft installing pain delivery mechanisms for their developers - then every time a user got an error - the user would feel the "pain").  Even though the movie was silly, it did get the point across.  Often it is difficult to feel that pain since the application is in a business domain that just isn't relevant to you (I remember building a very specific and technical sewer management system for an English county years ago and I didn't even live in that county nor install sewers!).

How do organizations deal with dogfooding when the business domain is not relevant to the developers?  A strict quality assurance process that allows testers to inflict the "pain" on the developers?

Enough rambling, here is the laundry list of all the things taking up our time over the last few months ...

(If you don't have Secret Server yet, get it here)

Release Notes for 1.1

* Support Microsoft Access as a file-based database option
* Add import capability for CSV files (wizard)
* Email notification of secret changes
* Add support for Windows Authentication when using Microsoft SQL Server
* Streamline the secret sharing process to reduce the number of clicks
* Copy to Clipboard must be supported in FireFox (develop new FireFox plugin)
* Add Installation notes to installer
* Implement masking password fields on secret add and secret edit based on user preference
* Generate password feature
* Change Installer to be more of a wizard than a checklist
* Current user should not get notification of secret update
* Ensure that all Secret Server binaries are obfuscated for improved application security
* Installer always reports access denied on write access screen
* Installer: Allow the user to add a first user if there are no users and no secrets in the system.
* Session timeout causes error during upgrade
* SmtpMessageTransport needs to be added.
* GetSecretViewUrl needs a proper url location
* Add Email Address to user maintenance screens
* Add a new column to the SecretAudit screen to show notes
* Add two new options to Tools screen
* Mailto links should also send the SS version
* Add current secret name to secret screens - sharing, history, etc
* Configuration should be added to the toolbar
* Add password strength to ChangePassword screen
* User Edit should not allow you to make edit that would cause system to become dead
* Solve SecretView error on .NET Framework 2.0
* Usernames must be unique

by thycotic
Filed under: , ,

Comments

# Dennis said on Tuesday, March 28, 2006 3:59 AM

Hi Jonathan,
I develop a web-based meeting/room booking system for about a year now. It is an internal application for our
company department. I do not have any rooms to book, so I can't really 'dogfooding' this application.
But when I comes to bug fixing...I can feel their pain. During developing time I started
to create bookings, just for testing purpose, so I created bookings only for the actual month.
(No errors: check;Performance acceptable: check; software quality acceptable: check)
When we had bugs if the user was creating bookings for the next year, I started to realize how damn
impractical it was to page through all month on the ASP.NET Calendar Control to get to the desired month.
When I started developing I thought how nice this build-in calender control was...when I need to fix bugs,
it was making me nuts...At this point the application was running about 7 month live...
great customer, they never told me what a crap this calender overview was.;)
It was not really 'dogfooding', but it helped a lot. And of course always be sure to watch them using your tools...
it's incredible. They find ways to accomplish task which you never (ever) thought of.

Dennis

# Jonathan Cogley said on Tuesday, March 28, 2006 1:11 PM

Dennis,

Yes - it really is amazing the difference between building and using an application. As developers we are always left to deal with the technical complexity but many organizations do not have a dedicated quality assurance person. This means that we have to assume the role of usability expert and quality reviewer which many developer types do not suit. Dogfooding is an easier way to get into those roles as it is a more natural role.

Thanks for posting!