Bob on Medical Device Software

Google recently open sourced Protocol Buffers: Google’s Data Interchange Format (documentation, code download). What are Protocol Buffers?

Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – think XML, but smaller, faster, and simpler.

The documentation is complete and worth a quick read through. A complete analysis of PB vs. XML can be found here:  So You Say You Want to Kill XML…..

As discussed, one of the biggest drawbacks for us .NET developers is that there is no support for the  .NET platform. That aside, all of the issues examined are at the crux of why interoperability is so difficult. Here are some key points from the Neward post:

1. The advantage to the XML approach, of course, is that it provides a degree of flexibility; the advantage of the Protocol Buffer approach is that the code to produce and consume the elements can be much simpler, and therefore, faster.
2. The Protocol Buffer scheme assumes working with a stream-based (which usually means file-based) storage style for when Protocol Buffers are used as a storage mechanism. … This gets us into the long and involved discussion around object databases.
3. Anything that relies on a shared definition file that is used for code-generation purposes, what I often call The Myth of the One True Schema. Assuming a developer creates a working .proto/.idl/.wsdl definition, and two companies agree on it, what happens when one side wants to evolve or change that definition? Who gets to decide the evolutionary progress of that file?

Anyone that has considered using a “standard” has had to grapple with these types of issues. All standards gain their generality by having to trade-off for something (speed, size, etc.). This is why most developers choose to build proprietary systems that meet their specific internal needs. For internal purposes, there’s generally not a need to compromise. PB is a good example of this.

This also seems to be true in the medical device industry.  Within our product architectures we build components to best meet our customer requirements without regard for the outside world. Interfacing with others (interoperability) is generally a completely separate task, if not a product unto itself.

Interoperability is about creating standards which means having to compromise and make trade-offs.  It would be nice if Healthcare interoperability could be just a technical discussion like the PB vs. XML debate. This would allow better integration of standards directly into products so that there would be less of the current split-personality (internal vs. external  needs) development mentality.

Another thing I noticed about the PB announcement — how quickly it was held up to XML as a competing standard. With Google’s clout, simply giving it away creates a de facto standard. Within the medical connectivity world though, there is no Google.

I’ve talked about this before, but I’m going to say it again anyway. From my medical device perspective, with so many confusing standards and competing implementations the decision on what to use ends up not being based on technical issues at all. It’s all about picking the right N partners for your market of interest, which translates into N (or more) interface implementations. This isn’t just wasteful, it’s also wrong. Unfortunately, I don’t see a solution to this situation coming in the near future.

Bare with me, I’ll get to the point of the title by the end of the post.

I primarily develop for Microsoft platform targets, so I have a lot of familiarity with Microsoft development tools and operating systems. I also work with Linux-based systems, but mostly on the systems administration side: maintaining servers for R&D tools like Trac and Subversion.

I recently had some interest in trying to use Mono running on Linux as .NET development platform.

This also allowed me to try Microsoft Virtual PC 2007 (SP1) on XP-SP3. I went to a local .NET Developer’s Group (here) meeting a couple of weeks ago on Virtual PC technology. Being a Microsoft group most of the discussion was on running Microsoft OS’s, but I saw the potential for using VPC running Linux for cross-platform development. My PC is an older Pentium D dual core without virtualization support, but it has 3Gig of RAM and plenty of hard disk space, so I thought I’d give it a try.

Download and installation of Ubuntu 8.04 (Hardy Heron) LTS Desktop on VPC-2007 is a little quirky, but there are many blog posts that detail what it takes to create a stable system: e.g. Installing Ubuntu 8.04 under Microsoft Virtual PC 2007. Other system optimizations and fixes are easily found, particularly on the Ubuntu Forums.

OK, so now I have a fresh Linux installation and my goal is to install a Mono development environment. I started off by following the instructions in the Ubuntu section from the Mono Other Downloads page. The base Ubuntu Mono installation does not include development tools. From some reading I found that I also had to install the compilers:

