As new words and concepts diffuse in to wider use, their definitions become simpler or broaden to cover more scope.  Like the kid’s telephone game, each time the concept is passed to another developer, the information gets a little more muddled. In software development, declaration, macros, syntax and other programming constructs have to be exact or the compilers will fail.  Yet, when developers discuss concepts about programming, most of the time, that precision of language is lost.

The telephone game  seems to have happened to refactoring.  I subscribe to what would be consider the  ”classic” definition of  refactoring: the process of optimizing or extending a class  but leaving the existing exposed interface alone.  It seems that refactoring has been generalized from that definition into covering all activities related to touching old code.  Even worse, it has become an excuse to rework someone else’s code and then bitch about how bad it was.  Just look at the twitter stream for refactoring for a never-ending torrent of  abuse.

There is one simple way to tell if your efforts are truly a refactoring or not.  Did you break any of the unit tests?  If you did, then you are rewriting code instead of refactoring it and you had better update all the test cases while you’re at it.  Don’t get me wrong, there are times to rewrite software, but they are few and far between and, in my experience, it almost never pays off.

Refactoring isn’t just a nice philosophical idea; it supports one the most basic concepts in software development–backwards compatibility.  If you want to keep your customers and enjoy that paycheck, don’t break features or APIs in products without good reason or  get buy-in before release day.

To refactor the medical phrase “First, do no harm“, for developers it should be “First, break no test”.

In the beginning was the word. And thanks to Guttenberg, the word was often enclosed in a glossy book and sold for $49.95 at my local computer store. The noble computer book with a shelf-life of six months was the perfect solution for a piano with a missing wheel. Computer books (part of the discipline of book-learnin’) are an increasingly endangered species. Sales of computer books have been off by 8 to 10% year over year for a decade, a trend that shows no sign of slowing.

Still, I miss old-school, printed computer books. It wasn’t so much what they contained, as what they quantified. Using the Rumsfeld model, a nice fat computer book helps me quantify the unknown unknowns. As I tackle a new body of knowledge – say a new language or IDE – the unknown unknowns are infinite. As soon as I have that book in my hand, the unknown unknowns turn into known unknowns. I now know how much I don’t know, and the table of contents is my new best friend – whether I read the book or not. It is hard to beat stretching out at the cottage with a refreshing beverage and the latest tome on source code analysis.

But software developers don’t typically think in linear ways. While many of us are college or university trained, in spite of years of classroom training we run away from learning new knowledge in the old school way. Developers search for the answer to their current problem, rather than accumulating knowledge for its own sake. They listen and watch communities, RSS feeds and blogs for trends. They look for on-line videos, podcasts, newsletters, and magazines. They may even find a book in PDF, and print out a few pages that they want to use for reference.

The challenge for technology companies is to make our collection of facts, tools and interfaces accessible without binding it all up in a single document with a cover. Wikis, on-line API tutorials, developer communities, and a host of other information bits need to replace the old book model.

Of course, it’s hard to argue with Groucho Marx, when he said “Outside of a dog, a book is man’s best friend. Inside of a dog it’s too dark to read.”

Fooled by the job description

So you are not really happy with your current position and you are starting to sniff around.  You might go to Monster and check out some of the jobs that are posted there. You may check out some companies’ websites and see what open positions they have.  Regardless of how you go about looking for a new job though, you will run into job descriptions.  There may be a few job descriptions out there that excite you and motivate you to apply because you can totally see yourself working for a company that writes such a perfect job description for you; however, the majority of them will cause your eyes to glaze over and probably bring on a few face splitting yawns.

Bear with us, there is reason to our insanity when it comes to job descriptions.  When recruiting for any position, but in particular for technical positions, we must pull together something that provides some guidance to job seekers.  And while I am at it, I will be completely honest and admit that sometimes I get the requirements for the position and realize I have no clue what the manager is talking about.  But the manager asked for it so it gets incorporated into the job description.

Job descriptions can be incredibly useful if you know what you are looking for.  They should give a feel of the company, the job and even the team.  I am sure you have all seen those blogs or websites that provide humorous takes on particular phrases, and admittedly some of those have a ring of truth to it.  Yes, sometimes seeing the term “start-up company” can be a rather unsubtle hint that the compensation package maybe more creative than you had bargained for.  “Team Player” can indicate that your team may be challenging and difficult to get along with or…it might mean that the manager wants someone who can play nice with others, because mean people do not do very well in that environment.

