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 (12)

  1. tzagotta says:

    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.

  2. mikehall says:

    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

  3. Valter Minute (valter.minuteATgmail.com) says:

    I agree about the fact that the garbage collector and the class library could simplify the development and reduce the amount of bugs.

    But when you say that you can use 10 lines of code instead of 4000 this (IMVHO) means that someone else wrote 3990 lines of code to support you 🙂 and you’ve no controls about the bugs that he could have put inside his code!

    I’m not saying that you’ve to write code from scratch, but that when you choose to use high-level tools you should check their reliability and not only their ease of use or the number of features they’ve.

    Opening source code (like ms does on Windows CE) is a great way to enhance debugging capabilities and to increase users trust in a product.

    The .NET CF 2.0 is a great tool and I used it in a project where I’ve previously discarded CF 1.1 because of his performance and lack of features.

    I think that any problem has one or more tools suitable to solve it. A good programmer should have a large toolset so he can always pick the tool that solves the problem in the best way (and best means fastest but also more reliable one).

  4. mikehall says:

    Valter – at some level you are always relying on something, whether this be the Compact Framework, the native operating system API’s, the assembler, compiler, linker.

    Sure, you *could* decide not to rely on other peoples code, but this would mean you are writing an operating system from the ground up – probably not the best use of your time.

    I talked with Richard Greenberg from the Compact Framework team some time ago about the Compact Framework and memory management – my point being that, at some level, the Compact Framework *must* be calling into native operating system API’s to manage memory and objects – the CF team spends a TON of time verifying the native interface from the Framework (here’s a link to the interview with Richard – embeddedpodcast.com/Podcast/MED102505_RichardGreenberg.mp3)

    There’s also a good discussion of memory management from the Compact Framework on Mike Zintels blog – http://blogs.msdn.com/mikezintel/archive/2004/12/08/278153.aspx

    So what’s my point? – You have a set of tools and languages available to you, C/C++, Win32, MFC, ATL, STL, WTL, C#/VB, Compact Framework – You need to make a decision about the tool set and framework (and I include the Win32 API here) that matches your needs.

    When writing tools for Windows CE (which run on the desktop) I wouldn’t dream of moving back to Win32/MFC, .NET Managed development is SOOOOOO much more productive. If you’ve not tried it I would recommend taking a look.

    – Mike

  5. tzagotta says:

    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.

  6. mikehall says:

    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

  7. Jay Daniel says:

    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.

  8. Valter Minute (valter.minuteATgmail.com) says:

    Hi Mike, I don’t want to write my own OS, Windows CE works very well for me and can meet all my customer needs, so there’s no point in taking such a big effort.

    I apologyze if sometimes my writing is not so understandable, but I’m not english mother tongue (any MSDN/embedded conference in Italy is planned?).

    I tried to point out that using an high-level tool/language allows you to write less code and less bugs but requires a cereful choice of the tool.

    If I program in assembler with no OS, I rely only on the hardware working as specified (and this is sometimes a risk…). If I use an OS and many tools I should rely on them and so I should be very careful in choosing them.

    I use the .NET CF and I’ve to say that version 2.0 is a big step forward in term of both features and reliability.

    After I used the framework and its class library I also never feel the "need" to use windows forms in the "native" way or process XML using a non-managed parser!

    I would like to be able to put my hand "under the hood" (like I can do with Windows CE shared source code) when something goes wrong or don’t behave the way I expect.

    I hope that more and more tools and information will be released about the .NET CF to allow the developer to feel more "in control" of the system. I think that in an embedded environment this is a very important thing.

  9. mikehall says:

    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

  10. Gursharan says:

    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??

  11. tzagotta says:

    >>But, native code smartly written (use all STLs, autoptrs, blah)  always has an edge over managed code in terms of performance.<<

    No, I disagree, especially when you say "always."

    I am currently re-writing an application from native C++ to (managed) C#.  This is a GUI that does some data management and presentation work.  What I’m finding is that the execution speed is the same between the two for all the different things this program does.

    We’ve also written other apps in C# where there is not a directly-comparable C++ app, but where the net result was considered by us and by our customers as "fast."

    The performance argument just doesn’t hold water, in my experience.  Especially when managed apps are so much faster to write.

    Disclaimer: My experience in on Windows with .NET 2.0.  I haven’t worked with CF 2.0 at all.

Skip to main content