should or shouldn't do (the application's requirements).
· Software complexity - the complexity of current software applications can be difficult
to comprehend for anyone without experience in modern-day software development.
Windows-type interfaces, client-server and distributed applications, data
communications, enormous relational databases, and sheer size of applications have
all contributed to the exponential growth in software/system complexity. And the use
of object-oriented techniques can complicate instead of simplify a project unless it is
well engineered.
to comprehend for anyone without experience in modern-day software development.
Windows-type interfaces, client-server and distributed applications, data
communications, enormous relational databases, and sheer size of applications have
all contributed to the exponential growth in software/system complexity. And the use
of object-oriented techniques can complicate instead of simplify a project unless it is
well engineered.
· Programming errors - programmers, like anyone else, can make mistakes.
· Changing requirements - the customer may not understand the effects of changes, or
may understand and request them anyway - redesign, rescheduling of engineers,
effects on other projects, work already completed that may have to be redone or
thrown out, hardware requirements that may be affected, etc. If there are many minor
changes or any major changes, known and unknown dependencies among parts of the
project are likely to interact and cause problems, and the complexity of keeping track
of changes may result in errors. Enthusiasm of engineering staff may be affected. In
some fast-changing business environments, continuously modified requirements may
be a fact of life. In this case, management must understand the resulting risks, and QA
and test engineers must adapt and plan for continuous extensive testing to keep the
inevitable bugs from running out of control
may understand and request them anyway - redesign, rescheduling of engineers,
effects on other projects, work already completed that may have to be redone or
thrown out, hardware requirements that may be affected, etc. If there are many minor
changes or any major changes, known and unknown dependencies among parts of the
project are likely to interact and cause problems, and the complexity of keeping track
of changes may result in errors. Enthusiasm of engineering staff may be affected. In
some fast-changing business environments, continuously modified requirements may
be a fact of life. In this case, management must understand the resulting risks, and QA
and test engineers must adapt and plan for continuous extensive testing to keep the
inevitable bugs from running out of control
· Time pressures - scheduling of software projects is difficult at best, often requiring a
lot of guesswork. When deadlines loom and the crunch comes, mistakes will be made.
lot of guesswork. When deadlines loom and the crunch comes, mistakes will be made.
· Egos - people prefer to say things like: 'no problem', 'piece of cake', 'I can whip that
out in a few hours' 'it should be easy to update that old code'
Instead of: 'that adds a lot of complexity and we could end up making a lot of
mistakes' or ‘we have no idea if we can do that; we'll wing it', 'I can't estimate how
long it will take, until I take a close look at it', 'we can't figure out what that old
spaghetti code did in the first place'
If there are too many unrealistic 'no problems', the result is bugs.
out in a few hours' 'it should be easy to update that old code'
Instead of: 'that adds a lot of complexity and we could end up making a lot of
mistakes' or ‘we have no idea if we can do that; we'll wing it', 'I can't estimate how
long it will take, until I take a close look at it', 'we can't figure out what that old
spaghetti code did in the first place'
If there are too many unrealistic 'no problems', the result is bugs.
· Poorly documented code - it's tough to maintain and modify code that is badly written
or poorly documented; the result is bugs. In many organizations management
provides no incentive for programmers to document their code or write clear,
understandable code. In fact, it's usually the opposite: they get points mostly for
quickly turning out code, and there's job security if nobody else can understand it ('if
it was hard to write, it should be hard to read')
or poorly documented; the result is bugs. In many organizations management
provides no incentive for programmers to document their code or write clear,
understandable code. In fact, it's usually the opposite: they get points mostly for
quickly turning out code, and there's job security if nobody else can understand it ('if
it was hard to write, it should be hard to read')