The job description does describe the ideal candidate, and really, we do not expect to see the ideal, but we do want a person who fits the job description.  For example, if the job description asks for 5-7 years in C/C++, and you have 3 years of C/C++, then by all means apply. If you have 0 years in C/C++, then do not apply.  The skills are listed there for a reason.

Since you are reading this, you may be on the Klocwork website.  If so, check out our careers section.  You might read a job description on there that appeals to you, and if you do, send us your resume.

Want to get rolling with a Source Code Analysis (SCA) tool as efficiently as possible?

“Do what the smart companies do,” says Mark Grice, a Klocwork Director and Manager of the International Reseller/Partner Network.

In our last discussion, Grice outlined three best practices for SCA tools selection: involve your developers, limit your selection to market-leading tools, and identify a deadline.

According to Grice, smart companies take those best practices and:

1. Buy an introductory package and pick one development team that will deploy the SCA tool.
2. Do an in-depth performance analysis after six months.
3. Expand the rollout to other teams…or not.

“After the six-month period,” says Grice, “a company will widen its deployment circle and get more licenses.”

On the other hand, Grice says it’s also possible that the company will decide to try another tool from their panel of tools. They won’t need to re-evaluate because they’ve got a short list to pull from.

“They don’t lose, whichever way it goes,” he says. “During that six-month period, they got value from that tool by applying it to their codebase, learning about SCA and cleaning up their code.”

Most code reviews are done in-person, 60%  according to data  from a Forrester Consulting study commissioned by Klocwork.  So how do you accommodate remote sites, out-of-office employees  or off-shore development shops?

Most software developer teams will face some form of remote development challenge during their careers or product cycles.  As demonstrated from the data above, the breakdown of remote need is as follows:

• 76% use some form of outsourcing,
• 64% have some developers  located outside of the main campus,
• 40% of reviews are conducted with remote participants.

You can’t let development come to a grinding halt simply because a critical team member is not physically available at the scheduled time or location.  For most organizations, code reviews need to be performed and employee travel is not the solution for cost and timing reasons.  This has driven the adoption of lightweight review processes and new tools that support it.

Klocwork built a code review tool for this express purpose.  Other ones exist like Code Collaborator and the open source Review Board .  How do you support your remote code reviews?  Email?  Wiki? Or a purpose-built tool like one of the ones mentioned?

I love this quote by Carl Ek from  Code Integrity solutions:

There are 0010 0000 kinds of people in the world: Those that understand the difference between Big Endian and Little Endian, and those that do not.

Issues with Endianism and processor architecture ports are becoming more and more common these days as more desktop source code moves into different arenas.  Gone are the days when the 32-bit memory model or little-endian format dominate. Software changes are required to support the growth occurring not at the desktop, but in the server  and mobile platforms.

Mobile devices especially have opened a Pandora’s box of Endian and memory problems, with variety of processor architectures with ARM[1] leading the way.  Add to this mix,  end-consumers are demanding desktop features like Adobe Flash or Office apps on mobile devices, many a stable codebase will fall apart when ported to either mobile or server.

For developers porting to different platforms, there are some significant challenges.  Just to list a few:

• CPU optimizations need to be reviewed
• inline assembly calls require rewriting or removal
• machine word (WORD) allocations may require refactoring
• any binary data exchanged over the network stacks require verification

None of these are  new, they’re just not a common skillset for most developers.

Source code analysis can be a boon in two ways. Firstly, in the planning phase by helping you determine the breadth of the effort,  and secondly by identifying any existing  issues, particularly of the memory allocation and Endian varieties.

For more in depth information, there are two recent articles available from Dr. Dobbs:

• Porting to 64-bit Platforms by Irving Rabin
• Detecting Endian Issues with Static Analysis Tools by Carl Ek

[1] Note: Some ARM processors support both big and little Endian formats.

I’ve talked about different metrics that are used to measure quality and the metrics that developers would use in practice.  But what about the tools themselves?  How are you measuring the value you are getting out of these tools?

