Why is fixing runtime bugs expensive?  
Author Message
Karim Hemani





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

I am a novice C# programmer. In the title “Learning C#,” the author states that it is much more expensive to fix a bug at runtime than at design time or compile time. I am wondering if it would indeed be as expensive as he says if the application goes through an SQA cycle before it is deployed. Whether you catch it at design or compile time, or rather at runtime, why would there be more or less cost involved Please shed some light on this.



Visual C#1  
 
 
Andreas Johansson





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

I am not sure what is meant with runtime vs. design time. I will assume it means deployed app vs a app still in development.

When you design an application you only need to take the requirements into consideration. This makes it easy and cheap to change functionality as nobody is using it. You only need to update the code after a new design.

Once you have deployed an application any changes you need to make must take all users of the application into consideration. If a user will not be able to do something they was able to do before it will be a breaking change and users of the product probably will complain. If it is a non breaking change not everyone will update and buggy code might exist among customers.

Besides the time is takes to design and develop a new working solution you also need to consider what it does to your customers. They do not really care why you update, if they are affected by it as they have to update their installations and anything depending on it.

As an example, if Windows all of a sudden will not allow you

In a simple rule, the earlier you catch a bug the lower cost it has. This is because less people depend on it and it means less time to spend deploying/supporting a fix.



 
 
Peter N Roth





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

It’s not just fixing; it’s detecting that there is a bug, finding it, designing a “fix”, implementing and testing the fix, promulgating the new code. It’s the complete development cycle in miniature, for maybe a few lines of code.



 
 
John230873





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

The other thing is that if you find the bug at run time and try to repair it at this stage there are normally a lot of other refreneces to the code and these will normally need to be checked and repaired expscially if it is OO. If you catch these problems during the design you can save alot of time.


 
 
TAG





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

This is a myth.

It's not defined who will cover those extra costs of fixing bug so late.

If this software is for sale - then it's possible for software developer/team/company to rip benefits by releasing new version of software or charging per hour to implement fix or selling support plan subscriptions etc...

If this software is for internal company use - then it's simply moving spending from one part of company to another (like reducing large and useless adverti****ts budget and increase headcount of internal development team).

Remember - something that is cost for someone - is profit for somebody else. Every new software product attempt to reduce number of people needed to do business or costs of using them (by trying to automate things instead of doing them manually), every bug in software product increase demand for software developers.

Your major goal during development must be to make customer happy - nothing else. There is no way to create bug-free and super-customizable software product. There are always will be bugs in your code, bug in libraries you use, bugs in hardware you use, improvement requests, requests for changes in functionality, human mistakes etc... The less you will think about all this - the happier your life will be.

P.S> Example - needs for fixing bugs in sofware released by Microsoft created WindowsUpdate - as result a lot of telcos got extra money from Microsoft users for Internet access. Is this good or bad There is no definite answer.


 
 
Andreas Johansson





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

If you make a software that are in wide use and it turns out there is a design flaw that enable hackers to take over any computer that has it installed there will be large costs in cleaning up systems. This costs is carried by the users of the software. That is money that could be spent on revenue generating activities instead like improving the IT infrastructure.

For the software maker there will be costs to identify the issue, re-design the feature that is flawed and besides the embarrasment there probably will be loss of sales.

Software should not and does not need to contain bugs. It is not impossible to make bug-free software, it just costs more money as you need to spend more time to design, develop and test it.

Bad buggy software is bad for everyone except hackers and similar that abuse it.



 
 
TAG





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

design flaw that enable hackers to take over any computer

Your view is single-sided. This is good for IT jobs, anti-virus (IMHO large hoax) and firewall industry.

As well security risks of using outdated software push companies to buy new versions.

New hardware security features(like NX bit in processor) drive hardware sales.

BTW, the fact that there is no good and widely adopted solution for computer software backup, restore and maintanance mean that costs are not so high to increase demand for it.

P.S> Even NASA software has bugs - but you have no NASA budget.


 
 
Andreas Johansson





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

My point is that it is better to spend the time to be productive and innovative than fixing flaws from earlier. I see it from the view of the software maker, it is not a bad thing to create good software.

I want to buy new versions of software because they offer more features, not because the previous version is so crappy or insecure that I can not use it.

Bugs can be very expensive.
http://en.wikipedia.org/wiki/Ariane_5_Flight_501

Spending more time designing, developing, testing, auditing can save a lot of money, not only for rocket engineers but for any software developer.



 
 
Nimrand





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

 

Remember - something that is cost for someone - is profit for somebody else.  Every new software product attempt to reduce number of people needed to do business or costs of using them (by trying to automate things instead of doing them manually), every bug in software product increase demand for software developers.

Your logic here is severly flawed.  Yes, people profit from bad things that happen, even software bugs.  Divorce lawyers profit from divorces, builders profit from hurricane damage, etc.  That doesn't mean we shouldn't avoid such things just because it creates demand for a product or service.  The world would be much better off if builders were building new houses instead of rebuilding damaged/destroyed ones, and if programmers were busy making new and better software instead of fixing all the bugs in the old one.

The bug is a "cost" in the sense that the developer could produce the same level quality software with much less time/money if the bug is caught early in the process.  There will always be bugs that aren't caught of course, but its best if one at least tries to minimize them.


 
 
Mario Cossi





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

Karim,
from my understanding of the statement you quote, it has nothing to do with deployed software vs one that is still in development. It has to do with errors caught by the compiler vs errors you find while testing your app, and is usually a way to endorse the strong typedness.

