Archive for February, 2008

The PHR Battle: Microsoft vs. Google (redux, again)

Tuesday, February 26th, 2008

Here in Orlando at HIMSS'08 Google is barely noticeable and Microsoft is making a huge splash. Even so, Scott Shreeve unabashedly declares Google the PHR winner in his Getting Giga Over Google (Again) post:

My prediction: Google by a long shot. A really long, interconnected, collaborative, collective intelligence, networked kind of aggregated intelligence kind of a shot.

Whether you a agree with Scott or not, it's a good read.

My only caution: It's never a good idea to underestimate Microsoft. They may come to the game late, but when they put their minds (and resources) to it, they often win.

Microsoft Interoperability Principles

Saturday, February 23rd, 2008

As with many Microsoft press offerings, Microsoft Makes Strategic Changes in Technology and Business Practices to Expand Interoperability has created quite a stir. When you think about interoperability, Microsoft isn't the first thing that pops into your head.

The talk in the open source community regarding this announcement is understandably negative (read through the Slashdot commentary). According to the Interoperability Principles, Microsoft is opening up their protocols and APIs and embracing industry standards. That's good. But look at the Open Source Compatibility (I.5, my highlight):

Microsoft will covenant not to sue open source developers for development and non-commercial distribution of implementations of these Open Protocols.

This plus the licensing of patented software "at low royalty rates" have made the Microsoft naysayers say "nay" (yet again) and that this is all just another marketing ploy.

Maybe so. This philosophical change is not meant to make Microsoft a FOSS (free open source software) company. Their goal is still to make money, which is exactly what their shareholders demand.

I think providing an improved forum for open source interoperability, and presumably better support moving forward, is a good thing. As long as Microsoft continues to own the desktop, the easier it is to inter-operate with their “high-volume products”, the better. This will certainly be true for the healthcare industries, which like most others, depend on Microsoft products.

UPDATE (3/4/08):

Check out Microsoft's Interoperability Principles and IE8 (and here). This is good news for the Web development community. Doing the right thing must be good for business.

Brain Control Headset

Wednesday, February 20th, 2008

Via Slashdot, Emotiv has a new Brain control headset for gamers scheduled to come out later this year:

THOUGHT-CONTROLLED GAMING HEADSET

  • Sensors respond to the electrical impulses behind different thoughts; enabling a user's brain to influence gameplay directly
  • Conscious thoughts, facial expressions, and non-conscious emotions can all be detected
  • Gyroscope enables a cursor or camera to be controlled by head movements
  • The headset uses wi-fi to connect to a computer

I've discussed this type of Mind Reading Software before (and here).

Interpreting motion and/or motor signals (facial expressions) is one thing. I'd love to know what type of EEG processing will be used to detect conscious thoughts and non-conscious emotions. At the very least, this type of quantitative EEG analysis has to begin with high quality EEG signals. I don't know how this can be done from an unprepared scalp and electrodes that are applied without gel.

UPDATE (3/2/08):

Via Slashdot, here (and here) is another game controller from OCZ (the Neural Impulse Actuator (NIA) is not currently a listed product). The NIA works by "... reading bioptentials. These include activities of the brain, the autonomous nervous system and muscle." You can't help but be skeptical about the value of this technology for these purposes.

UPDATE (3/22/08):

More information on the Emotiv device: 'Mind Gaming' Could Enter Market This Year.

Software Development: Driven by what?

Sunday, February 17th, 2008

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:

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.

Medical Device Data System (MDDS) FDA Rule Changes

Friday, February 8th, 2008

As reported here and here, the FDA is proposing to reclassify a MDDS from a Class III to a Class I medical device. On the surface this might seem like a big deal. If you read the fine print though (my highlight):

FDA has already recognized that the class III requirements are not necessary for ensuring the safety and effectiveness of MDDS devices and has been exercising enforcement discretion with MDDS device manufacturers. These firms have not been required to submit PMAs or meet other requirements typically required of manufacturers of class III devices, but the agency believes that all or nearly all firms in this industry have in place good business practices, including quality systems.

They're just formalizing already established practices.

Selecting a MVC/MVP Implementation for a Winforms Project

Friday, February 1st, 2008

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:

Spaghetti

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:

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.

Passive View — a Derivative of the Model-View-Control

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

UPDATE (11-Sep-08): Still more: MVC vs. MVP: A Hillbilly's Journey.