Share via

Bug Density - A reason for considering Managed Code ?

I had an interesting discussion with someone from India last night about embedded software development, one of the subjects we discussed was why someone should consider using Managed (C#/VB) vs. Native (C/C++) application development.

Perhaps some of the reasons are obvious, garbage collection, no pointers, very well organized class libraries, great development tools (Visual Studio 2005), support for devices and desktop applications (and also Windows XP Embedded since desktop applications run on Windows XP Embedded), rapid application development etc... But what about Bug Density ?

If we consider that developers typically code ~50 bugs per 1,000 lines of code (I've seen numbers that range from 10-50 bugs/1000 in different reports) then reducing the number of lines of code you write would appear to be an excellent way of reducing the number of bugs in your code, right? - in a recent blog post about supporting a USB Barcode Scanner I had estimates for the number of lines of code needed to support the device and capture barcode data ranging from 4,000 lines (C/C++) through to 10 lines of code for a C#/VB managed application.

Is bug density something you consider when writing code for your embedded devices ?

BTW, the "Spot the Bug!" blog always makes for good reading...

- Mike

Comments

  • Anonymous
    January 31, 2006
    Mike, with all due respect, it's wrong to say that this task would take 4000 C++ LOC, but it only takes 10 C# LOC. That is clearly not apples-to-apples.

    While there are benefits to managed code, and C#, a 400-to-1 reduction in LOC is not one of them. A few percent difference maybe, plus or minus, depending on the task and the availability of libraries.
  • Anonymous
    January 31, 2006
    let's take a simple example written in C++/Win32 and C#/.NET Compact Framework.

    The C++ application has the O/S API's as its "framework" - the C# application has the .NET Compact Framework as its "framework".

    You don't need to write the code, just consider this example...

    Write the code to walk all folders within a Windows CE operating system image and list all .BMP files to a text file or the screen.

    - Mike
  • Anonymous
    January 31, 2006
    The comment has been removed
  • Anonymous
    February 01, 2006
    The comment has been removed
  • Anonymous
    February 01, 2006
    Mike, for your example, "Write the code to walk all folders within a Windows CE operating system image and list all .BMP files to a text file or the screen," this would take a few C# LOC, and for a native implementation you would want to write a helper function that does the equivalent of Directory.GetFiles. But this helper function would only be probably ~10 LOC itself. So the managed code would be a little bigger, but this is not a 400x increase, right?

    Let me modify your example slightly, because in your example, there happens to be a single method that returns just what you want. But in the real world, this isn't usually the case. Instead, say the job was to list out all the BMP files in a directory tree, but we also want to show the size of the file. Now what is the LOC difference between the managed and native code? I would bet they are about the same.

    My point is not to be argumentative. If you tell me that .NET give a 10%, or 25%, or even 50% productivity gain - I will believe you. We see those gains here in our shop since we moved from native C++ to managed C#. But if you tell me there is a 400:1 LOC difference, then I have to speak up. The transition from native to managed is not like the order of magnitude change from assembly to C is/was.
  • Anonymous
    February 01, 2006
    tzagotta, I'm not suggesting that you would always see 400:1 difference when coding native vs. managed - hopefully, when using any framework the number of lines of code you write overall should reduce (otherwise, why use a framework).

    The core question still stands, assuming that using a framework reduces the number of lines you actually write, this should translate into reduced bug density (should).

    So, that being the case, are you more inclined to use a framework, or not.

    - Mike
  • Anonymous
    February 02, 2006
    Mike, I think there are quite a few developers (my own place of business included) that are held up not by resistance of your "framework," but by the fact that this framework relegates us to using a different language altogether.

    From what I can see, the current C++/CLI implementation looks like a great and natural way to extend C++ into the .NET world. And yet we STILL have C++ being treated as a second-class citizen to C# for managed code. Now that we finally have it on the desktop, we STILL can't use it to code for the .NET CF. I'm just not willing to give up C++ to use the framework. I have to imagine that there are others like me as well and MS should try to let go of the C# agenda a bit and bring C++ up to speed in all respects.
  • Anonymous
    February 02, 2006
    The comment has been removed
  • Anonymous
    February 03, 2006
    Hi Valter,

    Thanks for the comment - we're getting ready for the Mobile and Embedded Developers Conference (MEDC) world-tour... we're starting in India in April, then moving to Las Vegas in May - we're not hitting Italy, but will be close! - we have the MEDC Europe event running from June 6-8 in Nice, France - hope to see you there ! - more information about the event can be found here - http://www.microsoft.com/europe/medc/default.asp

    - Mike
  • Anonymous
    February 14, 2006
    I would say it depends. You may want to compromise on the performance or it may be just that for yor application it is not a matter. But, native code smartly written (use all STLs, autoptrs, blah)  always has an edge over managed code in terms of performance. You know when we debate over such issues, personal likings and choices come into picture and we tend to neglect the bigger picture. Agreed, managed code is easier and neater, but peroformance may be topping your priority chart. May be you would like to correct me??
  • Anonymous
    February 15, 2006
    The comment has been removed
  • Anonymous
    January 22, 2009
    PingBack from http://www.hilpers.pl/205271-bug-density-a-reason-for
  • Last updated on