A compile time error is "less expensive" to fix as the compiler will spot it for you and it will be reported every time you issue a compilation until you have properly fixed it.

At run time, the error you notice might only be the effect of a long chain of events, or it might occurr only under certain conditions. You will then need to understand what are these conditions and/or retrace the steps until you find the bug; this will take longer and hence will be "more expensive".

Just to make a simple example: consider a program that uses an ArrayList to store some strings. One of our methods contains a bug that will cause an int to be added to the ArrayList instead of a string. We will only notice the error when we attempt, maybe much later, to extract that object from the ArrayList and cast it to a string. We will have to find when and where the offending object was added to the collection, and potentially under which conditions this happens.

Had we used a List<string> instead of an ArrayList, the compiler would have failed to compile the line where we try to add an int to a list of strings. The advantage should be evident.

I hope this helps
--mc


 
 
Nimrand





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

This is true, it really isn't supposed to have anything to do with deployment. Although it is more than just the difference between compile time and runtime errors. Some bugs are simple coding typos, whereas others are flaws in the design itself. If a flaw in the design is not caught and makes it into the code that is produced from the design, then it will be harder to change because the entire code base is written around the design, which, as it turns out, is not completely correct. Fixing the bug may require changes in code in many places of the system, whereas it would have been much easier to fix the bug if it had been fixed in the design before it was coded. An even worse scenario arises if the requirements are wrong, and you have to go back and change a significant component of the system after it has been designed and coded. So, the argument is that a bug can originate from any phase of development, and the more phases it passes through un-detected, the more time it will take to change. Of course, you can never detect all bugs, and you have to decide how important it is to catch a bug in order to decide how much effort to put into it. Air traffic controller software require virtually no bugs, for instance, but most software can get by with many bugs as long as they don't destroy data and don't happen frequently.
 
 
NeverGone





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

Just Like Michael Howard Who is the author of book named Programming Secure Code saying :"You don not know things which you don not know",meaning in the cycle of software always exsits unknown include the bugs,but if you ignore it especially it is negligible ,you will spend more money on mending.

 
 
TAG





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

...developer could produce the same level quality software with much less time/money if...

This assumption is wrong. Same developer with same tool used at initial step of development process will create same result (same bugs).

The only difference can be if developer has several different tools and has freedom to allocate time in different ways for them.

Entire design first vs. code first discussion is about selecting how tools will be used.

If you will use UML design to create some pretty picture, word-processor to write specification, phone or video conference hardware to collaborate with customer, automated verification and review tool (like current managed code compiler instead of old assembler one or punch cards), snippet library or electronic documentation with fast search, automated testing suites etc...

Something that is common between all of those tools - they don't work well then you change your design or requirements. This lead to statement about bug fixing high costs.

Software industry is simply not able to give us correct tools or we are not ready yet to pay for them.



 
 
rauhanlinnake





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

"Remember - something that is cost for someone - is profit for somebody else. Every new software product attempt to reduce number of people needed to do business or costs of using them (by trying to automate things instead of doing them manually), every bug in software product increase demand for software developers."

The bug fixing isn't a profit for anyone. The fixes consume lots of resources, time and money. The company that needs to fix the bugs, could use that time to develop the software product instead of fixing it. Consumers does appriciate new features much more than those darn security bugs finally fixed (they really love if there is no security bugs at all to fix). In the mentioned book Writing Secure Code, Howard estimated that certain bugs in a released software product that need fixing, can cost for the company about 100,000 dollars. That gains no profit, since the product is already shipped, and customers are unsatisfied.

For some reason, people think that software vendors leave bugs in their products (Windows ****) to make more money, but those bugs can cost the companies huge amounts of money. Everything is about the customer trust and satisfaction. And developers sure don't like fixing bugs over and over again, they need fresh problems to solve.

 
 
Nimrand





PostPosted: Visual C# General, Why is fixing runtime bugs expensive? Top

I think you're missing the point, TAG.

Lets say there is a logical flaw in the design that would cause the resulting program to behave incorrectly in some cases.  Lets say that, in order to fix this error, it would require that we change a number 10 functions across 5 classes (by adding new parameters/logic, etc).

Scenario A: The logical error is discovered in design.  The problem is analyzed, and the UML diagram is updated to reflect the needed changes.

Scenario B: The logical error is discovered in testing.  The problem is analyzed, and the 100+ lines of code for those ten functions are carefully recoded to incorporate the new logic.  The code retested by the testing team and hopefully found no new bugs or regression bugs.  If the development team is diligent, they may also update their UML diagrams, or at least whatever ongoing documentation they have.

Which will take longer to do   Clearly, scenario A will take less time.  However, in order to get schenario A and discover the logical flaws in the design, we have to spend time analyzing it.   Of course, if one spends too much time in design, then we negate its time-saving benefits.  So, one has to be mindful of how much time spent in design is actually cost-effective.  Even if one uses a code-first strategy the need to find logic errors early still applies.  Aferall, the longer a bug is inplace undiscovered, the more dependencies that will exist on the buggy code, and the more things that will potentially need to be changed when the bug is fixed.

I agree with you that the usage of tools is important, and there are no perfect tools.  The point being made here is that, reguardless of what tools you use or how you use them, one of the goals of one's development strategy should be to identify logical flaws (whatever their form) as early in the process as possible, rather than let them fester and become larger problems down the road.  Its one of many considerations one has when selecting and applying a development strategy.