# apt-get install mono-mcs
# apt-get install mono-gmcs

So now I move on to MonoDevelop. Here’s what the download page looks like:

Here’s my first grip: Why do I have to download and install four other dependencies (not including the Mono compiler dependency that’s not even mentioned here)?

Second grip: All of the packages require unpacking, going to a shell prompt, changing to the unpack directory, and running the dreaded:

./configure
make

Also notice the line: “Compiling the following order will yield the most favorable response.” What does that mean?

So I download Mono.Addins 0.3, unpack it, and run ./configure. Here’s what I get:

configure: error: No al tool found. You need to install either the mono or .Net SDK.

This is as far as I’ve gotten. I’m sure there’s a solution for this. I know I either forgot to install something or made a stupid error somewhere along the way. Until I spend the time searching through forums and blogs to figure it out, I’m dead in the water.

I’m not trying to single out the Mono project here. If you’ve even tried to install a Unix application or library you inevitably end up in dependency hell — having to install a series of other packages that in turn require some other dependency to be installed.

So, to the point of this post: There’s a lot of talk about why Linux, which is free, isn’t more widely adopted on the desktop. Ubuntu is a great product — the UI is intuitive, system administration isn’t any worse than Windows, and all the productivity tools you need are available.

In my opinion, one reason is ./configure and make. If the open source community wants more developers for creating innovative software applications that will attract a wider user base, these have to go. I’m sure that the experience I’ve described here has turned away many developers.

Microsoft has their problems, but they have the distinct advantage of being able to provide a complete set of proprietary software along with excellent development tools (Visual Studio with ReSharper is hard to beat). Install them, and you’re creating and deploying applications instantly.

The first step to improving Linux adoption has to be making it easier for developers to simply get started.

We ran into an interesting problem recently that I have not been able to find documented anywhere.

We’re doing real-time USB data acquisition with .NET 2.0. The data bandwidth and processing isn’t overwhelming. Specifically, we expect data packets at 50 Hz — every 20 ms. Yet we were having horrible delay problems. In the end we found that Console.Writeline was the culprit!

To verify this a test program was written to measure the throughput of the following loop:

while (m_working) {
   Console.WriteLine(string.Format("Message {0} [{1}]",cnt++,mstr));
}

The length of mstr is varied and this loop is run for about 30 seconds. The results show the ms per message for increasing message lengths:

Console.Writeline is surprisingly slow!

We use log4net for our logging. With the timestamp and class information, a log message is typically greater than 100 characters. A single log message introduces at least a 20 ms delay in that case, with additional messages adding that much more. Even though debug logging would not be included in the released version, these significant delays make development difficult.

Not only do you need to make sure that there are no Console.Writeline's in your real-time threads you also need to remove the console appender (<appender-ref ref="ConsoleAppender"/>) from the log4net configuration. The log4net file appenders do not cause noticeable delays.

This is tough to do. There are tons of technical books out there. Also, now that the Internet can instantly answer just about any question, the path of least resistance leads to arguments like this: Why I don’t read books.

There is no right or wrong when in comes to learning methods. It’s a personal preference. I’m a book reader, but I can understand how Internet content (blogs, articles, etc.) has made it easy for people that don’t like books (for whatever reason) to acquire relevant knowledge.

The availability of “Best” lists are abundant. For example:

• Programmers Don’t Read Books — But You Should: As usual, Jeff is in top form here.
• UnSpun by Amazon: Best Programming Books: Based on reader reviews.
• The Best Programming Books Ranked by Programmers: Categorizes ranked books by topic.
• The 5 Books that Every Programmer Should Read: Lots of comments with other suggestions and opinions.
• The Top 9½ In a Hacker’s Bookshelf: Each is well reviewed.

OK, so once you get past the classics (Code Complete 2, The Pragmatic Programmer, Design Patterns, etc.) where do you go from there?

