Internal Software Quality

Note from a WikiGnome: This page is a combination of several pages which once constituted a WalledGarden in 2004. As it turns out, CorrectInsteadOfCriticize is the only page in the garden that was incorporated into the rest of wiki.

This is a collaboration on InternalSoftwareQuality initiated by JohnCarter.

Its direct intent is to be printed and given out as notes as part of an internal seminar series at a largish company doing software development in embedded, desktop and large system environments.

But why limit it to that? Please CorrectInsteadOfCriticize, feel free to add delete, mangle fold and spindle as your experience shows fit.

Indirect intentions are...

This collaboration is a symbiotic part of WardCunningham's Pattern wiki showing how, in a most pragmatic manner, the computer industry can move from BigBallOfMud implementations to naturally occurring patterns.

Internal Software Quality are those qualities of software that are visible from global perspective of all the sourcecode in a product.

As such is merely an aspect of, and indeed, is not even the most important aspect of total SoftwareQuality?.

Internal Software Quality is _not_ about...

Rather, this internal quality will emerge from naturally recurring patterns... -- OmCandea

Internal Software Quality is that which _makes_ Software...

So "Internal Software Quality" is concerned with making software "more reliable" without addressing requirements issues, "Number of defects," "Fitness for use," or "User interface design." This, indeed, is a challenging task!

-- JohnCarter

Internal Software Quality is:

InternalSoftwareQuality are those qualities of software that are visible from global perspective of all the source code in a product.

There are two important notions in that sentence...

As with all qualities, they are neutral and can only be enumerated. It requires something external to evaluate them as Good or Evil.

The conclusion is that, within this discussion, Internal Software Quality is only an enumeration of characteristics. It is not concerned with any evaluation of goodness regarding those characteristics, either singly or as an aggregate.

For example, I have a wee scriptie that eats all the files in large C projects. Having done so it concludes that it is a quite common event in large C projects that functions are declared in more than one header!

This quality can only be ascertained from a global view of source code.

We have to add the desires to maintain, understand and reuse code to evaluate quality of "functions declared in multiple headers" as a Bad Thing!

Internal Software Quality is not:

Let's get it straight up front.

There are more important things than InternalSoftwareQuality.

If you build the wrong product, or build it too late, it's totally unusable or you simply don't deliver. You're dead. You can have the greatest InternalSoftwareQuality in the world, but you're still dead.

If you have flocks of defects, your customers will hate you, but as long as you have flocks of features they want they will still buy your product. Just ask Microsoft. (At least until they have a viable alternative.)

But that stuff is in the domain of requirements analysis, project management, project scheduling and quality assurance. Assuming someone in your company is doing all that and you are Joe Coder doing your stuff, how do you write code that is 'Good'?

If you write Good code, the SoftwareAssurance?, your testers, your "verification and validation" team won't send back endless bug reports.

Conversely I have seen decades old code that was Bad, but had been maintained, used, bug fixed, and fixed, and fixed, and fixed, until the defect count was astonishingly low. Just don't try to add any new features though....

If you write Good code, it will implement the requirements correctly, (God help you if the requirements analyst got it wrong).

If you write Good code, it will be delivered, but the "When" of Good code is orthogonal to the "Now" of project schedules. There has been lots of Good code in canceled projects, and it takes time to make it Good.

There is lots of Good, low defect code that implements all requirements (which are correct). But someone has tacked a totally unusable interface on to it, so you really wouldn't know it was Good. You haven't managed to get it to run yet.

You can copy, letter perfect, every pattern in the GangOfFour's DesignPatternsBook, but unless they are there, at the balance point of the constraining forces, your code will not be Good.

In particular, I assert that a product that has been better tested and bugfixed may have fewer bugs, but lower InternalSoftwareQuality. Why? Because the endless stream of small fixes, has compromised the design integrity. What was originally clean, uncluttered code has become a tangle of corner cases, kludges and extensions!

John, you're attacking XP assumptions in an XP-environment:-) -- OmCandea

I have four variables to play with, scope, time, resources, quality.

So to make these collaborative notes Good(high quality) for Joe Coder, and to do it within the time I have, and the attention span of Joe Coder, well, I will just have to limit the scope to what Internal Software Quality is...

Summary of above. Internal Software Quality is not concerned with:

Internal Software Quality - Why we don't get it:

Perhaps my experience is unique, but I don't think so.

The constraints on a manager are on his FourVariables. Scope, Quality, Time, Resources.

Usually the only measure of Quality that bites him is number of defects. It's often the only measure he sees.

So what does he do all day? Push hard on the Scope, (more features, right features, high priority features first, argue the feature list with marketing.)

Push hard on the Quality, (FunctionalTest, HallwayTest?, UsabilityTesting, defect tracking, assigning defects to developers, closing issues, opening issues)

Push hard on Time. (Manage the schedule, manage the critical path, create GanntCharts?, ProjectPlans?, encourage the staff, remove blockers and time wasters, juggle priorities, schedule tasks.)

Push hard on Resources. (Hire the right people, train the people, equip the staff, handle the PeopleWare, compete with other managers for more resources, manage the resource profile, hire contractors, compile the budget, control the expenditure.)

All Good stuff.

But sadly, what, besides InternalSoftwareQuality, will

Therefore, these questions should be answered by a methodology or a process - OK, but XP-ists require (with quite good reasons) this methodology/process/best practice to be embedded directly in time, resources, requirements and so on. You seem to think differently here. How else would you make it tangible? -- OmCandea

What in the daily round of managing has the manager least visibility of? InternalSoftwareQuality

The computer industry has a problem.

Internal Software Quality - Separation of concerns:

