Home > ISV, Security, Software Development > Feeling your users pain (and release notes for Secret Server 1.1)

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

It is awonderful 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

  1. Dennis
    March 28, 2006 at 7: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

  2. Jonathan Cogley
    March 28, 2006 at 5: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!

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: