Scribd
Upload
37 views

Why Does Software Have Bugs?

Software bugs occur for several reasons: miscommunication of requirements, complexity of software applications, and programming errors. Other causes include changing requirements, time pressures during development, unrealistic estimates that ignore complexity, poorly documented code, and bugs in software development tools. Managing requirements, thoroughly testing applications, and allowing time for maintenance can help reduce bugs, but some level of bugs may be inevitable given software complexity and the human factors involved in development.

Uploaded by

PRINCEBLR
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
37 views

Why Does Software Have Bugs?

Software bugs occur for several reasons: miscommunication of requirements, complexity of software applications, and programming errors. Other causes include changing requirements, time pressures during development, unrealistic estimates that ignore complexity, poorly documented code, and bugs in software development tools. Managing requirements, thoroughly testing applications, and allowing time for maintenance can help reduce bugs, but some level of bugs may be inevitable given software complexity and the human factors involved in development.

Uploaded by

PRINCEBLR
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

Why does Software have bugs?

Miscommunication or no communication - as to specifics of what an


application 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 objectoriented 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.
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.
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'
'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 problem's', 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').
software development tools - visual tools, class libraries, compilers, scripting
tools, etc. often introduce their own bugs or are poorly documented, resulting
in added bugs.

You might also like