I will typically invest in books on emerging technologies that I want to fully understand (a recent one was Windows Presentation Foundation Unleashed — highly recommended). The real challenge is finding a book that doesn’t suck. Reviews and recommendations by other readers, like from the sites above, are the best resources.

My other vetting technique is standing (and reading) for long periods of time in the nerd-book section of a bookstore. There’s no substitute for browsing the pages of a real book. The one that’s still in your hand when your SO drags you towards the exit is probably the best one to buy.

I guess I didn’t get the memo.

Here’s the first couple of sentences from this post:

Several drops ago we introduced a ViewModel composition spike. The purpose of this spike was to introduce…

I don’t know why, but this terminology caught me by surprise. My interpretations are:

• Drop: a software release.
• Spike: a quickly written new or enhanced feature used as a proof of concept (e.g. see here)

Drops are sometimes used in CodePlex-P&P projects and spikes are often referenced in the ALT.NET discussion group (searched for here).

Anyway, I like the sound of these. They’re succinct and to the point. I foresee them becoming a common part of the developer’s lexicon.

If you follow Microsoft comings and goings, one of the more interesting developments (at least to me) over the last 8 months has been the formation of a community that calls themselves ALT.NET.

As explained in What is ALT .NET?, the term was coined by David Laribee last year and describes a group of

like-minded individuals within the larger world of the Microsoft® .NET Framework who felt a growing frustration that Microsoft tooling, guidance, and .NET culture at large did not reflect or support an important set of core values.

The name is misleading because even though most members are from the .NET community, the group’s purpose is to promote a set of core values that are platform/language independent. To summarize from Jeremy’s article:

1. Keeping an eye out for a better way.
2. Adopt the best of any community.
3. Not content with the status quo — experimenting with techniques.
4. It’s the principles and knowledge that really matter.

The members of the ALT.NET group are distinguished technologist and many are productive bloggers, e.g. codebetter.com and Ayende@Rahien. Also, the discussion group altdotnet is very active (over 6200 posts since the beginning of the year) and lively. There are also periodic group meetings (see the ALT.NET site for links) that use Open Space Technology (OST) to organize conference agendas. Check out the interesting videos (by David Laribee) from the recent conference in Seattle.

So why are ALT.NETters not like the rest of us? We’re experienced developers that use modern tools and techniques, but we:

• Have never used enterprise-class frameworks and tools (e.g. Biztalk, P&P Application Blocks, ESB, TFS, etc.).
• Have never worked with a “Software Architect”. We have always had to design and develop our own systems.
• Have experimented with Agile development methodologies but have never been part of a “real” Agile team.
• Think Pair programming is an April Fool’s joke.
• As with Agile, we know about all the different “driven” software development approaches, but have never had the opportunity to fully embrace any of them.
• Have heard about Boo, Spec#, and F#, but have never used them.

This list could go on and on. Many have never used an ORM or the MVC design pattern either. The point isn’t what we know versus what they know. I’ve talked about Stereotyping Programmers before and how it’s just plain bad. I think the ALT.NET community has made a conscious effort to improve their inclusiveness.

The ALT.NET group is certainly on the cutting edge of useful and innovative software technologies and techniques. We may not understand everything they’re talking about, but the conversation is well worth listening to. Someday you may be faced with a challenge that will need just the type of solutions they’ve been discussing.

If you’ve never run across it before, the TIOBE Index is an interesting measure of the popularity of current programming languages.

The definition of how the index is calculated is here. The rankings are based on relative number of “hits of the most popular search engines.” As noted in the FAQ, even these relative numbers can be affected by changes in the methodology used by a search engine.

I’ve looked at Google Trends in the past, so I thought I’d do a quick check on some of the highly ranked non-grouped languages (here):