In terms of static analysis, one obvious measurement is simply the bug fixes you have made.  Most organizations have a number they use to define the cost savings for each bug.  Using some research data from IBM puts the cost of fixing a bug before a release at 40-50 times cheaper.   Fixing a bug after release is the extreme and hopefully you’re finding these issues earlier and that’s where static analysis comes in.

I would think any static analysis tool offering would give you that simple graph.  Below is a couple of examples where you can track the fixes per component or per owner.

Bug fixes per compoent

Bug fixes per owner

One other thing that I think is very important is where you’re saving money.  When you run static analysis for example you have a couple of choices where you can find defects.  After the integration build or right at the developers desktop before they check-in their code.  Obviously if the developers are finding and fixing their issues while they code and before they even get checked in then it is saving even more money for the company.  Good static analysis tools will help you see the value of using it at the desktop.  A simple counter is all you need to see how many bugs were fixed in the code prior to check-in.  Immediate ROI from using static analysis.

Mark Grice in a more peaceful moment.

Today, Mark Grice is in a better mood.

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.

There has been lots of discussion on this blog (and others for that matter) on the importance of early defect detection, refactoring, and code reviews, but what does it all mean to a team of developers trying to maximize their velocity in a 2 week iteration? Based on a number of studies, and some real-world customer feedback  we have put together the following ROI…but note that this ROI is not measured in dollars, but rather in hours saved, because a development team can more easily relate to a 20 hour time savings per iteration rather than a break even point of 14.5 months. A few assumptions first…the team is made up of 10 developers, working on 5 stories (each story creates about 300 LOC) every 2 week iteration. Also, we used internal estimates for the refactoring time savings since we couldn’t find any 3rd party data on refactoring ROI. . If you have anything more concrete, I’d love to hear about it.

From this table (which has been a regular slide in our Agile in Action roadshow series) we see that tools can help, in this example just over 40 hours/iteration, which if you break that down further works out to about 1/2 day per developer every 2 weeks. Now that is an ROI that an agile development team can relate to…

As the topic suggests, this kind of argument has been around for some time.  Most developers can recognize the need for tools but once you start breaking the developer’s day-to -day workflow you might as well flush that tool down the drain.

What developers need is a tool that seamlessly integrates with their development environment and their workflow, so they can meet their quality goals without taking a big productivity hit.

It’s one thing to provide plug-in tools for the more popular IDEs like Visual Studio and Eclipse, but it’s an added bonus when defect detection is a seamless part of the edit cycle. No buttons to click, just continuous analysis and issue highlighting while you work.

Let’s take the analogy to the spell checker.  Initially, you had to click a button to spell check your document. That has obviously changed dramatically. Now we see any mistakes we make as we type them (and can even fix them automatically).

That’s what we were thinking when we introduced continuous analysis in our plug-in tools and our source viewer for command-line tools, Klocwork Desktop.

Here’s the spell checker equivalent for source code analysis:

The above screenshot is from our Visual Studio plug-in.

When you open or save a file, the analysis runs in the background. A bug marker in the left gutter and a squiggly line, in the true spirit of the spell checker, clearly marks the detected issue.

Find ‘em and fix’em while you work.

It was a mistake for Eric to wear a t-shirt to his job interview, and it was a bigger mistake to wear that particular t-shirt.

People who do not get hired after an interview second guess themselves; they look for concrete reasons as to why they were not hired for that particular job.  They might justify it by saying the company sucked, the interviewer was an HR douchebag, the hiring manager did not know their stuff.  Of course, they may be correct in passing these judgments, however, chances are there simply was a mismatch between the person interviewing and the company.  When this happens, count your blessings that the people doing the interviewing for the company knew that.  Being brought into a company that is a mismatch with your values and attitudes can impact everything you do, not to mention, make you downright miserable.

An interview is an opportunity for you to interview the company…to find out if you like them.  It is not just about sitting in front of some scary people and answering the questions they fire at you.   For most people, interviews are not pleasant experiences.  However, they are an evil necessity, until a more effective way of assessing people is invented.  And this brings me to the point of this blog…how the hell do you get through an interview?

