Mike’s Dump

March 23, 2007

Best Post This Year

Filed under: Links — mikesdump @ 8:43 am

This has to be the best thing (excluding Dilbert of course) I have read all year. I can relate to all ten points and have blogged on some of these topics myself. Well worth the read if you haven’t already.


March 21, 2007


Filed under: Work — mikesdump @ 1:32 pm

The past couple of days I have been in a few conversations around requirement documents. After giving it some thought it was time to do a brain dump.

What Do You Want?
I think what gets lost when more technical people write requirements documentation is what is required. Instead of focusing on the project from a user point of view they are thinking how they would implement the feature and write instructions instead of requirements

Create a table called customer to store customer information. The following fields should be stored . Write an after update trigger to capture any modifications in the customer_history table.

Is the above requirement wrong? No. But, does it really matter from a user point of view what the table is called? Does it have to be a database trigger for history tracking? Instead something simpler could have been written in the requirements document:

All fields on the customer screen (see screen shot) need to be saved. Anytime changes to the customer information are made a copy of the original information should be made so the changes over time can be viewed on the customer history screen (see screen shot).

You don’t have to be technical to communicate what you want an application to do the key is knowing what you want.

Screen Shots
A picture says a thousand words right? Seeing a drop down list beside a field called “salutation” right away would tell the developer that list of salutations is going to have to come from somewhere. This should bring up questions like:

  1. Does this list need to be modified by the user?
  2. Modified by administration staff?
  3. Or never modified?

Seeing this could mean creating supporting screens, tables, or simply hard-coding the values. Only seeing in writing the requirement for a field called salutation could be easily overlooked and created as a text box instead of a drop down.

Test Scenarios
Adding what scenarios are going to be tested to the requirements document will sometimes highlight areas where the requirements may not be clear but also gives the developer the ability to “test like a user” (well, in theory anyways).

Undocumented “Features”/Implied Requirements
No matter how complete the requirements document is there is always potential for miscommunication. I believe there are several features in an application that are just assumed. For example, when a feature is to “save the customer” it is unlikely that would be interrupted as saving that information only as long as the application is open (persisted in memory versus persisted to a file or a database). It would be assumed this information should be available the next time the application is loaded as well.

Other areas that I have seen implied requirements are:

  • Validation � It may not be in the requirements document but if a user types a letter into a number field it shouldn’t crash the application
  • Security � In a multi-user environment users shouldn’t be able to delete data that doesn’t belong to them (assuming user data is private in this scenario)
  • Application Interface Consistency � This often gets overlooked in larger applications until several screens look different because each developer implemented it in their own way.

These particular examples could be covered off by standards documents so requirement documents don’t become bloated.

It Isn’t Written in Stone
The worst thing that could happen from a good requirements document is it is used as a replacement for conversation. A good requirements document is only the starting point for creating working software which is what both developers and users prefer.

March 19, 2007

What the hell happened?

Filed under: Home — mikesdump @ 11:00 am

Maybe it is just me, but when a service that I’m paying for goes down for anymore than a few minutes I would like to know why. If it is a short amount of time it’s curiosity but as the length of the outage increases my attitude switches to “What the hell happened”?

I use WebHost4Life to host my blog and today the SQL Server it attaches to went down. Being a developer I know shit happens but if it wasn’t for a couple of friends letting me know it was down I probably wouldn’t have caught it (thanks Mike & Justice). What should have happened is WebHost4Life should have let me know SQL Server was down, what they were doing about it and when they expect it back up. You know, something that a professional organization would do.

After seeing it down half an hour after I was informed I decided to submit a trouble ticket. A few hours later I receive the following response:

Would you please give it a try on your site now? Please let us know if you have any further enquiries or concerns. Thank you.

After seeing the response I didn’t really care if the site was up or not because there was no explanation to why the service I pay for was unavailable. I did check my site and noticed my last post was missing so I sent the trouble ticket back.

Mike 1:59:37- Has the system been restored from a backup because it appears I am missing some data?

Staff 5:34:57- Yes, there was actually a large scale disk corruption last night that was recovered by our technicians. Unfortunately, we had to revert back to the backup from the day before. I apologize for the inconvenience.

As a customer I would expect things to break from time-to-time. Unless outages are happening all the time I wouldn’t question a service provider’s ability on this point. What affects my confidence is how well the service provider responds to outages including their communication.

Working for a company that provides online services it sure made me think on how well (or not so well) we have responded to these types of situations in the past.

My Most Successful Project this Year

Filed under: Kids — mikesdump @ 10:54 am

The customer had no clue what they wanted but working closely with them, in short iterations, we nailed it! What we ended up with was a hole in the snow with a tunnel large enough for a 7 year old. Good thing the customer was interested in QAing the project themselves because the developer wasn’t capable of testing the final product.

March 17, 2007


Filed under: Home — mikesdump @ 4:19 am

Transactions are pretty cool. They allow a group of changes to be applied as one unit. If anything goes wrong during the process the entire set of changes is rolled back to the initial state. I’ve often thought this would be a useful thing to have on life.

There a lot of decisions I have made in my life that have been questionable. Most of the decisions I can look at now as great learning experiences and have allowed me to grow and get to where I am now. Other decisions I’m still waiting to realize any benefit.

Then there is another group of decisions that you really aren’t going to learn anything from. You either get them right or wrong. They might affect you, people around you or both. It is these decisions that I could use a rollback on.

If anyone develops a rollback feature for life that I can install I obviously have some room in my head because parts of my brain aren’t being used!

Create a free website or blog at WordPress.com.