What is architecture?

On a regular basis we hear people talk of good and bad architecture, but what is architecture?

Before I describe software architecture, let's see if we can come to an agreement of what architecture is.  What are the components of architecture, and what value does architecture have.

Architecture provides the structural and connective framework required for a system of components to function.  Architecture is specific to a context, good architecture for a software system is different from that of a car or a building.

Architecture in general is not visible, it is present in the system but under other visible design components.  Before a discussion of software architecture, it would be best to describe architecture using physical objects.

Architectural Elements

Architecture involves two elements:

1. Structure
2. connective elements.  

Let's look at these two elements with respect to a building.

Structure for a building involves the foundation and the pieces that provide support to the entire building; it is the skeleton of the building.  If a building has an interesting shape it is because underneath the framework of rebar and concrete support the shape.

Connective elements can be structural, but they provide a way of linking different structural components for the purposes of transporting something.  Connective elements in a building transport air, water, and electricity.

The structural capability of the framework will dictate how high a building can go; generally speaking architecture determines size.  If the building has a framework of rebar and concrete that will support a 10 story structure, it will be difficult to add additional floors over 10 easily. Adding additional floors will require effort expended to reinforce the existing structural strength of the building

If a connective element is missing then adding it will be expensive.  For example, old brick buildings often didn't plan for plumbing or electricity.  If this element is added afterwards, then it will be much more expensive to put in.

If plumbing is added afterwards then you will see the plumbing running outside the walls. This can lead to problems if the building experiences sub-zero weather. 

It is similarly inconvenient to add electricity or air-conditioning to a building which has not had these connective elements designed into the building when it was built.

For comparison purposes, let's look at architecture in a couple of  contexts:

Object	Structural component	Connective elements
Building	Steel frame Concrete Bricks	Plumbing Electrical system HVAC system Elevator Emergency stairwell
Car	Chasis Tires	Drive train Steering column Gas conduits Electrical system HVAC system

Architecture and Visibility

In the two examples above, several things about architecture stand out:

1. Structural components are generally hidden unless they are functional
2. Connective elements are covered up in the final object

So for a building the structural element of the steel frame is invisible hidden under finishing elements. But there are cases where we see concrete or brick walls exposed.  Structural elements are generally not attractive and so we put in extra effort (i.e. cost) to hide the structural elements. Sometimes in the case of concrete or brick walls we will leave them exposed because the visual need to hide these elements are not there, i.e. a warehouse.

Connective elements are almost always hidden.  The sight of electrical wires, plumbing, or HVAC tubes is not aesthetically pleasing and we generally hide these elements.  If we are hiding a connective element, they are cheapest to put in when an object is being created the first time.

Cost of Fixing Hidden Connective Elements

Repairing a hidden connective element is expensive.  For example, fixing plumbing and electrical wires in a house are expensive depending on how hard it is to access the connective element.

Adding a connective element after the fact is much more expensive and much less attractive.  There are brick buildings that were built prior to indoor plumbing and electricity being available.  A good example of these buildings are the residences at Harvard or old brick warehouses that are now office space.  In the case of the Harvard residences the plumbing runs outside the residences and due to the winter weather in Boston, is subject to freezing.  Adding electricity to a brick warehouse involves running metal conduits inside the walls; since they are exposed, they are subject to water accidents.

Visible Structural Elements

In the case of a car the tires are a structural element, but they are exposed to view.  This is why effort goes into making the tires as attractive as possible, i.e. white wall tires, decorative hub caps, etc.

Purpose of Architecture

Once the architecture is set it determines two things:

1. The size of an object
2. The functional capabilities of the object

As previously mentioned, the structural architecture of a building will dictate its maximum size and the connective elements will outline its capabilities.  Connective elements are always about functional capabilities.

The purpose of structural architecture is to partition an object into sub-components that are independent and can be designed separately.  For example, in a building, the structural architecture allows you to subsequently design each of the apartments separately without worrying about how the design of one room affects another.

For a car, the main structural element of the chassis allows you to design the following sub-components separately:

• engine
• doors
• lights
• seats

By allowing sub-components to be designed separately we subdivide a problem (i.e. divide-and-conquer), which reduces the complexity of overall design.  It allows separate teams to work on the sub-components.  Good architecture facilitates strong polymorphism in the sub-components.

In an apartment, each apartment can be designed differently and by different people.  In a car, the engine can be designed by one group of people different from that designing the doors, lights, or other part of the car.

