I don’t need to be in to my client’s office until later this afternoon.  This gives me a chance for TWO mornings of writing in a row.  I intend to take full advantage of that!

When looking at the question of “Does this work?” have you noticed that all of us tend to have a slightly different view of what “work” means? 

OK, so its not just me then.  Good.  I was a little concerned for a while. 

In my case, I look for a variety of measures and models to determine if a piece of software “works” or not.  Under one model it might work perfectly well.  Under another model, it might not work at all.

These can have the same set of “documented requirements” and completely different models around expected behavior.  In a commercial software setting, I try and get the description of what the sales staff have been pushing that this software will do.  (If the sales folks are setting the customer expectations, I like to know what they are saying.)

If this is software that people inside the company are going to be using, I try and get with representatives from the department where this software will be used.  Not just the “product owners” but the people using the software as part of their daily function.  These groups can, and often do, have distinctly different definitions of “it works” for software impacting their departments.

Finally, there is the view of development, individuals and the team.  On software with many points of collaboration and integration, let me make one thing really, particularly clear:

It does not matter if your part “works” (by some definition of “works”) if the entire piece does not “work” (by the definition of someone who matters.)

That goes for functions within the application and the entire application itself.  Resting on “I did my bit.” is not adequate if the people working with the piece of software if that piece of software does not do what it needs to do. 

No matter how well the individual pieces work, if they don’t work together, the software doesn’t work.