1. Be prepared, know the names of the interviewers, know the company business and feel free to bring in notes.  It is entirely reasonable to request more information from the company representative setting up the interview.
2. Appear enthusiastic and interested (but not so much that you are confused with a salesperson!).
3. Dress appropriately.  This generally means clean trousers and a shirt with a collar, maybe a tie for the men, a clean skirt and a blouse for the women.
4. Answer the questions, and if you do not know the answer, let the interviewer know with the promise to get back to them.
5. ASK QUESTIONS…find out enough information to determine whether you want to be an employee.
6. Finally, follow up…if you like what you heard during the interview.  Just an e-mail will suffice, and believe me that will set you apart from 90% of the candidates.

As readers know, we’ve been talking about code reviews pretty regularly here and elsewhere over the past few months. To continue that discussion, here’s a question we run into often: are in-person code reviews as the primary way to communicate, by definition a bad thing?

Here’s some more data from the Forrester Consulting study commissioned by Klocwork that shows the majority of respondents still conduct in-person reviews… elsewhere in the survey only 36% of respondents indicated that they worked on a centralized team with everyone in one location. So that means, if 60% still conduct in-person reviews, they’re likely excluding valuable contributors to the review.

Data that shows majority still conduct in-person code reviews

Is this practice just being done because “that’s the way it is” or are there good reasons for in-person meetings being the primary way to review code? I could see the odd in-person meeting being necessary for a variety of reasons but given how distributed teams are these days and the variety of tools available to effectively review code remotely, it doesn’t seem that efficient.

There’s a general philosophy gaining more prominence around meeting reduction, whether in software development or elsewhere. We’re seeing many organizations question why their code review process needs to be in-person when it excludes people who aren’t co-located and generally takes up too much of people’s time. What are you seeing?

Mark Grice is a pretty unflappable guy, but when you ask him a question about barriers to successful adoption of Source Code Analysis (SCA) technology, he starts to splutter.

“There are things I see over and over that make me want to bang my head against a wall,” says the Klocwork Director and Manager of our International Reseller/Partner Network.  For the past nine years, Grice has helped companies from around the world to successfully implement SCA. There are many companies that deploy SCA tools and reap their ROI, but there are others that can’t get to first base.  Below are barriers Grice has consistently encountered from a persistent minority. Here are 7 sure-fire ways to ensure that your organization will fail at SCA:

1. Make sure your SCA tool evaluation process is long and costly.
   “I’ve seen companies spend three years in the analysis phase, involving a number of key staff,” Grice  says. His advice? “Buy them all and just start using them. At least you’ll have spent three years producing better code instead of just testing and evaluating.” Or, just buy one and start using it. If it doesn’t do everything you want it to, buy another one.
2. Cling to your tool-selection criteria to the point of impotence.
   “I’ve seen companies not buy a tool because they couldn’t check off one requirement out of 100.  It didn’t matter that the other 99 criteria were met,“ Grice says.  Often, these checklists eliminate every tool.  These companies opt to do nothing rather than something about their code quality.
3. Insist that one tool must do everything.
   No one tool will do everything. Buy a couple of them.  “If I’m working on a construction project and I need to drive some nails and cut some wood, I’m going to go and buy a hammer and a saw.” What? There’s no such thing as a sammer (or a haw) for both those tasks?
4. Focus solely on the number of false positives the tools throw.
   “A zero false-positive rate is ridiculous,” Grice says.  A very low false positive rate is often tied to a higher false negative rate. It’s easier to manage false positives than false negatives, particularly since the latter rear their ugly mugs after your product is shipped, he says.  If a tool is tunable and customizable, you can just filter or turn off the defect types that don’t interest you.
5. Denial:  You don’t have to fix problems if you don’t find them.
   “Gack!” Grice has to do deep breathing to get through this one. “If you don’t want to find anything, then don’t test! I mean, jeez!”
6. Have a persecution complex: Management will use the information against us.
   Developers sometimes worry that they’ll be ranked by number of defects per lines of code. But if you’re finding and fixing defects before you check in, your numbers will actually improve. “I’ve seen one team resist the SCA tool because they were at the top of their game. Then that team saw their ranking fall because teams using the SCA tool made consistent quality gains with every build and then caught up and then surpassed them,” Grice says.
