February 25, 2020

McCall's Software Quality Model

  —Employ quality metrics to support developer and user needs throughout the lifecycle.

McCall’s quality model was published in 1977 (see A Framework for the Measurement of Software Quality). It’s significant because its one of the first models to capture user experience and developer perspective.

Another document FACTORS IN SOFTWARE QUALITY complements what’s in the framework with more detail.

McCall’s Software Quality Model provides a nice high-level introduction into the relationships between model components. It doesn’t touch on the quantitative aspects of the model. The model provides a framework for measuring software quality that affect user and development facing properties of the software.

The Model

The model is built upon three product pillars:

  • Transition captures how well the product can be adapted to new environments.
  • Operation captures how well the product fulfills its specification.
  • Revision captures how well the product can be revised or changed.

Each pillar ties represents an activity occuring on a software product throughout its lifetime. These pillers are use to create a collection of quality factors aligned those activities. A quality factor captures behavioral and nonbehavioral requirements.

Product Operation

Operation provides a behavioural representation of the product. Behavior includes quality factors like correctness and efficiency.

Product Transition and Revision

Transition and revision provide a non-behavioral representation of the product. Transition includes quality factors like maintainability and flexibility. Revision includes quality factors like portability.

Quality Factors and Criteria

Quality factors are positively influenced by one or more quality criteria.

A quality criteria is software-directed metric (actual, quantifiable measurements) that relate to the factors.

For example, a quality factor for simplicity impacts reliability. Reliability is measured in terms of the extent a program can be expected to perform its intended function with required precision.

The same criteria can impact a number of factors. For example, portable code may degrade efficiency.

Some factors positively or negatively impact other factors. For example, correctness positively affects reliability but generality might negatively impact efficency.

Employing the Model

A key point in McCall’s paper is that the metrics for quality criteria are measured throughout the development of the product’s software. This is in contrast to testing which only identifies the frequency of error.

Furthermore, the quality measure process must be applied to the requirements and design phases of the product. Quality metrics are predictive in nature and oriented toward the development phases rather than toward the finished system. They are a tool employed to reduce the cost of correction before the final product is delivered.


Keys to measurement success:

  • attributes are predetermined and a consistent method of mesurement must be employed
  • a relationship must be developed between the product and its application
  • such measurements are not absolute

Measures are then a rating for a quality factor. This rating must include a function mapping each quality criteria into the quality factor.

February 2, 2020

Awful Code. Awful Circumstances.

  —With awful circumstances comes a terrible price--to people and the organization.

Sarah Mei has a tweet:

We think awful code is written by awful devs. But in reality its written by reasonable devs in awful circumstances.

A lot of the comments focus on developer ability. My favorite response is the truth table–surely done in jest.

Developer ability is a narrow view of the challenge here. People make mistakes, exercise poor judgement and create less than ideal outcomes. This happens under good circumstances as well.

I think Sarah’s point is that environment and constraints affect code quality. I asked her:

Am I correct that your notion of awful circumstances includes organizational (management, process, etc.) down through to the personal relationships between team members?

She responded:

Yeah. There is a very narrow slice of it that any of us has control over.

A narrow slice of control. I’m hopeful.

It’s important to recognize the socio-political environment and psychological elements.

  • Management support.
  • Team power structure.
  • Personal relationships.
  • Individual stress, burnout, frustration, capability and ability to contribute.

It starts with people. The narrow slice of control revolves around how people treat each other and the choices we make to respond to our challenges. The trick is to maximize the number of good choices we make.

I have hope that awful circumstances can be improved. I believe empowered people can make decisions that improve outcomes. The trick is to listen, act and repeat.

A narrow slice of control might be all you need.

January 27, 2020

Architecture and Design

  —What goodness do you want your architecture to provide?

I’m facing a challenge wherein I need to improve my team’s focus on architecture and design. My perspective on this is that their approach is ad-hoc. Team members complain that decisions are made without discussion. The results are suspect and limiting, or least don’t fit my definition of a successful outcome.

My team uses Scrum and struggles with design. My first experience with Scrum left me with one unanswered question: “Where is design occurring?”. I think the short answer to that question is that it wasn’t occurring in a way that promoted a shared understanding of the goals.

In taking on architecture and design I’ve had to rethink my position on how to approach it. Most of my thinking is around identifying what to focus on and how to communicate it so the team gets a shared understanding of the objective.

The first thing I did was look at the product requirements. There was an implicit notion of an architectural quality objective in many requirements. For example, people would talk about performance or reliability but often just use the word itself as if it’s presence conveyed something important. What was missing was an exploration of what performance or reliability really meant. What was missing was tangible activity around these objectives both in the form of requirements and in design.