The connective components in each object either: 1) provides a shared service that is accessible to multiple components, or 2) provides a coordination of sub-components to achieve a higher level function.

Electricity, plumbing, and HVAC are all examples of shared services that are available to an entire building.  The usage of electricity in one room does not dictate the usage of electricity in another room, however, aggregate usage of electricity is sized by the architecture.

Elevators for a building and steering columns and the gas system of a car are examples of components that are coordinated across multiple levels of the object.  They provide an overall functionality when all of the sub-components coordinated are functioning.

In general, if one of the sub-components is not functioning then the entire set of coordinating objects will fail to function.  For a car, if any component in the diagram fails then the engine itself will fail.

Summary

In any object composed of multiple sub-objects there is architecture.  Architecture provides two different but related functions that is:

1. Structural components
2. Connective elements

The architecture of an object dictates how large it can be and determines how separately each sub-component can be designed.

This article focused on physical objects, the next article will focus on software architecture.

Project failure is due to bad requirements

Projects can fail for a number of reasons, but at the root of most failures is a failure to gather correct and consistent requirements.  We've all laughed at some variant of the above diagram, but these issues are all because:

• We fail to capture correct and consistent requirements
• We play "broken telephone" when we are communicating requirements

Let's take a concrete example.  Suppose we have an orienteering challenge where you need to go from the start point below to the finish point, this is the actual requirement.  

But, there is a gap between what the actual requirements are and what is actually written down.

Good Requirements

As long as the written requirements don't diverge too much from the actual requirements, you will have time to adjust the requirements during project execution and still get to the finish point.  

So as long as the initial written requirements are in the green zone, you can still complete the project on time because the requirements point you in the correct direction.

Mediocre Requirements

Now suppose one of the following happen:

• You don't have all the core requirements because insufficient people were consulted
• You have conflicting requirements from different sources

When you have less than accurate requirements you will be in trouble.  The initial code and architecture of the project will be created based on the quality of the requirements.  If those requirements are suspect, then there will be rework as code needs to be adjusted as the scope of the project seems to shift.

So now you will find yourself in one of the yellow zones below

Even with the best execution, the project will be challenged.  Deadlines will be missed as you attempt to bring the requirements back to what they need to be.  This is like trying to change a tire on a car and discovering the jack is missing.

It is important to realize that adjusting poor requirements is not Scope Creep.  Fixing incorrect and inconsistent requirements is necessary and it is pointless for a project manager or executive to disallow these changes.  It would be worthwhile for project postmortems if the project manager tracked whether a requirement was missing or inconsistent.

Challenged projects are typically declared as successes, but only after massive compromises, burned out resources, damage to reputations, and loss of revenue.  When all the damage is taken into account, this is hardly a victory.

Bad Requirements

The last situation occurs where you only have vague requirements before you start a project.  This situation happens where the executives need a project done quickly and over-estimate the teams familiarity with the subject domain.

These projects start with requirements in the red zone below.  You don't have a prayer of completing this project and it will turn into a Death March with all of its characteristics (see Death March Calculus).

Making core course corrections to bad requirements are like trying to change a tire on a car when you are going down the highway at 100 mph.  It won't happen.

Conclusion

It is human nature to assume that the sooner you start a project that the sooner you will finish.   That assumption is only correct if you have good requirements to point you in the correct direction.  Good requirements are consistent and correct and include at a minimum the core requirements for the primary users.

Starting a project with mediocre or poor requirements is simply a recipe for project failure.  Mediocre or poor requirements are incomplete and inconsistent.

If you have been part of a project failure then you will discover that despite the other factors that went wrong, requirements failure was at the root of it.

User stories or use cases?

Alistair Cockburn says "A user story is to a use case as a gazelle is to a gazebo".

If you are extremely familiar with both techniques then this makes sense.  If you are not familiar with both then suffice it to say that you can put a gazelle in a gazebo but not vice versa.

A user story is of the form As a <type of user>, I want <some goal> so that <some reason> (see here).  

A use case for withdraw money has many more components to it, and a skeleton of such a use case can be found here.  I develop this skeleton use case in a four part tutorial:

• Part 1: Use case as a dialog
• Part 2: What is an actor?
• Part 3: Adding interface details
• Part 4: Adding application context

The above user story is only a part of the entire use case.  For an ATM, a user story might be As a user, I want to withdraw money so that I can have physical cash.  This user story is only the summary of the withdraw money use case without the details.