7. Make non-development staff responsible for rolling out the SCA tools.
   “I know we’re in for it when the prime asks, ‘What’s a build?’ or ‘What’s make?’”
   To successfully roll out, Grice says, you need a code expert–someone who really understands your build process, the development environments and how to evaluate the findings.

And there you have it—your SCA-failure habits. We’ll end here because Grice has to go and get his  blood pressure checked.

As a followup to the False False Positive discussion previously, I was included in a discussion between a customer and one of our sales engineers and thought that it was a great general example of how a source code analysis engine  is really reporting on memory allocation problems where most developers would dismiss it.

Here is the initial inquiry and response:

I’m hoping I can get your comments on the CL.FFM checker. Does this check just catch a situation where the destructor will free memory that may not exist, because the assignment operator never allocated any?   Seems like if it is allocated in the  Constructor, then no worries.  But I suspect this is catching something subtle.  Do you have any other examples that can clarify what it is catching?

CL.FFM notifies you of the potential for freeing already freed memory (FFM). And yes, it’s catching something far more subtle. Here’s a code snippet from our help wiki to use as a reference for what follows:

Example:

1   class CData
2   {
3   public:
4     CData(const char* buffer, int type) : m_type(type)
5     {
6       if( (type > 0) && buffer )
7       {
8           m_data = new char[strlen(buffer) + 1];
9           strcpy(m_data, buffer);
10      }
11      else
12      {
13          m_data = new char[1];
14          m_data[0] = 0;
15      }
16    }
17
18    virtual ~CData()
19    {
20      delete[] m_data;
21    }
22
23    CData(const CData& rhs) : m_type(rhs.m_type)
24    {
25      // No error here, as the copy constructor performs a deep copy
26      if( m_data ) delete[] m_data;
27      m_data = new char[strlen(rhs.m_data) + 1];
29      strcpy(m_data, rhs.m_data);
30    }
31
32    const CData& operator=(const CData& rhs)
33    {
34      // Shallow copy here, no explicit assignment to 'm_data'
35      m_type = rhs.m_type;
36      return *this;
37    }
38
39  private:
40    char* m_data;
41    int   m_type;
42  };

Sometimes it’s easier to think of a C++ class as a structure (for the data elements) and some associated code (the methods). When you do an assignment or a copy, the underlying code makes a ‘memcpy’ of the structure first (it may not actually be ‘memcpy’ but the code has the same effect) and then it applies any applicable assignment or copy methods.

Say we construct an initial instance of CData and call it ‘object1’. In memory, we have a structure with 2 data elements where the element ‘m_data’ is a pointer to some dynamically allocated memory that contains some string data (see the constructor for CData ). Then I declare another instance of CData and call it ‘object2’ and I code this:

CData object2 = object1;

This will go through the ‘=’ operator and (essentially) give me 2 structures of CData. BUT both will have a pointer for ‘m_data’ that points to 1 (and only 1) dynamically allocated memory buffer. What should have happened is that the ‘=’ operator should have dynamically allocated a new ‘m_data’ (for ‘object2’) and ‘memcpy’d the text from ‘object1->m_data’ into the new ‘object2->m_data’ – but the code doesn’t do this, and this is what we’re looking for. In essence, this is the classic ‘shallow’ versus ‘deep’ copy issue that C++ has.

Now things start to get weird. With both objects still ‘in-scope’, any change to ‘->m_data’ for either object will cause the change to appear in both objects (because it’s the same physical memory that each point to). If the app is multi-threaded, you could even have synchronization issues.

At the point that one of the objects goes ‘out-of-scope’ and gets destroyed, the destructor will ‘free’ the memory behind ‘->m_data’. But the other object is still pointing to it, so you will get access to freed memory for any reference to it by the surviving object. This is bad, but probably on the low end of “bad” until the memory is reallocated to something else. Then it gets really crazy, because you now have 2 unrelated things reading/writing from/into the same space.

At the point when the surviving object goes ‘out-of-scope’, you’ll end up with a double ‘free’ and probably corrupt the entire dynamic allocation heap. And, if it’s been reallocated already, then you’ll have additional corruption spreading into other parts of the application. This becomes the high end of “bad”.