Here is some truly evil code... 

 const char * processText( dbHandle_t db)
 {
      // Get the text from field A of table B the database. About 2 lines of code
      // process the text about 40 lines of code.
      return processedText;
 }
That seems pretty innocuous doesn't it? Innocent, so why do I hate it so much?

Because you cannot test 95% of the code without having ...

Now if that text was trivially refactored into... 

 const char * processText( dbHandle_t db)
 {
      // Get the text from field A of table B the database. About 2 lines.
      return processTextString( inputString);
 }


 const char * processTextString( const char * inputString)
 {
      // process the text about 40 lines of code.
      return processedText;
 }
Now you can trivially exercise, with far greater thoroughness, the majority of the code without the complexity of the database.

Replace database with "hardware", "equipment rack", "main system", "tiny dumb embedded target", according to taste and environment.

Internal Software Quality - Design for testing:

Imagine you have an unimaginably vast and complex box in front of you.

In the side of the box you have two small holes that you can just fit you hands through, and a small dirty window through which you can peer.

Your task is move a ball into every corner of this box.

You are a SoftwareTester.

You don't believe me? What is the size of the StateSpace of a smallish embedded system. Lets say one with 2 Megabytes of memory. It is 2 to the power of 2000000. As I said, it is vast.

Every variable can be considered a dimension of this space. Thus the dimensionality is very, very high. (About 256000 dimensional space)

Every variable is constrained. Sometimes simply (eg. must be greater than zero), and sometimes in more complex fashions (e.g. x must be < y)

The shape of this box is very complex.

You can only use the few widgets and input fields on the UserInterface to manipulate the state of the software system.

You are doomed. Let's face it, you haven't a whelks chance in a supernova.

Solution, break the box up into smaller boxes. Preferable orthogonal boxes. (For example, a C++ system has many instances of the string class. You don't have to test every instance in the system, merely the string class by it self.)

Except you can't. You have a BigBallOfMud.

It doesn't break into smaller chunks.

Rule 2 of SoftwareArchitecture for InternalSoftwareQuality.

Testability is an external characteristic not visible in the source code. Therefore it is not part of InternalSoftwareQuality.

Unless the tests themselves are part of the software, as many people advocate. Then the testability is validated (or not) by the comprehensiveness, clarity and simplicity (or lack thereof) of the tests.

"Failure to meet requirements," "Number of defects," and "Fitness for use" are not concerns with InternalSoftwareQuality as stated on that page therefore testing is not part of Internal Software Quality.

Rule 3 of SoftwareArchitecture for InternalSoftwareQuality.

The approach of "Write the tests first" is not a characteristic visible in the source code. Therefore it is not part of InternalSoftwareQuality.

See TestFirst.

Summary

InternalSoftwareQuality is the aspect of development that managers have least

See also: IsYourCodeThatImportant and its link to Quality pages

This whole thing is a Work In Progress. Too big to create in one sitting. (I have a life too.) I need to get the notion of what I'm doing down first. (Creating a collaborative course, and get it clear in my mind what I am talking about.) Sorry that it was so vague to start with, but it is solidifying, especially thanks to the input of others.

My hope is that everyone visiting this wiki and my students will get stuck in and make this thing happen. I will continue relying on the principle that a wiki is so interesting because it invites surprising new ideas and uses, an this course is a surprising new idea and usage. What I hope to achieve by placing the course on the wiki is surprising new inputs, insights and usages. Wikiness is about giving up control and letting a certain WildMagic? in.

-- JohnCarter

Although I recognize the authority of the initial author to determine the direction of the discussion, I question the premise that there is an "internal quality" that is separable and independent of quality as a whole. For additional discussion of this view, please refer to the writings of Dr WilliamEdwardsDeming concerning systems and suboptimization through the creation of subsystems.

So you have never looked at a piece of code and said, "This is a load of crap!"? Purely on the basis of the code in front of you and not in consideration of the system as a whole?

It is definitely possible to find aspects of quality separable from the whole. However, as I discuss in InternalSoftwareQuality, I agree with you that all aspects of quality must be considered to create a final High Quality product.

The "whole" these days is generally managed to the Nth degree, but the InternalSoftwareQuality is below the radar of most managers. -- JohnCarter

I can have 10 different developers look at a piece of code and get 10 different opinions on the code. The problem is actually the opposite of what is stated above. There is far too little focus on software as a whole and far too much focus on isolated internals.

In software development, as is the case in many other areas as well, multiple possible solutions exist. Proponents of each solution will argue that each of their solutions has the highest internal software quality, but in the end the differences will be invisible to anyone outside of the development effort itself.

There is simply no way to evaluate "internal software quality" as an isolated concept. The result is merely an argument over personal preferences (which abound on wiki). There is far too much "everyone should do it my way" masquerading as "internal software quality."

I personally feel that the whole idea of being able to control Internal Software Quality is moot. The only way to control this, is for development managers to write the damn code themselves. The problem is in the art, much as one would hire an artist to paint a picture, then try to tell the artist that he implemented his artistic gift incorrectly. If your painting is so big and complicated that you need many artists to work on it, then be prepared to have many different talents applied to produce it, but don't expect them to be able to pool their talents into one "perfect" talent. If you have the damn gift to write that much code yourself, then use it. If not, then keep your nose out of what you can not do. End of story.

The discussion seems to confuse "software quality" with "software qualities" or software characteristics. Software Quality is a subjective evaluation of all of the underlying Software Qualities (Characteristics).

See InternalAndExternalQuality

CategoryQuality

EditText of this page (last edited April 12, 2006) or FindPage with title or text search