Ok… bad pun but question still stands. We wanted to try and answer that question so we worked with the team at VDC Research to try and quantify some of these questions. You can download their full report on the multicore and multiprocessor landscape, but here’s one piece of data that I thought might be interesting. Basically, heterogeneous processor architectures are growing quickly and the number of projects using simple processor architectures is diminishing fast.

Data from VDC Research showing trend in multiprocessor development

Really, backs-up what we all instinctively know and understand but nice to see some empirical evidence to add to the mix of customer feedback, social media chatter, and articles we’ve been seeing on the topic. We also tried to collect a bunch of other resources on this topic in one spot with a previous endian blog post we published.

Of course, our focus is on the code analysis tooling available to address these issues. If you’re doing a port, the prospect of manually (or semi-manually) crawling through thousands of instances where you need to modify code to support a different endian format really sucks. Some automation would certainly be nice. Our CTO Gwyn Fisher will be talking in more detail on this topic next week. He has a presentation on improving software reliability in multicore and multiprocessor architectures. Check it out.

Part of my life has been spent in the manufacturing sector working with industrial automation devices, but the discovery of the Stuxnet virus is the first time I’ve ever heard of specifically virus targeting and even rootkitting a PLC (programmable logic controller) or  SCADA (supervisory control and data acquisition) network.

When working in industrial plants, we took the standard precautions with regard to Windows viruses and even started to add virus protection for Linux, but never did it occur to any of us that the industrial automation equipment might be at risk. Whenever the subject was even brought up, which was rare in itself, there were the standard arguments:

• Oh, it’s on a physically separate network (or VLAN configuration), only USB (thumb/flash) drives are allowed and they’re virus checked before use.
• Oh, it’s running a completely different processor/operating system/architecture – there’s no way it can be infected.

The consequences of infection are severe.   These devices run everything from our nuclear power plants to complex manufacturing assembly lines, aircraft controls (FADECs) and chemical refineries, just to name a few.  In its most basic of functions, industrial automation is used for two purposes: to keep humans safe and to produce products for less cost.  Interrupting either of these is going to kill someone or cost a company a large chunk of change.

So, what does this all mean?  It means that industrial automation and PLC vendors had better start hardening their solutions for security vulnerabilities and elevate the quality of their firmware and software components using security vulnerability tools such as Klocwork’s static analysis just as the general computing industry has done for the past 30 years.

For an in-depth analysis and timeline, refer to either Symantec’s whitepaper on their Stuxnet analysis or the work done by ESET on their version of Stuxnet.

I recently read a book by Peter Ritchie called “Refactoring with Microsoft Visual Studio 2010” and thought I would give my review.

Great book to really help you get started with Refactoring.  Ritchie first goes into an introduction of refactoring and some of the tools available in Visual Studio 2010.  He then provides techniques to help you identify code that might need to be refactored along with examples and step by step procedures to refactor the code.

The focus of this book is not necessarily with Visual Studio 2010, as many of the refactoring examples he goes through do not even have a solution with Visual Studio, but more with a focus on C# code.  When I first ordered this book it wasn’t entirely clear to me that C# was the only language of focus.  That was a little bit disappointing for me because at Klocwork our focus is on refactoring for C/C++.  I guess I’m not surprised as not too many tools are providing a refactoring solution for C/C++ developers.  But with that said even though all examples are C#, what it really helps you understand is where and when to refactor and that is language independent.

I think Ritchie really describes the question of “why refactor” brilliantly.  The point of refactoring vs. rewriting is to fix something that’s not broken.  But as Ritchie states, he is a believer in if it ain’t broken, don’t fix it, but unless your code base defies all reality, it is likely that your code is constantly evolving and getting more complex.  Hence the need to refactor.

Another important point made by Ritchie is that refactoring falls into the developer’s hands.  It is not a task that keeps building up until you identify numerous backlog’s of refactoring.  It is something you need to do daily, as needed.

Overall I enjoyed the detail and examples provided and recommend it to any.  I hope to talk a little more on how Ritchie relates metrics to refactoring in another post.

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.