Next week I’m heading out to the Software Assurance Forum (use SOF96945 for the conference code) in Washington D.C. (well, actually Arlington, Virginia, but D.C. sounds more glamorous). If you’re not familiar with what the SWA is, in a nutshell, its key objective is to encourage software developers to raise overall software quality and security from the start, rather than relying on applying patches to systems after vulnerabilities are discovered.

Anyways, while I’m there, I’ll be taking part in 2 speaking opportunities. The first will be as part of a 6 person panel discussion entitled “Understanding Technology Stakeholders: Their Progress and Challenges” (10:30 – 12:00 on Wednesday). The panel is made up of stakeholders from varying disciplines such as industry, academia, standards, and government. A good well rounded panel should provide for an interesting and entertaining hour and a half.

My second session (Friday at 2:20) will see me fly solo as I discuss our (Klocwork’s) experiences and observations as they relate to SATE. I’m not given much time, so I’ll be revving up the motor mouth to make sure I get our points across. I have a sneaking suspicion I just *may* go a little OT.

So, is anyone out there also going to this event? If so, drop me a line either by email (todd.landry@klocwork.com), or Twitter (@todd_landry) and perhaps we can get together to chat. Look for my next blog next Thursday, as I will recap the panel discussion and the other sessions I attend at this event.

I have always loved “I’m gonna write me a new minivan”  from Scott Adams.  To me, it never gets old.  Originally published in 1998, the theme that applied then still does today: driving 100% of defects or bugs out of the code-base is a laudable goal, but is it really the right one?   I would have to argue no.  There’s no silver bullet out there that will find all software defects and solve issues automagically, and until there is, software development will continue to struggle with prioritization.  Unfortunately, we live in a world of finite resources and constantly evolving demands, but we can always dream about being Wally for a little while.

Overall a good show at ESC.  Always well run and put together.  In terms of vendors we had some great discussions especially with Electric Cloud.  We managed to see a great demo of ElectricInsight.

ElectricInsight is very visual giving you an incredible view of the structure of a software build.  Not only a tool to help you visualize the impact of adding nodes to ElectricAccelerator cluster but it helps with diagnosing your build problems in seconds.  Really cool dependency analysis with a click of a button.

In the end there is no doubt the economy has taken its toll on ESC Boston 2009.  By far one of the worst turn outs for the exhibit show floor.  But one thing I can take away from this, I’m the Wii Jousting champ!

Succinctly communicating what Klocwork does and how it helps improve productivity during code reviews, integration builds, and of course for developers is always a challenge. We’ve tried to capture this visually with this simple SDLC image, and of course we always talk about the importance of finding bugs early.

Then somebody else comes along and makes the point in a way you never thought of… here’s a funny that’s been going around for some time, but I figured it’s worth passing along to the Kloctalk readers.

Off to Agile 2009 next week in Chicago where Klocwork will be both attending and exhibiting at the conference. We’ll blog throughout the week to keep people updated and let you know the latest. There are a few sessions in particular that we’ll be sure to report on and let readers know anything useful we learned (or not):

• Adopting Agile in an FDA Regulated Environment
• Java and Ruby Tools for Code Quality
• Effective Code Reviews in Agile Teams
• Zen and the Art of Software Quality
• Scrum and CMMI – from Good to Great

Be sure to check back often!

There I have said it. As a marketer, I am disappointed in my peers in their attempts to get their message in the hands of their audience.  Over the past couple of weeks, I have attended a few webinars from other organizations selling software development tools that were truly atrocious.  So here are a few pointers for my few marketers on webinars:

• Stop talking down to the audience – treating your prospects as unintelligent blobs is not the way to connect or be heard. These people are senior developers and engineering managers of Fortune 500 companies not kids coming out of school. Yes, there is a need to bring everyone up to speed and get them to the same knowledge level but that can be done in the first few minutes; don’t do it throughout the presentation.