User stories come from the Extreme Programming methodology. The assumption was that there will be a high degree of interaction between the developers, and the end customer and that QA will largely be done through test driven development.  It is important to realize that Extreme Programming does not scale.

Once your development team gets large, i.e. you have 3+ agile teams and your code base gets large enough to warrant a formal testing environment, then you will outgrow user stories as your only method of capturing requirements.

You can still use user stories for new modules developed with an end customer to take advantage of the light weight and rapid nature of user stories, but at some point those user stories should transition to use cases.

Unfortunately, there are quite a few ways to build use cases and not all of them are effective.  Alistair Cockburn's method (found here) is an excellent way to capture use cases for more sophisticated systems.  There is no doubt that use cases are heavier weight than user stories, but consider this:

• Use cases can more easily be turned into test cases by QA
• With use cases you more easily prove that you have all the requirements
• Use cases annotated with screens and reports can be used to collaborate with remote off site customers
• Well written use cases can easily be broken up into a sprint back log
• Use cases will work if you are not using Agile development methods
  

So don't forgo the speed and dynamic nature of user stories, just recognize that there are limits to user stories and that you will need to transition to use cases when your project team or application grows.

Ready, Fire, Aim: How most gather requirements

Connecting with your customers and delivering value depends on understanding your customer's requirements and selling the correct product or solution that solves your customer's problems.

Commonly, the requirements gathering process is done hastily or not at all in the rush to get the sale. After all, the faster you can make the sales, the faster the money is in the bank -- correct?

The more that product customization is required, the more it is important understand the customer's actual problem.  Long lead times to build and implement a solution means will not only lead to difficult implementations but also to a more disappointed customer and a loss of future revenue.

If you build software, which has long lead times, it is even more important to make sure that what you are building will satisfy the customer's requirements as changing the final software solution will be nearly impossible and very costly.

Why do we continually misunderstand and sell the wrong solutions and building the wrong software?

Human Nature

Time pressures to make a sale put us under pressure and this stress leads to making quick decisions about whether a product or solution can be sold to a customer.  We listen to the customer but interpret everything he says according to the products and solutions that we have.

Often the customer will use words that seem to match exactly the products we have.  But then after the sale once we have to implement we often find that either we deliver a poor solution to the customer or a solution is infeasible and we must refund the customers money.

However, behind every word that the customer is using there is an implied usage, and understanding that implied usage is where we fail to gather requirements. For example, suppose the customer says I need a car.

Suppose that you sell used cars:

• the customer asked for a car
• you sell cars

Ergo problem solved!

• What if the customer needs an SUV but you don't have any?
• What if the customer really needs a truck?
• What if the customer needs a car with many modifications?
• What if the car the customer needs has never been built?

We hear the word car and we think that we know what the customer means.  The order-taker sales person will spring into action and sell what he thinks the customer needs. Behind the word car is an implied usage and unless you can ferret out the meaning that the customer has in mind, you are unlikely to sell the correct solution.

If you don't understand how the customer will to use your solution then you don't understand the problem.

Comedy of Errors

For products that require customization, the sale will get transferred to professional services that will dig deeper into the customer's requirements.  At this point you discover that the needs of the customer cannot be met.  This leads to sales people putting pressure on professional services and product management to find a solution, after all, losing the sale is not an option.

Sometimes heroic actions by the product management, professional services, and software development teams lead to a successful implementation, but usually not until there has been severe pain at the customer and midnight oil burned in your company.  You can eventually be successful but that customer will never buy from you again.

Consequences

As WIlliam Ralph Inge said, There are no rewards or punishments -- only consequences. The consequence of selling the wrong solution to a customer is:

• Whether you lose the sale or not, the customer loses faith in you
• The sales person is perceived as incompetent in the rest of the organization especially by professional services and software devleopment
• Your cost of sales and implementation is much higher than expected
• Your reputation is damaged

Conclusion

Selling the correct solution to the customer requires that you understand the customer's problem before you sell the solution.

When customization is required, good sales people engage resources that can capture the customer's requirements accurately and assess that you can deliver a solution to the customer.

Slowing down to understand the customer requirements and how you will solve his problems is the key.  By understanding the customer's requirements and producing the correct solutions you become a trusted adviser to the customer.

See also

• Shift Happens, effect of scope shift in a software development project.