I started presenting quality objectives as the “goodness” we wanted from the architecture. It was a cheap sales pitch. No one will sign up for badness. It was a good idea in that it created a focal point for discussion. I could ask questions like “Are we getting the goodness we need?” and even “How can we enhance the goodnes we need?”.

The funny thing is that people responded positively to “goodness” over “quality objectives”. People became engaged on finding and identifying “goodness”.

The most interesting thing about goodness is that it turned out to be a good communication tool for stakeholders. Those people outside of the Scrum and Development teams.

Using “goodness” provided a way forward and to begin a conversation about what it meant to have a reliable or performant product. It provided a way to change the perspective on our requirements elicitation that put architectural quality objectives in the same class as functional requirements.

January 4, 2020

Mythical Man-Month (Lessons for Agile Teams)

  —Yet another look at the Mythical Man-Month.

I’ve discussed this essay in a couple of places:

  • The Mythical Man-Month (Worth Reading Again) renegotiate your schedule, not your deliverable. An optimal schedule uses as many people as there are independent subtasks (and no more).
  • Hatching a Catastrophe discusses how a lack of hustle leads to a lack of urgency around small schedule slippages. The challenge is to create a sense of hustle and urgency in a team when these occur.
  • The Mythical Man-Month (Revisited): discusses how people use this essay to deflect from good work breakdowns. The challenge then is to educate people on the need for deeper analysis.

My reading of these essays is that they provide useful and valuable insights even for an Agile team. And yet, the team and I are challenged by these things.

A team member is interested in discussing these essays. Bravo, I say! I’m hopeful this person will provide insight that the team embraces.

An ideal outcome for a discussion on these essays should include:

  • Recognition that the question of whether you can add more people to a task is reasonable until such time you’ve identified all the substasks. Shutting down discussion on this question prematurely is one way to misuse these essays.
  • Recognition that a slip of a day is a signal and not something to be afraid of. Delivery oscillates–sometimes you pull ahead of the projection; sometimes you lag.

An Agile team should be comfortable using swarming to address the issue of optimal subtasks. A Scrum team is ideally 4-7 people. This number of people doesn’t introduce a communication barrier, since you are all in stand up and it completes in 15 minutes.

An Agile team should be willing to help each other so that day-by-day adjustments can be made to adjust for progress changes. The stand up is an ideal place to discuss whether you are able to help or need help on a task.

December 29, 2019

Unconditional Code

  —Michael Feather's ideas on unconditional code.

I’ve recently come across some comments by Michael Feathers relating to unconditional code. The basic idea is that that code containing lots of if-statements or nested if-statements should be viewed with suspicion. He extends this suspicion to switch-statements and loops.

It’s an incredibly powerful idea.

One concept he discusses to eliminate if-statements in a function is to look at error conditions and consider expanding the domain of the function to eliminate the error condition. I mentioned this to a couple of collegues and both asked what that means. I assume that domain refers to the function inputs (just like the mathematical definition of a function over a domain and range).

If I apply this meaning to a function the is seemingly nonmathematical in nature what can I come up with?

Here’s some Python code from Pandas that creates a Pandas data frame from a CSV file.

pandas.read_csv(file_handle, usecols = [ 'Index', 'Column One' ], index_col = [ 'Index' ], parse_dates = [ 'Index' ])

What’s interesting about this function is that it will accept CSV file containing only the header row (defined by usecols). The data frame created by this read_cvs under these conditions is empty. Nothing unreasonable about this.

If my application uses this function and goes off to compute something it needs to handle the case when no data is present gracefully. If my application just counted rows if data, I could achieve this by producing a count of zero. The point being that zero is as reasonable an answer as one, two or three if this is the number of rows present.

The problem with this example is that it’s not clear I’ve extended the domain of the count function.

If my application computes the average value of a column in this file then things get more interesting. Using the above example, I get a count of 0 rows and my data value is undefined (because it doesn’t exist).

Pandas deals with this very gracefully. Run read_csv on a CSV file containing only the header column and you can use pandas.isna on a column value to determine if the value is unavailable. My average calculation now needs to be aware of this situation and we can check for this situation using a count or pandas.isna. This awareness is likely to come in the form of an if-statement.

This brings me back to the initial question of how to extend the domain of my average calculator in the absence of any column values. In Michael’s example, he introduces the concept of a null object that participates in a computation but essentially does nothing.

In my average calculator, my average function should understand and operate on empty data frames by returning the equivalent of pandas.isna == True for the array. If it does, then the domain of the average function includes the any numeric value and “NA”. My application doesn’t contain an if-statement for this extended domain. It lives somewhere and that’s ok.

The point Michael is making, is that lots of if-statements are generally a bad sign. The total elimination of them is not.

Check out the Anti-If Campaign.