This is very subtle, but it’s nasty because it’s very difficult to spot and fix. In the field, it tends to manifest as strange behavior that can’t be recreated. If you bring multi-core/multi-threading into the picture, then it can also become the classic timing problem that’s nearly impossible to pin down and fix.

CL.FFM looks for the dynamic allocation situation and an ‘=’ (assignment) method that doesn’t contain enough support for a ‘deep’ copy. CL.FFM.ASSIGN looks for the same situation, but in this case, you haven’t even coded an ‘=’ method (so a ‘shallow’ copy is now guaranteed). CL.FFM.COPY looks for the same situation, but you haven’t even coded a ‘copy’ method (and again, a ‘shallow’ copy is guaranteed).

I like developers.

I have spent a career hiring, motivating, confusing, annoying and retaining developers.  I am not going to go so far as to say I understand you guys, but I do know what makes a good developer.  More importantly, I know what makes someone a bad fit for the team I am recruiting for.

First impressions are important. Yeah, I know, it sucks and your technical prowess should speak for itself, but it doesn’t.  Let’s face it, if you forget the “L” in Klocwork in your cover letter, I’m laughing too hard to pay attention to your superior coding skills.

If you continually refer to me as “Sir”, my feminist nose gets a bit out of joint; resumes filled with spelling errors throw into question your attention to detail and your level of concern for putting forth solid code.

While I am on the subject of resumes, it’s very impressive that people have the experience to fill up 15 pages of a resume. Maybe it’s even impressive that they have the time to type out a 15-page resume, but no one else has the time or the inclination to read a 15-page resume.  To date, the record length for a resume that I have received is 25 pages – this person is not employed here.

Being in this industry and in HR for as long as I have, I have learned something shocking – people stretch the truth on their resumes!  Imagine that!  And then imagine a company having the audacity to have someone in for an interview and test the person to assess whether what they claim on their resume is actually the case.  Of course, as a candidate, you should then take great offense to the fact that my colleagues and I called into question your integrity, your intelligence, and your worth as a citizen of the world.  In fact, you should probably follow up your interview with a strongly worded e-mail addressed to Sir at Kocwork.  Or maybe you shouldn’t.

Just…don’t…do…that.   We are not attacking your credibility. We do not enter the interview room thinking you are a lying, worthless waste of skin. In fact, we are pretty excited to meet you, so far we have liked what we have seen, otherwise you would not be here.

We will remain excited to meet you, right up to the point where you show up half an hour late, wearing a questionable outfit covered with what appears to be last week’s Sunday dinner.  Maybe you will look me in the eye, or maybe you will direct your eyes to my chest and keep them fixed there throughout the interview.  When that happens I like to observe where your eyes remain clamped when my male coworkers are interviewing you because inevitably it has nothing to do with what is on the interviewer’s chest. It’s just a convenient place to rest one’s gaze.  However,  between you and me, it kinda freaks me out.

I found this blog to be rather cathartic. I have more, so much more and if I am invited back as a guest blogger, maybe my therapy bills will go down.  Until we meet across a table in our interview room, I wish you good luck and good code!

In the spirit of the FIFA 2010 World Cup, I thought it would be fitting to describe how software developers can relate to the game.

1. Announcers – Have you ever really listened to what the announcers say?  One of my favorite things to listen to is the very opinionated soccer announcers.  Some of the things they say just make me laugh.  For example, when the announcer was describing the uncertainty of the game – “There’s one thing for certain, there is no score.”  or in this year’s World Cup describing a slow and boring game – “It’s like they are playing in slow motion”.  I’m not saying developers are opinionated…no way ;).  One thing that is similar is the comments developers will put in the code.  One of my favorites:

//When I wrote this, only God and I understood what I was doing
//Now, God only knows

For more funny comments go here.

2. Money – Soccer players do what they love for vast amounts of money.  Developers do what they love…well okay maybe not the second part.




3. Vuvuzelas – whether you like them or not you are stuck with listening to hundreds of Vuvuzelas playing their merry tune.  Despite all the complaints it will continue to haunt spectators until the tournament ends.  So why is everyone blowing the god forsaken plastic tubes?  Well my first guess is that they are drunk, but I think mostly because it is fun.  So as a software developer you don’t get to blow on the vuvuzela but I bet you would want to when you finished your work or the latest complicated feature?  Hopefully this is not because you’re currently drunk.