Failed? You get what you deserve!

Consider this, few projects fail because of unusual or unforeseen problems.  If you are trying to go so fast that you don't do your due diligence or decide to skip steps then -- "You get what you deserve!".

Projects succeed because they do not rely on force of personality and luck.

Only 3 of 10 software projects succeed (see Understanding Your Chances). Success happens when you implement best practices and avoid worst practices; not just talk about them and convince yourself that you are doing them.

Therefore 7 out of 10 projects fail, even if you redefine 'challenged projects' as political victories; these projects are often severely over time and budget.

It is estimated that between $3 trillion and $6 trillion dollars are wasted every year in IT; by organizations that "don't know, and don't know that they don't know", i.e. what you don't know can definitely hurt you.

What is amazing is that failures do not prompt the incompetent to learn why they failed.  After the post-fail finger-pointing ceremony, people just dust themselves off and rinse and repeat.

There is never enough time to do the project correctly, but there is always enough time to do it again.

Ingredients of a Successful Project

Successful software projects have the following characteristics:

• Effective capital budgeting
• Proper project sizing
• Estimate uncertainty
• A focus on defect removal

Capital Budgeting

Capital budgeting means having business cases for major projects and allocating capital to the most promising projects; a little due diligence prevents bad projects from starting.

For example, RJ Reynolds invested $325 million to develop smokeless cigarettes when they knew in the initial pilot that the cigarette tasted bad and no one would buy them.

Project Sizing

If a project has a good business case, then the next step is to figure out how big the project is.  This requires that you expand  the requirements sufficiently to estimate time and cost.

When it comes to software -- size matters.

Not only does size matter, you need to understand the level of uncertainty (requirements, technical, or skill) tied to your project to understand how much re-work or discovery will be necessary.

• Re-engineering a product with new technologies?  (high technical uncertainty)
• Building a new product with existing technologies? (high requirements uncertainty)
• Building software with a team unfamiliar with the technology? (have high skills uncertainty)

Skipping the time to get estimates is a major cause of project failure

There are still executives that give engineering a few hours or a few days to estimate major projects and wonder why the projects go late or get cancelled.

Estimate Uncertainty

Project methodology needs to take into account expected uncertainty.

Projects with low uncertainty can be handled with a traditional project methodology; these projects can have their work breakdown structures elaborated and dependencies can be worked out ahead of time.

Projects with moderate to high uncertainty will require rework and discovery.  This must be built into the project plan or you need to switch to an Agile methodology.  If you don't then there will be missing tasks on the project plan as well as task duration that is under-estimated.

Project tasks get stuck at 90% complete because the sources of uncertainty are not established a priori

Executing a project with personnel that are not competent with the technologies that you want to use is essentially professional malpractice.  If you must use existing personnel that don't know the technologies you want then you need to build in a large margin for training and rework over the project; these projects will take at least 2x as long as your worst estimate.

Focus on Early Defect Removal

Developer's say: "There is never enough time to write the code".  Statistics say, "There is never enough time to find all the defects" (see The Programmer Productivity Paradox).  To be successful you need to find defects as quickly as possible, especially since:

• If it costs X to find a defect pre-test 
• It costs 10X to find it in QA
• It costs 100X to find it once deployed in the field

You do the math, it costs less to find defects before they get to QA.  You are kidding yourself if you think that it is cost effective to have huge QA departments (see The Cost of Not Doing Quality).

Conclusion

Building software reliably and repeatably is not difficult.  What is difficult is getting organizations to realize that there is a minimum set of processes that must be followed to have a successful project.

Organizations regularly skip one or more steps and wonder projects fail to come together and succeed.

When BA means B∪ll$#!t Artist

BA  means Business Analyst, but what makes for a good BA?  When do you have a good BA and when do you have someone who isn't? Many projects fail at the beginning due to incomplete, inconsistent, and overly verbose analysis that then leads to incorrect project plans and projects heading in the wrong direction.

Business analysis consists of all facets of solving business problems. Business analysis is a role executed by project, product, and engineering managers as well as other people.  However, there are people that do business analysis as their main role and we simply label them as business analysts or product managers.

We shall stick to the term business analyst for simplicity. Business analysts perform a range of tasks including:

• Gathering requirements
• Writing business cases and project charters
• Performing gap analyses to incorporate new products

Are your BAs any good?  

The success of many projects depend on the ability of the BA do correctly identify the problem you are trying to solve.  If your BA is not competent then you are doomed before you start.