• Slideware hell:
  • Have a congruent theme – pick one major point and each and every slide in the rest of the presentation should support that theme. Don’t over complicate it.
  • Don’t read your slides – I can read too;  I don’t need you to do that.  I need you to tell me why your point is important so that I pay attention and expand into examples and facts that prove your point.
  • Don’t cram every possible benefit on to a slide – this goes with the previous point – at most 4 bullet points – highlight what is important and use your oratory skills to expand
  • Balance your text with meaningful visuals – I am going to scan your slide in 10 seconds and then turn my brain off. So to keep my attention, give me a visual containing information not just data and each slide needs to tell me something new

• Don’t try to garner respect, earn it. Don’t tell me in your previous life you shared their pain; it comes off as false. Product Managers, you especially  have been the ones at fault for this one.  I am not attending to hear about you. I have a problem; I am looking for a solution.

• Respect their time: webinars are a great vehicle to communicate with an audience but don’t overdo it.  I personally don’t sign up to webinars that last an hour.  I am not willing to give you that much of my time and I would hazard to say neither does most of the potential audience.  Check your abandonment or engagement rates.

Enough ranting and berating of my fellow marketers but together we have to get better at what we do.

Truepath Analysis

Ever been faced with that glassy-eyed expression, the look of unthinking, unwholesome fear when some long, incomprehensible word escapes your geeky mouth and upsets the maiden aunts around the once-a-year, wear-your-best-tie, try-not-to-die-before-the-cake’s-all-gone tea table? OK, so this paper won’t help you in that situation whatsoever, but if you replace your maiden aunts with a bunch of your best geek friends, and replace the tea with a sturdy helping of Dew, knowing how a real whole program analysis solution works might just conceivably come in handy. Some day. “Dude, I was totally stoked when I read this thing, trust me it’s ahh-some.” Maybe.

Anyway, in the best traditions of self-serving corporate PR blogs everywhere, I give you… drum roll please… Whole Program Analysis, the Klocwork Way.

Enjoy.

!(social media)

I will probably get flack for this but I am going to exclude web developers from this discussion of adoption rates about social media in the developer sphere.

Having moved through the technical streams over to the dark side of marketing, I have learned to challenge assumptions and here is one of mine I think needs testing.   In this new age of “social media” and interaction, I have yet to see the leadership in the developer community make any substantive use of it.   I would love to be proved wrong on this one.   Social media, in my view, is really just branding what people have been doing for years: using peers to converse and exchange information on topics and facilitating interaction, even for niche subjects like the merits of static code analysis in mission critical applications.

The adoption rate of the “formal” social media is what I am interested in.  The blogs, twitters, facebook, digg,  etc, you know the brands that I mean.  I have been looking for weeks to find any concrete data on adoption rate and have been hard pressed to find much.

• Technorati  (March 2008- State of the Blogosphere) – 26.4 million blogs vs less than a handful about software development.
• Google Trends indicates that the ratio of software blogging to the main stream is 258 times less.
• Digg has just over 18583 diggs for software development versus over 3 million for marketing
• Twitter volumes are similar 13 900 versus 1.4 million

Why hasn’t the paradigm shift happen here like in other industries?  Online marketers are eating up social networking on Himalayan scale, so why not in development circles.  Speculating on human behaviour is not without its caveats but are technical people so different from say marketers or bus dev people?  In a nut shell – yes.

It’s  not to say developers aren’t social, in many ways the development community has been the leading the wave [Yes, that is an intentional pun for the upcoming Google Wave]. I would argue that software development has been social for well over a decade as best exemplified by the open source movement.  Some of the greatest advancements in software design and productivity have come from major collaborative efforts such as the  LAMP stack, OpenOffice and Android just to name a tiny few and open source has lead to the rise and fall or changed of direction in many a company – see Apple adopting the Linux kernel etc.

