Subscribe via RSS

Your Software Process Sucks : The Prelude

Filed Under Human Factors, Software Process

Picture this. You are sitting in a job interview with your next potential boss. Being a TDD/Agile/Scrum zealot you proudly declare:

“A strong skill of mine is software process, I really think I could be an asset to your team.”

Should the correct answer of the potential boss be:

  • A. That’s great! We could always use people willing to improve the process.
  • B. What do you have in mind?
  • C. Our waterfall process has worked for 5 years. We will not change it for anything.

Recently, I was blown back when I heard the answer C come out of the mouth of a Sr. Architect. The interviewer could tell that I was sincerely disappointed by this answer and asked if I wished to continue. I agreed out of curiosity of what other nonsense he might say.

Choking on my bottled water was probably not the best show of face, but seriously? You don’t want to improve your process? You don’t want to work faster, smarter, and more efficient? Do you not like money?

Unfortunately, this is a resistance to change seen in a lot of organizations. Why does this occur? How can we fix it? Stay tuned, as the next couple of posts I will be exploring these questions under the series title “Your Software Process Sucks”.

Save Time By Writing Better Bug Reports

Filed Under Quality Controls, Software Process

A few months ago I received the following bug report:

“CS-17: Search broken. Make search work like Google.”

Make search like Google, what the f@!# does that mean?

After an hour man-hunt for the project manager, another hour of conversation was spent discovering the actual problem. Collectively, 3 hours of my time were wasted clarifying a problem report that should have been explicit in the first place.

If time is spent creating and organizing bug reports (i.e. Jira) a minimum level of effort should be taken to making them helpful. This may seem obvious to a developer, but a client or QA will not always know your expectations for a good bug report. It is the responsibility of the developer to communicate (and teach) these expectations.

After receiving the (now a local cult favorite) Google bug report, I politely explained to my trusty QA that I would be much more productive in processing bug fixes if the corresponding reports came in the following fashion:

  • Descriptive Title
  • Priority
  • Screen shots (if available)
  • Stack Trace (if available)
  • Detailed Description
  • Expected Results (Examples)
  • User Role (anonymous, authenticated user, admin)
  • Browser/OS
  • Test Server
  • Build Number

As an example, the report CS-17 was changed to:

CS-17: Search only returns results where all keywords exist and not where any of them exist

Priority:
2

Detailed Description:
If I currently search the website for “blue whales”, I only see results for “blue whales”, and not “blue” or “whales”.

Examples:
“Sea Horses” expected results should be pages seahorses.html, sea.html, and horses.html in that order.

User Role:
Anonymous

Browser:
Firefox and IE6

Server:
(QA Server) http://client.project.preview.codesqueeze.com

Build Number:
1.0.2614.30901 – 3/19/2007 9:25PM

This bug report is much better at telling the story of when, where, and how the search is not working correctly, plus I know some examples to test my fix against. Having the author take the needed 15 minutes to correctly write the bug report collectively saved the company 4 hours.

What do you expect from a good bug report?

How To Write Validators That Demand Attention

Filed Under Code

ASP.NET validators are bad at getting attention. Period.

Users do not want to view validation summaries at the top of a page, only to go visually searching through your form for the invalid fields. Nor do they want to play a rousing game of hide-and-go-seek with little red asterisks (*). This is especially true when your form becomes larger and/or when multiple validation errors occur. The form below is fairly common place:

Normal Validation with ASP.NET

By writing your own custom validators, you can override the EvaluateIsValid and Render methods to add a new dimension of usability. Here are 3 tricks that you can implement in your own custom validators:

1. Modify Control.BackColor

Changing the BackColor property of the invalid control can be a quick and easy way to allow the user to instantly view which fields are invalid. Additionally, this is a way to do validation in situations where screen real estate is limited (i.e. PDA).

BackColor Validation with ASP.NET

The implementation of this is easy: override the EvaluateIsValid method of the validator you are inheriting from (in this case the RequiredFieldValidator), find the control being validated, and set its BackColor property. Control of the color has been accomplished by an added property called InvalidColor and text is added to the control if it is of type IEditableTextControl.

Note: Modification of the invalid control must occur earlier in the ASP.NET Page Life Cycle than the Render method as it may be too late and rendering of the invalid control may have occured.

Sample EvaluateIsValid Code

2. Use Animation

Using an image as a validation marker is generally a bad idea; however, in some circumstances images can work. Compact forms or very clean designs may benefit from a more stream-lined form of pinpointing invalid data. Before using images be sure that the users are able to fully understand what the iconic representation of each image is.

Moving Image Validation using ASP.NET

Implementation of this type of custom validator is slightly different as you will need to override the Render method. This is because dynamic creation and rendering of an Image control needs to occur before the base rendering.

Sample Render Code

3. Be Blatant

When all else fails, throwing messages the size of billboards will always work. To accomplish this, I used some Bubble Tooltip CSS, and put together a validator that displayed absolutely positioned balloon messages.

Bubble Tooltip Validation with ASP.NET

Using the two concepts outlined above, writing this validator is can be done is 3 small steps. First, we need to create the balloon image.

Bubble Balloon

Second, register the CSS in the EvaluateIsValid method.

Registering CSS

Finally, insert the specific HTML in during the Render method.

Rendering bubble HTML code

In order to achieve the absolute positioning you will have to create a style tag on your validator such as the one below.

Sample ASP.NET Validator Code

UPDATE: Check out the ValidatorCallout in the ASP.NET AJAX Control Toolkit. Everything as the above with none of the work!

Feel free to download these validators and modify them for happier validating!

« Older Entries Newer Entries »

Max Pool - © 2025 - {codesqueeze}. Sycorr Banking Solutions