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.

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!

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…

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.

There’s a tradition in R&D management that goes something like this: “give them toys and they’ll be happy.” Typically this has meant the biggest monitors, or the fastest CPUs, or an egregiously unnecessary SLI GPU configuration (for, ahem, high capacity computation tasks, right…), or whatever the latest piece of hardware might be that catches the purchasing manager’s eye.

But what about the software on that hardware? Sure, we equip people with an IDE (if they’ll use it, or whatever text editor they demand if they won’t) and whatever other tools are mandated as part of their development lifecycle. In fact, typical managers would dearly love to be able to mandate more tools for their developers. It’s easy, after all, for a manager to make the correlation that more toys = happy developer = more productivity = more code = bigger bonus = happy manager.

So why do so many developers, particularly in the embedded space, use outdated software tools? What’s the excuse, after all, for vi or some close derivative being a dominant code editor?

Inverse snobbery has been a popular theme in the privileged parts of the world for much of the last thirty years. “Yes, we drive a Lada because we just don’t believe that a BMW is necessary.” Really? Does anybody actually believe that tripe? I mean, I can well believe “I use vi because I have to; it’s the only editor that works on this cruddy piece of hardware.” But forgive me if I have a hard time with “I use vi because I like it better than anything else.” We all get used to stuff that makes no real sense, but surely there’s a point where even the most inverted technical snob has to look themselves in the mirror and know, deep in their darkest most hidden-away recesses of existential reality, that they’re just full of it.

Intransigence. Inertia. Feet dug in harder than you could possibly shift in a lifetime. Call it what you will, but unless something life-changing, like a project in a new language happens, many developers have a nasty habit of sticking with what they know. “What we do is hard enough,” goes the meme, “we don’t need to make it any worse.”

So how are those same developers coping with the demands of the ever-increasing footprint that is professional development? After all, it’s not enough anymore to simply bang out some code and check it in, moving on to the next assignment and hoping nobody notices. Now the professional developer is tasked with unit testing, performance testing, static analysis, memory profiling, code review, refactoring for maintenance, architectural cohesion, you name it. The list only ever gets longer as we move the goal posts for QA closer and closer to the consumer, requiring the developer to pick up the slack in the interim.

How does that footprint get coverage? There are still the same number of hours in the day, and the required amount of code generated by each developer hasn’t markedly decreased over the last 10 years. So what gives? One thing’s for sure… vi hasn’t made developer productivity much better than when it was first written at Berkley all those years ago (with all due deference to the strides made by vim/gvim in recent years).

I’m going to examine several different communities in upcoming posts and look at the approach they take to solving this problem, covering a range of backgrounds and roles from embedded driver writers to creators of modern web applications. In the meantime, have a look inside yourself and, if you pass muster as some analog of the crusty vi user I paint above, ask yourself why, and what might make you change. Recent history abounds with case studies, some of which I’ll reference, but at the end of the day it’s all about you and your personal work practice.

I just got back from a visit to the Valley and had an awesome week in San Jose/San Fran.  I even had time to play a bit of the tourist this time (I ran the Golden Gate bridge/Presidio).  All that was fun, but what I always enjoy is the conversations we had with customers and prospects at this year’s ESC SJ 2010 conference.

It is always interesting listening to their successes and teasing out the trending topics and new issues that matter to development teams.  Here are the top three themes that caught my ear this year:

1. The economic rebound is well underway, with growth and optimism from every quarter.  It may be too early to see results on the balance sheets, but the positive attitude is back.
2. Embedded developers are searching for enterprise-class developer productivity tools, like static analysis, for even tiny codebases (less than 40 kLOC).
3. By far, the most-often raised topic in one-on-one conversations was coding standards, with MISRA C and C++ as the favorite.  MISRA’s time has definitely arrived for the embedded community.

So all in all, a great time, and looking forward to next year.

As I write this, I’m sitting at the Dallas airport, suffering through a 3 hour delay on my flight to Washington D.C. to present at our 2nd Agile in Action Roadshow with our friends from Electric Cloud, Perforce, and VersionOne. As I have the time, I’ve been reflecting on my time here in Dallas, and the phrase “Everything is big in Texas” is bang on. Before I get to that though, I have to say that I do love Dallas…I’m not totally sure, but I truly believe I’m treated a little more special because of my last name (which I casually mention whenever I get the chance). Nothing like having the same surname as a famous coach from the Dallas Cowboys!

Okay, so why do I think the Everything is big in Texas is accurate. For starters, my big delay is due to a big thunderstorm. My rental car preference is a Compact car, and what do I get? A Yukon…I’m not sure what is bigger, this vehicle, or the Canadian Territory with the same name.

