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?

My first 2 posts looked at 2 different eras of Static Code Analysis, the Early Years and the Early 21^st Century. The SCA solutions of these times were revolutionary, and helped software development teams a great deal. But they had their warts.

In the final post in this series, I’m going to introduce you to the present day Static Code Analysis technology and how it is impacting developers.

The Present Day

I’m a huge fan of Reece’s Peanut Butter Cups. I love them. I keep active so I don’t feel guilty eating them. In a strange, convoluted way, the 3^rd generation of static code analysis tools are like this delicious combination of chocolate and peanut butter. Let me explain.

Eureka! Now developers are able to perform an analysis locally, using their development environment of choice, while still getting the high accuracy and consistency that was previously only possible by checking in their code and waiting for the integration build to take place.

Think about the ramifications of this:

• cleaner code is being checked in
• the ‘rinse-repeat’ vicious cycle of rework is drastically reduced
• quality teams are now able to focus on testing the product’s functionality rather than spending cycles uncovering something that could easily and quickly be found by automated tools.

Mmmm-mmmm good. Sounds like a win-win-win to me!

I think the best thing about these 3rd generation tools is simply the fact that developers are now able to resume ownership of the quality and security of the code they are producing.

Well, I hope you enjoyed this walk down memory lane. I sure did. Now I’m looking for spare change because I see a trip to the vending machine in my immediate future.

If you want to know more about the 3rd Generation tools, feel free to drop me a line.

Our marketing people here at Klocwork like to see me racking up frequent flyer miles and expending CO2 at roadshows, conferences and tradeshows. Whenever I’m out speaking, I always like to gauge audience familiarity with Static Code Analysis.

I’m happy to say that SCA knowledge has definitely increased over the years, but it is still not up to levels enjoyed by unit testing or integration testing.

What I plan to do over the next three weeks is to provide you with a history lesson on how Static Code Analysis has evolved over the past few decades (yes, it has been around that long!). The three different eras I will be addressing are The Early Years, The Early 21^st Century, and  The Present Day.

The Early Years

As I mentioned earlier, Static Code Analysis has actually been around since the time of bell bottoms, disco music, and Space Invaders (check out the Space Invaders link)–yes, the good ole 1970s. Who out there has heard of Lint (and no, I’m not talking about the fluff coming from your old bell bottoms pockets)?

Lint was one of these first-generation SCA tools introduced in the late 70s. These tools targeted low hanging fruit in C code, such as missing or extra semi-colons, missing curlicues, potentially dangerous implicit casts, and so on.

These tools were closely integrated with the compile and link process, and so this seemed like the best time to show its errors and warnings, while the developer was actually “in process” and fixing problems found by the compiler. Since these tools delivered its warnings at compile time, it quickly became a tool that was adopted and owned by the developers themselves.

Life was good. Well, until the bugs that were being found were deemed to be relatively trivial or completely erroneous (the dreaded false positive). The problem was that these tools were only able to see one file at a time, but for accurate static analysis there is a strong need to know everything that’s going on within the entire stream.

Without that vision of the entire stream, no matter how sophisticated the analysis tools are, they will make incorrect assumptions most of the time. Because of these inaccuracies, these first-generation tools never gained the widespread acceptance of software developers.

Next up will be a look at static analysis tools during a time when “Whassssuuuupp” became a household term.

Crying into your wadded Kleenex about how your vulnerabilities were exploited may make for compelling TV, but when it comes to software security, they’ll cost you a lot more than your personal dignity. Or maybe they’ll cost you millions of dollars in lost business and your personal dignity.

Why not toughen up your code by implementing software security best practices that prevent or mitigate the risks?

That’s why you should head on over to the Klocwork Developer Network and check out the free eLearning courses provided by Security Innovation, an industry leader in software security and cryptography. To view learning resources, just log in or register.

Here’s a brief description of each course:

• OWASP Top 10 – Threats and Mitigations

Learn strategies and best practices for understanding, identifying and mitigating the risk of vulnerabilities and attacks within the OWASP Top 10.

• Intro to the Microsoft Security Development Lifecycle (SDL)

The Security Development Lifecycle (SDL), a key security engineering process that was spawned from Microsoft’s Trustworthy Computing Initiative. Learn the necessary steps to meet SDL requirements, and identify the appropriate tools required by the SDL.