This result is surprising in that C seems to have more hits than either Java or C++. Maybe it’s because GT doesn’t include Google Blogs (or does it?), MSN, Yahoo!, and YouTube. With Google having ~70% of the search market share (see here) the addition of the others shouldn’t make that much of a difference. It would be nice to understand the discrepancy.

I can’t say I have a lot of faith in Google Trends results in general though. Their definition:

Google Trends analyzes a portion of Google web searches to compute how many searches have been done for the terms you enter, relative to the total number of searches done on Google over time. We then show you a graph with the results — our search-volume graph — plotted on a linear scale.

This explains the general downward trend — there are a lot more searches being done overall relative to these terms. Actually, just about any search term produces a similar looking plot. Only those that have specific events (like this), an annual activity (this), or seasonal fluctuations (this) show anything of interest. Trying to use GT for anything else seems fruitless.

Anyway, as to the usefulness of Tiobe Index:

The index can be used to check whether your programming skills are still up to date or to make a strategic decision about what programming language should be adopted when starting to build a new software system.

Some people think The TIOBE index is meaningless. There’s also some good analysis and discussion in Programming Language Trends. I don’t think the index is meaningless, but using it for either of the stated purposes should be put into perspective.

The first thing is that in terms of the mainstream (A) languages, not a lot has changed in the last five years. Because these trends move so slowly, an A language you pick today will probably still be A in four or five years from now.

The trends for lessor used languages (B and below) are of academic interest only and the position jocking (’Python beats Perl’) is meaningless without knowing the reason why. If you want to know what the next A-list language is going to be in the future, try Top 10 programming languages of the future.

More importantly though is that your language choice(s) should be based on the best practices used in the industry that you work. The selection of a language or tool is based on many criteria. The Tiobe (or any other) list position is most likely going to be a small part of that decision process.

First a definition:

driv·en –adjective

1. : having a compulsive or urgent quality
2. : propelled or motivated by something — used in combination <results-driven>

Driven software development methodologies abound:

• Behavior-Driven Development (BDD)
• Design-Driven Development (D3)
• Domain-Driven Design (DDD)
• Feature-Driven Development (FDD)
• Model-Driven Architecture (MDA)
• Process-Driven Development (PDD)
• Test-Driven Development (TDD)

Many of these are encompassed by the iterative Agile software development methodologies. Collectively they are sometimes referred to as the XDD acronyms. As you might expect, these along with all of the other competing, contrasting, and overlapping development philosophies can cause a software developer much consternation. Confessions of a Software Developer* is a good example of the overload that can occur.

My reason for bringing up driven methodologies is not to complain about being overwhelmed by them (which, like most others, I am). It’s simply to point out the contradiction of X-Driven with the Merriam-Webster definition. I think this will help us better understand what should really be driving us.

Look closely at definition #2. Propelled or motivated by something … results-driven. What is that something? Ah ha!

The fundamental motivation for all of these development approaches is to:

Improve productivity and quality.

This is the result, the goal. Behavior, Model, Test, etc. are all just the means by which we are trying to achieve this desired result. It’s the result that we’re driven towards, not the methods and techniques we use to get there.

So, in order to make this distinction clear and to eliminate confusion in the future, I propose that all these methodologies be renamed from Driven to Guided. Think of them like you would a GPS system in your car, except these will allow you to find software Nirvana. TDD is now TGD, and the whole lot is known as XGD.

The point here is that you should not let any particular development philosophy blind you to what the real purpose of using it is in the first place. Being guided by a methodology helps me remember that better than when I’m driven by it. Also, the whole concept of being driven seems exclusionary to me. You shouldn’t hesitate use the pieces and parts of any combination of these techniques that best suites your needs.

I’m not a computer scientist. I’m also not one of the many über programmers that create and analyze software frameworks and techniques. I simply design and develop software that attempts to meet my customer’s needs. To that end I’m always looking for the best tools available to get the job done.

Jeremy Miller states the importance of design patterns well:

I know many people blow off design patterns as ivory tower twaddle and silly jargon, but I think they’re very important in regards to designing user interface code. Design patterns give us a common vocabulary that we can use in design discussions. A study of patterns opens up the accumulated wisdom of developers who have come before us.

My opinion: You don’t need to be a rocket scientist to understand design patterns. Most are just common sense. Complex patterns are designed to solve complex problems. Design patterns should be thought of as a tool that you use just like any other. Don’t let the ‘ivory tower twaddle’ scare you away.

I think most people would agree that one of the key components to creating a successful software product is quality. I’ve developed .NET applications in the past and have experienced the difficulty of testing and maintaining the functionality of Winform forms and components when they are created with the default Visual Studio tools. If you’re not careful, here’s what you end up with:

Photo hat tip: Josh Smith from Using MVC to Unit Test WPF Applications — a very good and relevant article.

I should note here that the development of software for medical devices already has rigorous verification and validation processes to ensure quality. See FDA Good Manufacturing Practice (GMP - Quality System Regulation) subpart C–Design Control (§ 820.30 sections f & g). However, these requirements do not preclude the need for development techniques that make the software more robust and maintainable. On the contrary, the higher the software quality, the easier it is to meet these standards.

I’ve recently spent some time trying to select a GUI architecture that will allow us to create a more robust unit testing environment. This is why I started looking at Model-View-Controller (MVC) and Model-View-Presenter (MVP) design patterns. The need for these types of design patterns is twofold:

1. Separation of Concerns (SoC), which allows for
2. Improved Testability.

There are many articles and blog posts that describe MVC, MVP, and their numerous variations. These techniques have been around for many years but the current corner-stone comes from these Martin Fowler articles:

• GUI Architectures
• Passive View
• Supervising Controller

Once you understand these concepts you can start to grasp the trade-offs of all of the available MVC/MVP flavors. If you’re like me, one of the problems you’ll run into is that there are so many different approaches (and opinions) that you’ll be left wondering which is best to implement. The only advice you’ll get is that it’s a matter of choice. Great, thanks! From the article above, Josh puts it best:

If you put ten software architects into a room and have them discuss what the Model-View-Controller pattern is, you will end up with twelve different opinions.

This is when you turn from the theory and start looking for concrete implementations that might be suitable for your situation. Microsoft has released an ASP.NET MVC Framework as part of VS2008, but all of the Winform code samples I found were part of either blog posts or articles.

As you look at the different implementations (and relevant snippets), you quickly realize that following these design patterns requires significantly more work than just adding your application’s logic directly to the IDE generated delegates. The additional work is expected and is the trade-off for improved testability.

That’s fine, and worth it, but it’s still time and money. We do not have the resources, or experience, to undertake a full Test-Driven Development (TDD) effort. We will implement MVC/MVP on only the displays that we feel are the most vulnerable.

I’m not going to list all of the candidate examples I looked at. I will mention that Jeremy’s series of articles (here) dig deep into these issues and have lots of good code examples. Each approach has their pros and cons, just like the one I’ll present here. We’ll try to use it, but may end up with something else in the end. As we become more experienced, I suspect we’ll evolve into a customized solution that best meets our needs.

A Promising Candidate:

Implementing the Passive View — a Derivative of the Model-View-Control by Matthew Cochran.

This hybrid approach appealed to me for a couple of reasons. The first is that I spent several years doing Swing development, which uses a MVC that also allows multiple simultaneous views of a single model. I also like the event driven approach, which is not only heavily used in Java, but is also well supported in .NET. In any case, the View is passive and all of the important functional logic is centralized in the Controller class which can be easily tested with real or mock Model and View objects.

Matthew has done a good job of providing support generic classes that make implementation somewhat less cumbersome. The MvcControlBase class provides generic Control-View wiring while ChangeRequestEvents manages all events in a single class.

The project download provided by the article is a VS2008 solution. We’re still using VS2005, but I was able to back-port the project to VS2005 with only minor modifications that had no effect on functionality. The VS2005 project is available for download here:

MVC-PV-2005.zip (23K)

Final Thoughts:

I see adoption of MVC/MCP methodology for GUI development as a critical component for improvement in software reliability, quality, and long-term maintainability. Also, structuring the application side with MVC/MVP is only half the battle. Developing an effective testing strategy must go along with it in order to achieve these objectives. Until Microsoft provides an integrated Winforms MVC solution like they did for ASP.NET, we’ll just have to continue to roll our own.

I’d like to hear about your experiences, suggestions, and recommendations on any of these topics.

Thanks!

UPDATE (6-May-08): Here’s a good MVC article by Jeff Atwood: Understanding Model-View-Controller

UPDATE (16-Jun-08): Another reference: Everything You Wanted To Know About MVC and MVP But Were Afraid To Ask

Let’s start with a definition of Stereotype:

Stereotypes are generalizations about groups and their individual members, based primarily on membership in that group. They may be positive or negative, they may be accurate or inaccurate regarding average characteristics of a group, and may be used to justify certain discriminatory behaviors. Some people consider all stereotypes to be negative because they are unjust to individuals who vary from group characteristics.

Over the last week Jeff Atwood had a couple of posts on this subject: The Two Types of Programmers and Mort, Elvis, Einstein, and You.

If you dig into some of the links from these posts you’ll find that the Microsoft persona classifications have been the source of heated debate for a long time. There is no fine line here, in this context personas and stereotyping are the same thing.

The first time I heard the terms ‘Mort’ and ‘Elvis’ was when I read ALT.NET Recap: Front and center, let’s talk constructively about Mort. As you can tell from my comment to that post, I was greatly offended. I probably over-reacted. I just reread the post though, and I still feel the same way. Here’s an example of why:

Back to the question about whether or not Mort can get the stuff we’re talking about like separation of concerns and TDD. The typical Mort has managed to acquire a working knowledge of…

And the “Mort related quotes” didn’t help either.

Even though Jeremy’s intent was to explore how to improve the ALT.NET community, the use of stereotypes in this manner seriously distracts from that purpose. As I commented, if I came away feeling that way, I’m sure that others will too.

I don’t mean to single out Jeremy in this regard (even though I did) — his blog is consistently high quality, and inoffensive. The use of Mort-Elvis-Einstein is ubiquitous in the Microsoft blogosphere.

On the other hand, when I read the posts by Jeff and others that debate this issue I take no offense at all. I can even thoughtfully try to place myself into the different personas like many of the commenter’s did. This just shows how important context and intent are. As Jeff found out, this is a touchy issue — nobody likes to be pigeonholed.

Grouping based on stereotypes is inherently non-inclusive (there’s always someone not in a group, or in the wrong group). Even after you’ve figured out how to reach the unreachable, make sure that your message is made in an inclusive way.

UPDATE: (5-Dec-07)

This is sort of related: Call to Action : People Are Not Resources (via D’Arcy). Related in that calling people resources is also stereotyping, at least by the strictest definition. The more common form of stereotyping in exclusive, whereas being a pork-belly is all-inclusive. For some reason, I’m not as offended by being considered a resource as I am being called a Mort. But that’s just me.

What I don’t get is that if calling individual humans “resources” is bad, how come “Human Resources”, as a department name, is fine? If you want to get rid of labels, you really need to start at the top. How about “Human Assets” or the “Recruitment, Retainment, and Severance” department?

UPDATE: (12-Dec-07)

Jay Kimble has another take on this issue in his Is it 80% and 20% or is 20% too high… post.

…it seems to me that there are 2 kinds of people.

Those that think hard on an issue and those that don’t.

I would further generalize and say that laziness is one of the root causes of stereotyping. Stereotyping is the easy way out (”buzz words”) and is done by people that don’t want to take the time to understand another persons point-of-view or the complexity of an issue.