My conclusion on all this: the software development community has voted with their feet.  They do not need yet another vehicle to find their voice when they already use mechanisms (open source collaboration, forums, community websites etc) that do the job quite nicely thank you very much.

So if you disagree, take up the sword and prove otherwise.

PS. And yes I get the irony of writing a social media piece about software development on a blog. :-)

The hype has been on for years and although the frustrations of continued dropped cell calls  haunts us all, the future has arrived in full swing….pardon the pun!!! I thought this article between “Mad Money Cramer” and MLB is a fantastic illustration of a dream unfolding before everyone’s eyes.

This month has been a time to reflect upon the historic moment 40 years ago of man’s first walk on the moon.  I am sure just about everyone can remember where they were when the first televised pictures captivated the world.  For the legions of people that made that historic event a reality, they undoubtedly felt they  were living on the bleeding edge of technology with as many known’s as unknowns. But for the rest of us, it was a completely controlled event.  One we marveled at but did not participate in. One we were all touched by, but could not touch.

Contrast that event to what is transpiring today. We are in the midst of an “explosion of the mobile Internet”, but it hasn’t arrive with a single defining moment.  It has crept up on us virally, gradually becoming more pervasive and entrenching itself in our daily lives.  Even trying to quantify the market potential is difficult to predict, as Cramer exemplifies  - “Until you see these applications, you don’t understand how this thing is going to take over the world. It’s the definition of why I value the Mobile Internet as the biggest investable trend I’ve ever seen.”

There was a time when many of us tech-maniacs would hear from our significant other “are you ever going to put that damn thing down”  referring to our iPhone or Blackberry.  Now I for one watch in stunned silence as my kids and significant other are constantly glued to either their iPhone or Blackberry.  What was once the exclusive domain of the workaholic, semi-obsessed information junkie,  has become the “always connected” device of…well everyone I know.  It is no longer a “work device”  it is “my device.”

The transformation was fairly seamless and uneventful except for one subtle difference….one by one we are all participating in this event…not just witnessing it. Experts in the varied  fields of human behavior must be licking their chops as this new era spreads across humanity like the rising sun across the horizon.

The world has changed and I sometimes wonder if we now have “a new world disorder.”  A world where snippets of information are all anyone has time or interest in, a world where one on one communication is not the norm, a world where if we are not connected we are not comfortable.

Somehow it all seemed more managed when it was a “work device” as opposed to “my device.”  Time will tell how far out in front the “explosive mobile internet” progress is over the process necessary to support it.

There was a recent blog on the top 10 good reasons for Scrum, so in the spirit of equality, I thought I would do one on the top 10 reasons not to go Scrum. Now, before I get started, let it be known that I am a huge fan of Scrum and agile (so much in fact that I am certified as a Product Owner), but there are definitely situations where it just might not make sense to go that route.

1. Your development team is geographically dispersed. In my opinion, this is the main reason why it would not make a lot of sense to go Scrum. Scrum (and agile) are all about communication, and even though technology has made it easier to communicate across the globe, a winky-face over MSN cannot get the same message across as a face to face conversation.

2. If you are currently meeting deadlines and release dates. I’m a big believer in the adage, if it ain’t broke, don’t fix it. Why would you want to mess up something that is working for you? Short answer…you don’t…

3. You cannot get complete buy-in or 100% commitment from management, development, PM, etc. If a PM cannot actively attend meetings, or management wants to make rash decisions outside of the team, then it just will not work…don’t even bother trying.

4. If people need complete clarity about the solution before even starting the project. The very nature of agile/scrum lends itself to this just not happening.

5. You have a fixed deadline, with a fixed set of requirements. This happens all the time…perhaps you have specific functionality planned for a big event, or a big customer. If this is the case, then it might make sense to manage this using more traditional project management methods.

While the original blog that inspired this had 10 reasons, my time this iteration is up, so I will only provide 5. If you have others you’d like to share, feel free to leave a comment.