4. The thumbs up – In a meeting I had with our customer advisory board there was one individual who kept giving the thumbs up.  I understood that he was voicing his agreement with what we were talking about but I never understood why it was always with the thumbs up…until the World Cup started.  Seems to be the universal sign for the soccer players to say “nice ball” or “good play”.




5. Drama – Have you ever noticed how the majority of soccer players act when they have been fouled?  They dive 10 feet in the air, roll 16 times and clutch their chest like they were just shot.  Okay maybe I’m exaggerating a little but the point here is that some of these players are under the impression that they may get nominated for the next Academy award.  How does this relate to the software developer?  Well think of the code review, who really likes hearing that their baby is ugly?

With the recent story that the iPad has inherent security vulnerabilities, I thought it might be an appropriate time to delve into the world of software security guidelines…but I must warn you, this blog will contain an abnormal amount of acronyms, and may not be suitable for all audiences.

When talking about software security guidelines, there are really 5 or 6 organizations that are leading the charge, and they include:

-          OWASP

-          SANS Institute

-          MITRE

-          PCI Security Standards Council

-          SEI

Let’s first look at OWASP. OWASP stands for Open Web Application Security Project, which is a not-for-profit charitable organization that is focused on improving the security of application software. They are probably best known for their Top 10 lists from 2004, 2007, and most recently 2010.

Next is the SANS Institute. SANS of course is a FLA that stands for SysAdmin, Audit, Networking, Security. The SANS Institute claims to be the most trusted source for computer security training, certification and research, and have been developing and releasing their Top 20 annually for the past 7 years or so.

The MITRE Corporation is a not-for-profit organization that was founded in the late 50’s, and has over 7,000 very smart dudes (65% have Masters or PhDs). MITRE has come up with their own security guideline as well, that is the CWE (Common Weakness Enumeration) and it provides a common language of discourse for discussing, finding and dealing with the causes of software security vulnerabilities as they are found in code, design, or system architecture. The CWE lists over 800 programming errors, design errors, and architectural errors that can lead to exploitable vulnerabilities. Interestingly, MITRE and SANS decided to collaborate to come up with the CWE Top 25, yet another “Top” list they have been putting together for the last couple of years.

The PCI Security Standards Council was founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa, Inc. and is an open global forum for the ongoing development, enhancement, storage, dissemination and implementation of security standards for account data protection. The PCI SSC has come up with the PCI DSS, “a multifaceted security standard that includes requirements for security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect customer account data”.

Finally, there is the SEI (the Software Engineering Institute, which is a federally funded R&D center at CMU, aka Carnegie Mellon University). The SEI is home to CERT which was established in 1988 to address internet security problems and to find ways to reduce the number and impact of security breaches. CERT focuses on protection, detection, and response to attacks on networked computer systems. Surprisingly enough, CERT is not actually an acronym.

Neither PCI nor CERT has received the memo yet that in order to be cool, you have to have a “Top X” list…perhaps next year?

Now, not to be left out of the fun, the NCSD (National Cyber Security Division) of the DHS (Department of Homeland Security) has their own strategic initiative called BSI (Build Security In). The NCSD obviously wants to cover pretty much all the bases since, in addition to their own BSI, they also sponsor pretty much all of the other guidelines.

I would be remiss if I didn’t at least acknowledge a few other notables with respect to software security guidelines, and to make it more interesting, I will only provide the acronym. I challenge you to come up with the full name. So, a few others involved in security guidelines are NIST (who run a project called SAMATE, and also run an event called SATE, which BTW is also sponsored by DHS NCSD), WASC, and finally STIG. For fun, I’ll throw in CVE, even though it is not a guideline, but more of a dictionary or list that was put together by MITRE, and shockingly is sponsored by DHS NCSD. I’m starting to think that DHS wants to be everyone’s BFF.

Hopefully you’ve learned a little more about the alphabet soup of security guidelines out there. If you’re scratching your head thinking WTF, you’re probably not alone…

By the time users hit the help documentation, they’re already snarly. Yeah, some people read the documentation first before using the tool, but…