Ever suspect that the people responsible for performing business analysis for you are not up for the challenge?  Here are three simple questions; good business analysts will get all three correct and not take longer than 30 seconds.

	Context	Question
#1		Which of these two lines is longer?
#2		What does this sign say?
#3	I have two products whose prices add up to $1.10 and one product is $1 more than the other.	How much is the more expensive product?

The answers are:

1. The lines are the same length
   • Take a ruler if you are not convinced
2. Paris in the the spring
   • Notice that the occurs twice
3. The more expensive product is $1.05
   • If the more expensive one had been $1 then the cheaper one would be $0.10 but then the expensive one would only be $0.90 more expensive than the cheaper one.

These three questions illustrate that the mind can jump to conclusions that are often wrong. The mind can be tricked because it assesses things quickly, i.e. jumps to conclusions.  Only some people have the instinct to double check their results and check for personal bias.

Most BAs are well educated; however, the interesting thing is that studies show that educated people are less able to see their biases and they jump to conclusions more readily than other people.¹ Even worse, well educated people have less of a tendency to check their conclusions than other people.

A good business analyst realizes that during analysis there will be situations where the mind will jump to conclusions.  Many business analysts are asked to resolve conflicting requirements, recognize missing requirements, and deal with biases coming from many different sources.  Unless you have the reflex of checking facts for consistency and eliminating bias then you won't make a good business analyst.

So what is the quality of your BAs?

Other articles

• No Business Case == Project Failure
• No Experience Required

Bibliography

¹ West, Richard F. and Meserve, Russel J. Cognitive Sophistication does not Attenuate the Bias Blind Spot. Journal of Personality and Social Psychology.

No Business Case == Project Failure

A business case comes between a bright idea for a software project and the creation of the software project. 

• To - idea to have a project is born
• Tcheck - formal or informal business case
• Tstart - project is initiated
• Tend - project finishes successfully or is abandoned

Not all ideas for software projects make sense.  In the yellow zone above, between idea and project being initiated, some due diligence on the project idea should occur.  This is where you do the business case, even if only informally on the back of a napkin.

The business case is where you pause and and estimate  whether the project is worth it, i.e. will this project leave you better off than if you did not do it. For those who want precise definitions the project should be NPV +ve.  In layman's terms, the project should leave the organization better off on it's bottom line or at least improve skill levels so that other projects are better off.

Projects that do not improve skills or the bottom line are a failure.

Out of 10 software projects (see Understanding your chances):

• 3 are successful
• 4 are challenged, i.e. over cost, over budget, or deliver much less functionality
• 3 will fail, i.e. abandoned

This means that the base rate of success for any software project is only 3 out of 10. Yet executives routinely execute projects assuming that they can not fail, even though the project team may know that the project will be a failure from day 1.

Business cases give executives a chance to stop dubious projects before they start. (see Stupid is as Stupid Does) Understanding how formal the business case needs to be comes down to uncertainty. There are three key uncertainties with every project:

• Requirements uncertainty
• Technical uncertainty
• Skills uncertainty

When there is a moderate amount of uncertainty in any of these three areas then a formal business case with cash flows and risks needs to be prepared.

Requirements Uncertainty

Requirements uncertainty is what leads to scope shift (scope creep).

The probability of a project failing is proportional to the number of unknown requirements when the project starts (see Shift Happens).

Requirements uncertainty is only low for two particular projects:

1. re-engineering a project where the requirements do not change
2. the next minor version of a software project. 

For all other software projects the requirements uncertainty is moderate and a formal business case should be prepared.

Projects new to you have high requirements uncertainty.

Technical Uncertainty

Technical uncertainty exists when it is not clear that all requirements can be implemented using the selected technologies at the level of performance required for the project. Technical uncertainty is only low when you have a strong understanding of the requirements and the implementation technology.  Uncertainty and risk are two different animals (see  Uncertainty Trumps Risk in Software Development)

When there is only a moderate understanding of the requirements or the implementation technology then you will encounter the following problems:

• Requirements that get clarified late in the project that the implementation technology will not support
• Requirements that can not be implemented once you improve your understanding of the implementation technology

Therefore technical uncertainty is high when you are doing a project for the first time and requirement uncertainty is high.  Technical uncertainty is high when you are using new technologies, i.e. shifting from Java to .NET or changing GUI technology.