I saw big hair, big hats, big rings, big belt buckles, big omelets, big waffles, and big enchiladas. What I also saw was a big enthusiasm for Agile development. We had a great turnout that was fully engaged from the instant the roadshow began, asking questions wanting to know more, sharing their experiences with others, visiting with the vendors and not leaving until they got the information they needed. I wrote a few weeks ago about Agile adoption and where it currently was, and participating in this event, and speaking with the attendees, it allowed me to gain some additional data points that only strengthened my beliefs on this…Agile is definitely growing, and in all industries. As I said before, I truly believe almost all organizations have some Agile developments teams.

Hopefully the enthusiasm I encountered in Dallas will follow us to Washington D.C. And I’m thinking I may want to introduce myself as Todd Ovechkin…

So awhile back, I was begging for some good statistics on Agile adoption, since at that time, there really wasn’t anything substantial to sink your teeth into. Well, a new report from Forrester came across my desk, and it helped to strengthen what most people believe…that Agile processes have overtaken Waterfall as the development methodology of choice. In this report, which cites information gathered from a Q3 2009 survey of IT professionals, it states that 35% of respondents said that Agile most closely reflected their development process, while waterfall processes came in at 13%. I would even argue that iterative development could possibly be included in the Agile bucket, not because it is full-fledged Agile, but it is a baby-step in Agile’s direction. Perhaps I’m stretching things there…

Secondly, the data supports the fact that people are adopting the aspects of Agile that work for them and there’s no monolithic Agile implementation approach, something that is consistent with the many Agile teams I’ve spoken to over the last 3 ½ years or so. I’d be curious to know how many teams out there are doing , say, Scrum “by the book”…if there is such a thing.

Finally, the other thing that the report hinted at, that I have seen firsthand, is that while most organizations are not completely Agile today, they almost all have some groups that are. I honestly believe that the percentage of organizations that have small pockets of groups doing Agile development is very high…perhaps in the 80s or 90s. I don’t have any hard data on this point, this is more of a gut-feel, but I would be interested to hear from our readers as to what they think.

We are starting to see a large amount of Android phones such as the Droid and Xperia X10 (see a review here) and the (soon-to-be-released) first Google phone, Nexus One. With this, expect the number of apps to increase significantly.

Droid vs. iPhone

So with the increased number of apps, do these developers have the right tools to find and fix bugs? Take a look at the leader of phone applications-iPhone. There have been several posts (here and here) that recommend using the Clang static analyzer. Apple has taken it one step further, apparently rejecting iPhone apps that access private APIs. But Clang won’t help you with Java apps.

So what do the Android developers have? Android is just Java, so there are lots of tools, right? Certainly there are static analysis tools, profilers, unit testing tools and many more. But are these tools really taking into account the Android specifics?

Let’s take an example of a resource leak. Resources such as streams, connections and graphic objects must be explicitly closed; otherwise, you run the risk of throwing exceptions depending on the open resource.




For example:

1 static final String propertyFile = "my_config.ini";
2
3 static String getProperyFromConfigFile(String name)throws IOException {
4    Properties prop = new Properties();
5    FileInputStream st = new FileInputStream(propertyFile);
6    prop.load(st);
7    return prop.getProperty(name);
8 }

Here, a resource leak should be identified since line 5 opens up a FileInputStream, but is never closed before exiting the method. Now, this is all well and good and valuable to be found in any Android specific code, but what happens if I’m using built-in classes from the Android SDK?

For example:

1 public boolean onKeyDown(final int keyCode, final KeyEvent event) {
2    if (keyCode == KeyEvent.KEYCODE_DPAD_CENTER) {
3          final MediaPlayer player = MediaPlayer.create(this, ringtoneUri);
4          player.start();
5    }
6    return super.onKeyDown(keyCode, event);
7 }

Here, you have a situation where a MediaPlayer resource is created at line 3, but never closed on exit. Without the knowledge that MediaPlayer is a resource that should be closed, you will miss this type of issue. This extends to many resources and different issues. You can also have Android-specific null pointer exceptions and use of free issues.

Let me know if you’re doing Android development. I want to hear what you are doing to find these kinds of bugs.

Thought I would take a moment to share with you my experience at this year’s IP ESC show in Grenoble, France. First off, Grenoble is beautiful sitting at the foot of the French Alps. If you get the chance, go!

Back to the show. This is typically the IP Show, but this year is the first that ESC has been added to the agenda. I don’t think it helped attendance-wise. From what I can tell, there are maybe 200-250 attendees in total. I spent the last couple of days sharing booth duty with our friends from Emenda, France. Today, I spoke about how source code analysis fits into Agile development teams. I had about 15 attendees, which by all accounts was a good turnout.

I was able to cram about 40 minutes of material into 20-minute slot, and even had time left over to answer a few questions. Unfortunately, this show did not allow Exhibitors to attend any of the sessions. Too bad really, I was hoping to attend a few of them.

Next week, I am off to a similar show in Stuttgart, Germany, where I will have more time to present. Check back here next week for a recap of that event.