• Intro to XSS – Asp.Net examples

Learn to understand the mechanisms behind cross-site scripting vulnerabilities, describe cross-site scripting vulnerabilities and their consequences, and apply secure coding best practices to prevent cross-site scripting vulnerabilities.

• Intro to XSS – Java

Learn to understand the mechanisms behind cross-site scripting vulnerabilities, describe cross-site scripting vulnerabilities and their consequences, and apply secure coding best practices to prevent cross-site scripting vulnerabilities.

Have fun, code safely and put that Kleenex away (unless it’s allergy season).

Last week I toured the West coast with our friends from VersionOne, Perforce, and Electric Cloud on our Agile roadshow hitting the cities of Seattle, Santa Clara, and San Diego. In one of the after meeting discussions, one of the attendees asked me what the differences were between Agile and Lean. Having only been involved with Lean from an outside perspective, I didn’t really think there were huge differences and that they shared many of the same beliefs.

Luckily, it looks like others believe this to be the case too. So rather than me trying to explain this, this timely blog does a great job of explaining Agile and Lean, and why there is a lack of understanding and acceptance of Agile practices in many companies that practice Lean.

Also, as part of this Agile roadshow, we had a bit of a celebrity in our midst--our illustrious keynote speaker David Hussman of DevJam consulting has a past that most of us weekend musicians dream about. He was part of a big-hair metal band! Not only can he play a mean guitar, the dude knows his stuff about Agile and gave one of the best keynotes I’ve ever seen. Check out his website when you get a chance, and see if you can find him in this video.

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!

With our latest product release, we have ventured into the world of Apple. Yup, our product is now officially supported on the Mac.

I think I can safely say that this was not something on our roadmap a few years ago, but we recognized the trends, and now have this offering for our customers. With this support, it was determined that we needed a few more Macs in the organization, the Product Management team included. Now, I’m not sure I stepped forward, or everyone else stepped back (except me), but I ended up being the PM Mac guinea pig.

I have been using PCs since, well for a long time, so this was definitely going to be a learning experience. Let’s say that Google and I became very good friends the first couple of weeks with my shiny new Mac.

In my travels, I stumbled across this article that lists the top 30 mistakes made by new Mac users. Even though this article is a little old, it is amazing how many still apply. Here are a few that I have already qualified for:

15. Installing a program every time they want to run it because they think the installer is the program.

16. Where’s “the internet”? (looking for the Windows Internet Explorer “e” icon)

19. Looking in vain for an uninstaller app, because they don’t realize that uninstalling an application on Mac is as easy as dragging the program icon into the trash.

23. Saving everything to the desktop or somewhere on the hard drive other than their home folder

