The longer you wait to shovel the worse it gets, besides the additional snow you have to move. The snow may get compacted, or freeze into ice.  So you will end up breaking ice, salting, besides shoveling. The same is true when maintaining a project, and you wait to fix a troublesome section of code. The problems will start to pile up and dependency may be built on top of the code. Then when you actually get to fixing it you have to fix not only the initial problem, but any dependent code.

Sometimes our hands as developers are tied, the budget maybe tight, but we should understand the business case for fixing something earlier, and try to estimate the cost of not fixing it if there is resistance. That being said we should also be cognizant of balance between our need as programmers for quality, and the bare minimum which will provide our customers, internal or external, the value they expect.

“Fix early, fix often” is my philosophy for dealing with bugs. When you delay fixing a problematic section of code, you will pay for it with  interest.  Having a clean code base is even more satisfying then having driveway and walkway clear of snow.

Bookmark It

An example of this would be a QA team is testing a section and they work 4 hours. They spent the 1st hour working and they found 8 bugs, they spend another hour working and only find 4 bugs, after the third hour of testing they found 2 bugs, and in the fourth hour they only find one more bug. We could say that the output diminished each hour they worked.

In the graph below you can see how the number of bugs starts to trail off. This would be an example of how after a certain time the output is decreasing even though more time is spent testing. In this example over 50% of the total bugs found would have been the first hour 80% by the second hour.

Most often the initial QA testing is the most valuable, and then less and less bugs are found the more testing is done. This shapes the way we approach QA, and why many times QA is cut short, because reduction of flaws becomes more and more expensive, especially with larger products. This information also can shape how a testing process is developed, and how deep or shallow we choose to test each section.

Putting this altogether helps us as developers understand that flawless software is very difficult, and expensive to produce, because QA time becomes less and less effective after a certain threshold. The difficult part is figuring out when QA returns are diminished, and is there a point where it starts to drop off drastically? Every project, and every organization are different, and so this could very greatly depending on a number of factors, QA testers ability, software complexity, domain complexity, organizational factors, etc.

The law of diminishing returns as relates to quality and QA ties into the bigger picture of the project triangle (Scope/Quality, Cost, and Time). If we understand how much time it will take to reasonably test our software we can better balance the quality with deadlines and costs. We know that we may be able to shave 20% of a QA testing budget and not cut into the most valuable QA testing time and can more accurately forecast the risk associated with such a decision.

Bookmark It

the degree to which a set of inherent characteristics fulfills requirements — ISO 9000 : 2000

The definition is interesting, because it makes no statements about composition or any other property. The only statement it makes is about the fulfillment of requirements.

Software exists because it fulfills a need. These needs are translated into requirements. Secondly software is expected to have certain qualities by it’s users. These are requirements which are many times unwritten. If software does not fulfill most or all the requirements it will be interpreted as poor quality.

Here are some examples of unwritten requirements:

Bugs should be kept to a minimum.
Software should perform well.
Software should be very usable.

Unwritten requirements are not easy to fulfill, and they are ambiguous and subjective. Clearly defining these requirements and expectations. This process is integral to developing software that fulfills users needs and expectations.

Misunderstanding quality is dangerous, and leads to false beliefs. These beliefs cause developers to ignore parts of the software development picture. The only way to consistently build quality software is to define not only the functional requirements, but also the unwritten requirements and expectations.

Bookmark It

When making changes to a section of code, causes other bugs, sometimes recurring, to pop up. I.E. You fix one bug, and three other bugs pop up after you release.

Have you ever worked on code where troubleshooting bugs was like playing a game whack a mole. I have worked on a few applications that seem to have taken this idea to heart.

If you encounter an application that not very stable, many time your options for dealing with it are limited. You just have to work within the constraints of the system. Previously I have mentioned, defensive development as a technique to cope with difficult system. This is an example of controlling what you can, the new code, and fixes you introduce into the system.

When dealing with difficult systems your best weapon is going to be communication. Make everything as clear as possible. Make your new code readable, understandable, and most importantly comment what you changed, and why you needed to change it. Keep documentation on the system. Document critical, and time consuming tasks. If a process took you a week to update, document it, and it will take the next guy half as long.

The most important technique for dealing with difficult systems is asking questions, and making sure you understand what people are asking. Many times “whack a mole” conditions are caused by mis-communication, and lack of knowledge.

Maintaining difficult systems is a reality for many developers. This is as important, or more important of a development skill as creating new applications. Many time maintenance programming is far more difficult than new development, because you have to work outside of your code “comfort zone”.

Bookmark It

Recursion

If you are using recursion there may be a better way, or I like to say just because it fits into recursive paradigm, it doesn’t mean it HAS to. There are many times I have found myself ending up doing something recursively, and regretting. My word of warning: “It starts with a couple of recursive functions, and then you wake up 3 days later in the middle of New Mexico in playing Russian roulette with Bill Richardson. Recursion has it’s uses, but with it you probably are going to incur a performance cost that may not be worth it.

Nesting Logic

Any time you start nesting logic beyond 1 or 2 levels this should be a warning sign that something could be a miss. This is where debugging is generally going to start getting difficult. If you are having difficulty coding a section, and it involves nesting of logic this a point where you need to step back and get a second opinion on how to do it. I am by no means saying don’t do it, but watch

Really Long Functions

Writing really long functions is generally a sign of two things, either there is a lot of logic to parse through, or you may be doing something poorly. This may also be an indicator that something else outside of your current scope is amiss. This is generally a point to ask questions, and thoughts on how to program a specific section.

Maze Like Program Flow

If you are constantly searching for functions, and logic, and your program looks like a maze this is probably a point where you should take a step back. This means that either there is some really sloppy code, or there is very high level of systematic complexity. If the complexity does not match the task you are trying to achieve this may a point to step back and take a look at the big picture, and possibly get a different perspective on the situation.

There are many other sets of guidelines, many other people have created. This a small list of warning or “yield” signs that I use regularly. This reflects my general bias for trying to make things as simple as possible, and reducing complexity where ever possible.

Bookmark It