A lot of people just want to dive in and start using the tool. And when I’m stuck I want answers. Now, already!  You might think it’s stupid-user error and I might think it’s stupid software design, but who cares? I want help right NOW.

Troubleshooting information lives or dies by the search-and-I-better-frickin-find-what-I’m-looking-for mentality. How do we look for this help? We copy and paste error messages into a browser and search.

When my ideas about organizing  troubleshooting information compete with how Google finds stuff, Search Engine Optimization (SEO) carries the day.  Or at least it should. Of course, there are SEO factors that put help documentation at a disadvantage, but that’s another topic for another day and I’ll let Tom Johnson do the talking on that one.

What does this mean for me, a technical writer?

Well, if two (or 5) of our tools throw the same error message, I’m going to have one page for each error message and have instructions on that page that explain how to fix it in each tool. Yeah, it’s nice to have tool-specific help information, but Google gives more weight to page titles and URLs. For good measure, I’m going to repeat the error message in the body of the page and format it in bold or italics.

Sarah Maddox highlights elements of what makes a good error message (including some hilarious examples of bad ones), so no need for repetition.

Aside from clarity, what do I want in an error message?

Firstly, I’d like to be able to copy and paste it.

Secondly, I’d like the solution to be stated.

As an added bonus, I’d like to be provided with a link in that message that would bring me to the dialog where I can take remedial action. Then, I won’t even have to look for help information. I can just fix it. Here’s an example of one these helpful messages from our Eclipse plug-in:

See? Documentation not required. The solution is outlined, and you can click the link to get to the license dialog, where you can check your host and port information.

Hmmm. Maybe that would put me out of a job. Sergey, please change that message to:

ERROR:FROZEN:BAD LICENSE.

I have a mortgage to pay here.

So a while back, I explored where developers get their information.  Surprisingly, it is hard to find hard data on the subject.  As a bonus from a Forrester study commissioned by Klocwork into the habits of code review, part of  the data revealed developers’ use of social media tools.  When asked directly about their use of these tools to communicate with other developers, the majority polled would not choose a social media channel.

It just goes to show that yet again, software developers are a breed apart.  As an aside, as I was researching this topic, I found an interesting post on why Social Media Experts are poets, Software developers are novelist that delves into ideas on barrier-of-entry as related to quality-perception of creative tasks.

A while back, I talked about how I keep running into organizations that seem to go out of their way to make developers’ lives hell.  I’ve run into several examples where developers had to switch between different environments just to write and compile code.  That’s as productive as watching paint dry and as much fun as rearranging the deck chairs on the Titanic.

For teams that want to run source code analysis in these types of environments (or any kind of dev tooling, frankly)  it’s very difficult for vendors to support.  I did my usual PM grumbling about these environments but since that post exactly 1 year ago I’ve come to realize that these environments are a reality and we need to figure out a way to support them.  Maybe it’s not productive but organizations are making it work.  I’m sure they would even argue that they have made it productive (good luck to them).  It’s for this reason that Klocwork has given in and instead of pointing our finger and making fun (I swear I never did), we’ve decided that it’s in our best interest to make sure we provide these customers with the capability to run static analysis.

A couple of releases ago, Klocwork introduced a new tool called Klocwork Desktop that provides Klocwork command line users with the same graphical capabilities that one would get from Visual Studio or Eclipse.  This tool was great for users who never used an IDE.  With Klocwork’s 9.1 release we have extended Klocwork Desktop’s reach by providing a remote capability that’s designed to support the type of environments described above.  Using Klocwork Desktop in remote mode allows users to view their source and detected-issue information when Klocwork Desktop does not have direct access to source files or defects, yet still get the benefits of finding and fixing your defects before you check-in your code.

One really cool feature that is part of this is the “you’ve got mail” notification.  At first, I have to admit this is something that worried me.  If I had to label one thing as a productivity drain it was those annoying alerts you get of new email coming in.  Of course right in the middle of doing something important you get distracted by a new email with plans for the next party (or in my case hearing about the kids latest poop explosion).  The first thing I always do is turn it off.  But in the case of finding bugs while coding, it only makes sense to give you these notifications in a heartbeat.  So you can actually be writing code on some machine in Jakarta and automatically your machine in San Jose is alerting you of bugs.  Pretty neat stuff.