These are just a few of my favorites, and I’m sure I’ll fall into a few others. Someone once told me that if you need to do something on a Mac, pretend you don’t know anything about computers, and think to yourself what the easiest way might be to accomplish that task. Chances are that is how it has been implemented on the Mac (see #30 in this list). Anyone run into any other goodies that aren’t listed here?

It started with the iPod and slowly but systematically gained momentum.

A few years ago, I asked a developer-friend how he decides whether he’ll buy a dev tool or not. He responded somewhat tongue in cheek with, “I will download the tool, play with it and then decide if I would rather spend my money on the latest iPod or the dev tool.” Maybe this is a bit of an edge case, but it speaks to the thought process that goes into the individual developer’s personal workspace design.

For anyone who thinks it’s not all about the developer, think again!

We noticed a trend developing a couple of years ago in some of our largest accounts. A few very small teams in a handful of accounts asked us about our plans to support Mac. When we spoke to the central teams within those accounts about the priority of Mac OS X as a supported environment, it was initially downplayed as a requirement from a few “special project teams.” They reiterated that their corporate development environment continued to be Windows and/or Unix/Linux.

Think again. Like most wars developers decide to fight, they are winning this war as well.

Many of our major accounts now have, or are planning, a significant Mac presence in their development organizations. Apple may say they are not targeting the enterprise, but it is clear the enterprise is targeting Apple. Tim Cook, COO of Apple, made a comment to the analysts in July that 80% of the Fortune 100 are deploying the iPhone, and 50% of the Fortune 100 are testing or have begun deploying the iPad. I bet the same is happening with the Mac. From executives to developers to marketing personnel, the Mac is gaining momentum in the enterprise. For this trend to continue, there are some enterprise-friendly enhancements necessary for the Mac to be a true corporate citizen, but I have found tools like Parallels and VMWare serve as a viable backup plan when total Mac native mode doesn’t cut it.

As the old saying goes, “the proof is in the pudding.” In my opinion, no saying is more apropos, given the prior attitude many technically savvy people had towards Mac. They seemed to universally describe it as, well, a toy! Sure it does useful stuff, but any serious computer user will stick with Windows or Unix. Well, the times they are a-changin’ (since we’re on a cliché kick, I couldn’t resist some classic Bob Dylan).  Several developers I know who once spurned the Mac have quietly added the Mac to their day-to-day development activity. You can argue all you want about whether Mac has critical mass in the enterprise developer world. We are not. We are simply listening to our customers, and as a result we are launching Mac support this month.

Developer needs are constantly changing, but one constant always seems to be that developers quietly find a way to get what they want to do their job.

There have been a number of stories about internet dating gone bad lately.  One regularly hears stories about how people misrepresent themselves on dating websites; use old pictures, or even someone else’s pictures to lure unsuspecting love interests in.

These type of experiences are not limited to those seeking love…it also happens to those seeking a job, or those seeking an employee.  Technology is a wonderful thing but should never be used in place of the good old face to face meeting that must happen in the recruiting process (and in the love match process) .  I made a rookie mistake way back at the start of my career that reinforced this for me.   I was working for a high tech company that shall remain nameless, as I was not the only idiotic one in this story and I must protect those who are not as forthcoming about their idiocy.  We were looking for a developer, and the search was not going well.  Finally, we came across a resume from an individual, and it looked quite impressive.  As the individual lived in a different city, we set up a phone call for the interview.  It went well enough for us to want to have a technical interview with the individual, so in the interests of saving time and money, we also set that up by phone.  I am not sure I would have been able to tell there was anything amiss if I had been on that call, but in hindsight, I should have at least placed the call, or sat through a few minutes of it.  The technical interview went very well.  Then… we made our big error in judgement, we extended an offer without having laid eyes on the person, the offer included relocation costs.

Within 2 hours of the person starting, the hiring manager came to me in a panic.  Apparently, she was quite certain that this was not the same person she had interviewed over the phone…this became blatantly obvious as time went on.   We are still  not entirely sure what happened but we suspect the candidate had someone else do the technical interview for him…and since it was over the phone, we had no way of knowing.  Needless to say, the new employee did not stay an employee for very long and I learned a very valuable lesson.

This goes both ways…it is worth the trip to check out an employer face to face.  I have no doubt that candidates have been wooed by companies that were far less than they appeared and had a face to face meeting at the company’s site been conducted, lots of relevant and valuable information would have been gathered.  Do your due diligence in looking for a job, don’t accept what a recruiter says at face value, there are some wonderful jokes about recruiters and I will share one in my next blog.

Mark Grice in a more peaceful moment.

The last time I spoke to the Klocwork Director and Manager of the International Reseller/Partner Network, he outlined 7 habits of highly ineffective Source Code Analysis (SCA) tool selection.

Among those terrible habits, he described an SCA tool-selection process that involved endless feature comparisons and massive checklists of irrelevant requirements.

His head almost exploded, but on this day our SCA guru was calmer.  Clearly, he’s been using relaxation techniques or drinking some of the good stuff, like acai juice.

According to Grice, successful SCA tool adoption involves three key steps:

1. Involve your developers in the process.
   “Developers understand what their requirements are,” Grice says. “And that means your selection criteria will be more realistic and achievable, and it will focus on what’s relevant to the organization’s software and environment. Developers are also best equipped to assess the SCA results.”
2. Limit your selection to market-leading tools with the functionality relevant to your software needs.
   “For example, if MISRA compliance is something you care about, then make that part of your selection criteria,” he says.
3. Have a game plan with a path and a defined end. Work toward a goal that’s realistic—spend enough time, but not forever, finding the tool (or tools) you need.
   “Have a good idea of what will constitute success, and be prepared to make a decision and move on,” Grice says. “Avoid paralysis analysis—unless your goal is to just waste time and money and contribute nothing to improving your software.”

That’s it for today. Grice is off to yoga class (um, or a pub). Stayed tuned for the next post in this series–How smart companies adopt SCA tools.