Software Development Best Practices Blog

Fail Yet Succeed?

If you build EXACTLY what “they” tell you, you do it in the timeframe they ask for, and at the cost they wanted to pay, is that a successful project? The project is On time On budget Delivers the requested functionality No defects The team is ready for the next project Is it successful? “Yes,” you say. Rightfully so. But what if I tell you that the above project (project A) was followed by another...

  1. Posted on September 16, 2009 12:42:PM by Earl Beede to Practicing Earl
  2. Testing & QA, Technique, project management, humor, context, quality, requirements, Management

Feedback from Stakeholders – A “Done” Criterion

Each of the previous “done” criterion had the need for the individual applying the criterion to make a judgment call as to the “doneness” of the work item under review. This gives it the power necessary to determine “done” in contextual situations. However, if a person only used one of the criterion—Sufficient to Proceed, Appropriate for the Environment, or Sanity Checks—that check alone can not give a good assessment of “done”. Together they have the ability to guide the “done” decision. To confirm...

  1. Posted on December 17, 2008 7:59:AM by Earl Beede to Practicing Earl
  2. Testing & QA, Technique, humor, context, requirements, done, Management

Sanity Checks – A “Done” Criterion

For every work artifact we create there is often a short list of attributes or questions that can help us determine if the artifact is done. This short list reminds us of classic patterns that have risen to become accepted truth and classic mistakes that continue to dog us. This list of questions or attributes is what I call a Sanity Check, a quick look to see if the work artifact done. For example, if I am remolding a kitchen, the question, “Does the stove, sink, and...

  1. Posted on December 5, 2008 12:54:PM by Earl Beede to Practicing Earl
  2. Testing & QA, Technique, humor, context, done, Management

Appropriate for the Environment – A “Done” Criterion

When we create a work artifact on software project, we usually create it with the understanding that somebody else will need to use it. The who, when, and where of that somebody has a huge impact on whether or we can consider our work “done” or not. To be done, we must determine if the work is Appropriate for the Environment in which it will be used. Think of two teams: Team A and Team B. Surprisingly, both are working on the exact same product, using the same...

  1. Posted on October 31, 2008 12:06:PM by Earl Beede to Practicing Earl
  2. context, done, Management

Sufficiently Complete - A "Done" Criterion

A helpful way to think about a software project is to see the project as a series of decisions about what problem or opportunity the software will solve/implement and the solution itself. Theoretically the decisions start out large and granular and get refined and detailed as the project progresses. Code becomes that last place to make decisions before turning it over to the compiler. Of course in reality, software projects are more likely to see almost random decisions made at multiple...

  1. Posted on October 10, 2008 8:27:AM by Earl Beede to Practicing Earl
  2. context, done, Management

Context Matters

So, I was driving along, making a right turn into a driveway like I have done a thousand times before. I did what one always does when making a right turn: I checked carefully for pedestrians and watched the driveway to make sure nobody was coming down it. I then signaled my intentions and proceeded. Unfortunately, this right turn was occurring in England. Did you know that right turns in England cross on-coming traffic before entering a driveway? Well, I and another car added more evidence...

  1. Posted on June 17, 2007 10:21:AM by Earl Beede to Practicing Earl
  2. Methods & Processes, Technique, Agile, humor, problem space, solution space, context, requirements