Over the past few years I’ve talked to a number of customers in the embedded software and medical devices industries, and I continue to see a significant number of these organizations either moving to, or planning on moving to agile development processes.

With all of the inherent challenges for agile in these organizations such as standards/regulatory compliance, hardware changes and integration, security issues, etc. I must say that I’m a little shocked that customers are moving away from their current processes towards something like agile. Add to this the fact that the Agile Manifesto specifically states “Working software over comprehensive documentation” and it doesn’t exactly sound like agile is a great fit for embedded systems in general, let alone medical device.

Now, don’t get me wrong, I am a huge proponent of agile, and I certainly realize that there are many pros for moving to agile, and these have been well documented, but I have to wonder just how agile are these specific industries going?  I would bet that most (all?) of these organizations are adopting some of the key fundamentals of agile, but to say they are going “all in” would be a bit of a stretch.

Even industries heavy on process (because of regulatory requirements) are taking the leap into agile. How agile are they?

Looking at the manifesto a little closer, some of the principles are fairly generic and feel more like common sense than anything revolutionary, so they probably apply to any industry. There are a few principles however that are fairly easy to imagine in these industries, such as:

• getting all stakeholders involved in defining requirements (Principle #4), or
• embracing more face-to-face conversations (Principle #6), and
• simplicity, or minimizing the amount of work not done (Principle #10).

But do people really think that Principles #1 (early and often delivery of software), and #2 (welcome changing requirements) really apply to the embedded or medical devices industries? Personally I don’t see it.

So what do you think? Are the embedded software or medical devices industries capable of going full out Agile?

The two sides of testing team lead Jonathan Patchell.

At daily standup meetings, they eye each other from opposite sides of the room. Sitting on the same side of the cubicle wall is unthinkable.

They’re united only by their desire to produce quality software products and their appreciation for coffee and energy drinks. What’s good to one side can be anathema to the other when it comes to code.

I’m talking, of course, about testing and development teams. In the interests of generating more comments improving dialogue between two very important functions in a software organization, our marketing director asked me to interview our testing team lead, Jonathan Patchell, about the ways in which developers drive his team nuts.

Patchell, a computer systems engineer, has been with Klocwork for five years and a team lead for two. He struck a fairly conciliatory tone for this interview, which sorta ruins the adversarial approach, but don’t let his diplomacy fool you. I’ve seen him suffering as the release date approaches and his demeanour changes completely.

Here are Patchell’s top dev peeves:

What comes first—the process or the tool?

Yes.

Any tool worth its salt should integrate into existing processes and tools.

What’s interesting and informative is seeing the similarities and differences in how the same tool is applied in different organizations, across continents and oceans.

The emphasis on quality unites everyone, but the level to which agile is adopted is what makes static analysis markets different.

No one knows this more than Mark Grice, Klocwork Director and Manager of the International Reseller/Partner Network, and Steve Howard, head of Partner Support in Europe.

Trying to talk to these guys at the same time is a challenge. Mark’s work takes him all over Asia, but I managed to pinpoint him in Japan; Steve spends most of his time traveling across Europe, but was at his home base in England—for a time, anyway.

Same difference

The European and Asian markets are all singing from the same song book when it comes to coding standards.

“MISRA is very appealing here in Europe, particularly on the developer desktop,” Steve says.

“There’s a strong focus on quality here,” Mark says about his Asian market. While MISRA is “somewhat appealing,” Mark says he gets asked about Embedded System development exemplar Reference Series (ESxR) quite a lot. It’s a coding standard similar to MISRA in that it’s aimed at embedded system development, but its adoption is more Japan-centric. For more information, see ESxR at Information-technology Promotion Agency, Japan (IPA).

Steve explains  that the ability to extend checkers to suit the needs of specific organizations is of keen interest to customers in his bailiwick.
“Sometimes organizations want to enforce their own naming conventions or code constructions, and the extensibility tools provide a very quick and effective way to accomplish that,” he says.

Difference

The developer desktop illustrates the great agile divide.

“I’d say Europe is a little bit behind North America in its adoption of agile, but there’s still the same requirement for developer productivity and speed,” Steve says.

For that reason, he sees more opportunity to penetrate the European market with a static code analysis tool for the developer desktop. The growing interest in agile in Europe gives him an increasingly receptive audience.

Japan is a bit different on this score from the rest of Asia.

Quality is seen as the purview of testing teams, and not development. That means that there’s a huge focus on quality at the end of the development life cycle, rather than the beginning, Mark explains.

Desktop source code analysis tools are a harder sell in Japan, but that may change as agile processes trickle in.

And there you have it, a quick peek at a couple of our markets.

In my last post, I talked about some of the reasons why I started developing Android apps. The new Android 2.3 Gingerbread is even better than Froyo. I’m talking about a whole new Nerdy and the Droid factory.

With Gingerbread released and rolled out on the new flagship phone, the Google Nexus S, the developers’ wait is over. Some of the new features and functionalities baked within Gingerbread are:

1.    More power under the hood

My Nexus One lasts me about a day running Froyo. Android is now way smarter in managing its electrons with Gingerbread. With new interface design, smart process management and improved power management, it has increased the battery life significantly.

2.    Near Field Communication

NFC provides high-speed, short-range wireless communication capabilities and is responsible for most of the Gingerbread hype. NFC has introduced many new playgrounds for Android developers such as mobile tickets, mobile payment, identity documents, smart posters, electronic keys and more.

3.    Improved audio and graphics

Gingerbread now supports extra-large screen sizes and resolutions in addition to audio, graphic and input enhancements. This is a red carpet invitation for game developers to knock themselves out!

4.    Session Initiation Protocol VOIP telephony

SIP VOIP allows enhanced video and audio calling. It also supports video conferencing, streaming multimedia distribution, instant messaging, file transfer and online games.

5.    Native sensor support

Gingerbread now natively supports sensors such as the gyroscopes and barometers.

And let’s not forget new features like concurrent garbage collection, multi-touch software keyboard, enhanced support for native code, multi-camera support and new download management.

With all these new building blocks, I can’t wait to see what new apps are going to show up on my App Market!

Happy coding!

The open-source, Linux-based and hardware-independent Android mobile OS, with the new Android 2.3 Gingerbread release is giving mobile developers a whole new ball court to play in. Android is the fastest growing mobile OS among its competitors and with its share in the Smartphone user market growing, Android is attracting more and more enthusiastic developers.

Being a Java developer I jumped right into Android development about a year ago. There is a whole list of reasons why I chose to develop Android apps over other platforms and here are some of them:

1.    Low development costs and high returns

There is almost no cost to develop an Android app. There are no required licenses, specific IDEs or limited distribution channels. You may end up spending money on development and testing expertise, use of specific app stores and the purchase test devices, but the sum of all that is still a fraction of what you would pay to develop on other popular mobile platforms.

2.    Open and free

The two words every developer wants to hear are ‘Open’ and ‘Free’. Now you can have that on your mobile! This baby is license and royalty free because its underlying SDK architecture remains open source. The entire environment is available for customization, and developers and organizations can provide as detailed feedback as they want to the Android development team and watch as their issues get addressed in frequent new releases.

3.    Various distribution channels

Developers are not limited to the Android app market or any other channels to get their apps on consumers’ phones. Apps can be legally downloaded and installed from any unknown sources.

4.    The good old Java

Being Java based, Android uses a rich pool of libraries that provide extreme flexibility and room for uncapped creativity. Android’s topnotch documentation means virtually anyone with a working knowledge of Java can get Android applications off the ground.

5.    Flash Love!

Before Android gathered its well deserved power and popularity, Flash was thought to be a dying technology since it wasn’t supported by other mobile industry giants. There is obviously a ‘but’ here! The green robot embraced flash and took mobile web surfing to a whole new level.

6.    A little piece of the cloud

Android is heavily meshed with the cloud and it carries superior Google connectivity solutions. Google’s cloud tools are already soaring on the popularity list and they come right to the palms of the users’ hands with Android. One can also take advantage of browser connectivity solutions for Chrome and Firefox. In addition, Android provides open Bluetooth communication, something that is missing on some other popular platforms. Versions 2.2 Froyo and later allow the phone to become a portable hotspot. Now that is cool!

The awesome obviously doesn’t stop here. In my next post, I’ll talk about Android 2.3 Gingerbread features and what there is for us mobile app developers to play with!

Happy coding!

Deadlock: frog vs. snake
Photo: David Maitland / National Geographic

Continuing the discussion about the embedded community moving to muticore/hetrogeneous hardware from watch out here comes multicore, embedded software development teams have historically been shielded from mulitcore issues. This is due to the specialized functionality of many embedded application classes and the inherent serialized nature of the C language.^[1]

Muticore is an ambiguous term for software developers and one they don’t really use; software developers think in terms of threads/processes and concurrency, not how many cores or processors are available on the target. Concurrency is not a new topic either as Mark Smotherman captured in a history of multithreading, it has been a subject in computer science since its early beginnings in the 1950s.

What has changed is the rapidly increasing use of multicore technologies for embedded devices. One of the prominent software challenges that moving to multicore execution exposes is latent deadlocking bugs as true parallel execution comes into play, instead of a single core’s task scheduling/context switching techniques.

As an example, consider the following code snippet, which has been paraphrased from a deadlock discovered in a real-world open source multithreaded project.

Can you spot the deadlock?

lock_t lock1, lock2;
int refCount = 0;

void enter() {
   reserve_lock(lock1);
      if( refCount == 0 )
         reserve_lock(lock2);
       release_lock(lock1);
   refCount++;
}

void leave() {
   reserve_lock(lock1);
   refCount--;
   if( refCount == 0 )
      release_lock(lock2);
   release_lock(lock1);
}

To see the answer and understand the conditions that lead to the deadlock, download Klocwork’s whitepaper on Developing software for multicore.

A little about the picture in this post.  I found it when searching for pictures of deadlocks.  The photographer, David Maitland, titled his image “Deadlock” and describes it as a continuing struggle between a Morelet’s tree frog and cat-eyed snake. After three hours in the high-stakes cage match, Maitland said there was no clear winner.

VDC Research, “Next Generation Embedded Hardware Architectures: Driving Onset of Project Delays, Costs Overruns, and Software Development Challenges”, September 2010.

Processing Architecture for embedded devices in the current projects and expected in next two years

Although multicore and multiprocessor technologies have started to proliferate in the embedded market, smartphone manufacturers are in the midst of a rapid shift to multicores due the market transistion from business users to consumers. It’s becoming evident that in order for handset manufactures to differentiated their products, a feature war has commenced: wireless connectivity, video/flash/audio playback and even video creation/editing/conferencing have become are market drivers.

CPU designers have already responded to this need, just last week ARM announced its next generation of Cortex^™-A15 MPCore^™ design and Intel entered the smartphone cpu market earlier this year with the new Atom Z6 core.

For perspective, in a short few years mobile handset industry has had to move from relatively simple devices supporting cellular communication and user-interface tasks to multicore/multi-chip designs in order to grow features and thus market share. Until the arrival of power-aware multicore and heterogeneous chipsets, cellular devices have been limited by computational horsepower, power envelopes and time-to-market issues.

In any market with tremendous competition, time-to-market is crucial and one of the fastest methods to add features within the tight power budget is to add additional task-specialized silicon either as heterogeneous cores or chips from third-party suppliers that can be put to sleep or turned off entirely when not required.

Feature growth has in turn placed new burdens on mobile software development teams. Leaving the comfortable environment of a single core means addressing potential threading/concurrency problems and endian ordering issues when integer data is transmitted off-core.

Klocwork commissioned VDC Research to quantify the business impact of moving to multicore/multiprocessor environments and the results of this growing complexity is stark: multicore and multiprocessor software projects are

• 4.5X more expensive,
• have 25% longer schedules,
• and require almost 3x as many software engineers.^[1]

Embedded and especially smartphone development teams need to be gearing up for the feature arms race to come and should be looking at methods to mitigate theses impacts by implementing productivity tools like static analysis and automated code reviews sooner than later.

[1] VDC Research, “Next Generation Embedded Hardware Architectures: Driving Onset of Project Delays, Costs Overruns, and Software Development Challenges”, September 2010.