Projects with new technologies have moderate to high uncertainty.

Skills Uncertainty

Skills uncertainty comes from using resources that are unfamiliar with the requirements or the implementation technology.  Skills uncertainty is a knowledge problem.

Skills uncertainty is only low when the resources understand the current requirements and implementation technology.

Resources unfamiliar with the requirements will often implement requirements in a suboptimal way when requirements are not well written.  This will involve rework; the worse the requirements are understood the more rework will be necessary.

Resources unfamiliar with the implementation technology will make mistakes choosing implementation methods due to lack of familiarity with the philosophies of the implementation libraries.  Often after a project is complete, resources will understood that different implementation tactics should have been used.

Formal or Informal Business Cases?

An informal business case is possible only if the requirements, technical, and skills uncertainty is low.  This only happens in a few situations:

• Replacing a system where the requirements will be the same and the implementation technology is well understood by the team
• The next minor version of a software system

Every other project requires a formal business case that will quantify what kind of uncertainty and what degree of uncertainty exists in the project.  At a minimum project managers facing moderate to high uncertainty should be motivated to push for a business case (see Stupid is as Stupid Does).

Here is a list of projects that tend to be accepted without any kind of real business case that quantifies the uncertainties:

• Change of implementation technology
  • Moving to object-oriented technology if you don't use it
  • Moving from .NET to Java or vice versa
• Software projects by non-software companies
• Using generalists to implement technical solutions
• Replacing systems with resources unfamiliar with the requirements
  • Often happens with outsourcing

Projects with moderate to high risks and no business case are doomed to fail.

Related articles

• No Experience Necessary!
  • Surprisingly there is no correlation between years of experience and productivity.  This has been verified over 40 years.
• Stop it! No, Really Stop It!
  • 5 worst practices that software organizations commonly practice that they need to stop right away

Who should set defect priority?

Surprisingly, defect priority should not be set by QA.  QA are generally the owners of the defect tracking system and control it, but this is one attribute that they should not control.  The defect tracker is a shared resource between QA, engineering, engineering management, and product mangement and is a coordinating mechanism for all these parties.

Commonly people mix up priority and severity, for example, there may be a severe defect that causes the software either not to install or to cease functioning.

It is common for new releases to have various installation problems when they first get to QA. This blocks QA, so they mark the defects with a high severity and high priority.  This issue has a high severity and needs to be addressed right away, but remember bug tracking systems are append only -- once this defect gets into the system, it will never get out.  This kind of issue should be escalated to the engineers and engineering management because it makes little sense to clog the defect tracking system with it.

Now there may be intermittent issues that cause the software to fail and you may assume that this defect would be high priority, but if it occurs very rarely and would cost too much to fix then this defect may be a low priority.  Once again the priority of an intermittent severe issue can not be determined by QA.

Similarly, there may be many cosmetic or minor defects where fixing them might make a huge difference in the user experience and reduce support calls.  Even though these defects are minor, they may be easy to fix and save you serious money.  Once again, this can not be decided by QA.

Therefore, QA should reserve the right to set the initial severity, and may have an internal field for QA priority, but the priority of a defect should be determined by a product manager (PM) who has a more complete understanding of the overall context of the product.  The priority of a defect is a business issue, not an engineering or QA issue.

Ideally, the product manger will set the priority of a defect during a defect triage session where representatives from engineering, engineering management, and QA are present. As you go through each new defect each person can present their logic for what the priority should be.  The PM should then set the priority defect and assign the release it should be fixed in (i.e. this release, minor release, major release, won't fix).  Ideally there are extra fields in the defect record for both QA and development to put their priority beliefs.

It is important that the main status field of a defect not include any of the following or your defect tracker will go to hell (i.e. this information should be in other fields):

• Priority
• Severity
• Fix version

It is very hard to generate meaningful reports when these attributes creep into the defect status.  This has happened if you have a multi-page training manual for entering defects into the system.  Some of the statuses that make sense initially but turn the defect system into a nightmare are:

• FAD (functions as designed)
• WontFix
• NextVersion
• CantReproduce

Of course, if you don't have regular bug triage sessions with all the parties mentioned above then you are probably sand-bagged in fire-fighting.

---

Other related articles:

• It's not a bug, it's...
  • When does a bug become a bug?  Who decides that it is a bug?
• Bug Tracker Hell and How to Get Out!
  • Get attributes that do not affect status out of the main defect status