I posted about a year ago on my doubts about offering employee referrals. I’ve seen them badly abused before where a single employee made 20k+ on referrals many of which turned out to be less than great hires. Apparently Joel who spends a lot of time thinking about how to hire the smartest programmers has a similar opinion:

But the real problem with employee referrals is what happens when recruiting managers with a rudimentary understanding of economics decide to offer cash bonuses for these referrals. This is quite common. The rationale goes like this: it can cost $30,000 to $50,000 to hire someone good through a headhunter or outside recruiter. If we can pay our employees, say, a $5000 bonus for every hire they bring in, or maybe an expensive sports car for every 10 referrals, or whatever, think how much money that will save? And $5000 sounds like a fortune to a salaried employee, because it is. So this sounds like a win-win all-around kind of situation.

The trouble is that suddenly you can see the little gears turning, and employees start dragging in everyone they can think of for interviews, and they have a real strong incentive to get these people hired, so they coach them for the interview, and Quiet Conversations are held in conference rooms with the interviewers, and suddenly your entire workforce is trying to get you to hire someone’s useless college roommate.

And I will admit I have gotten two referral rewards at past companies. In both cases I referred in really good hard working programmers who helped make the companies successful. In one case I split the referral bonus with one employee and in the other I just had HR turn over the whole referral bonus to the employee. The point is you want to work with smart people who are going to help the company, not refer in any old acquaintance who might make a decent employee.

I’m digging into Software Security: Building Security in by Gary McGraw and I came across a strong opinion on C and C++:

If you are concerned about buffer overflow problems and other basic software security bugs, don’t use C. If you must use C, use a source code security scanner. By the way C++ is even worse than C from a security perspective. C++ is C with an object model crammed halfway down its throat.

Ouch.

During a short conversation with our new Chief Security Officer he explained:

If we can certify that we have a secure software development life-cycle we stand to increase our overall revenue with clients from 10-20%.

Wow, actually utilizing our methodology as a competitive advantage. Typically if I mention methodology to anyone on the business side and many on the IT side they sort of shake their head no, never heard of XP or RUP. Indirectly it has a big impact on our ability to deliver and maintain applications, but it’s far from a direct revenue generator.

Over the next year we’ll be looking at adopting some practices, getting some training, and further integrating our QA and development teams. Many of the Agile practices we’re adopting parallel with established practices for improving application security. Thus unit, integration, and acceptance tests and their automation mean you can actually certify that you’re software is reasonably secure at least for what you’re testing for. Automated builds and code reviews mean no issues lay undiscovered for long. This also means QA will probably have to get involved at the coding and scripting level rather than their current pure UI testing and automated scripting against that UI.

Scrum and its 30 day Sprints allow us to inspect and adapt quickly instead of approaching security as an after thought that we find out when a security firm busts and application with a penetration test. And adding things like abuse use cases to our requirements make it clear how we can verify we’re ‘done-done’ with some particular feature.

If you take a non-paranoid approach to implementing better security you can actually stand up at a company meeting and explain how your software process improvement project delivered 100 million for the company. Not bad.

One way of organizing technical work on projects is to have a tech lead who architects the solution and divvies out the work. This is a high risk model often found on classic waterfall projects. Often the tech lead saves all the complex or interesting parts of the code and has the rest of the developers do the GUI or some supposedly less complex area of the code. This leads to:

• Less than motivated developers since they know they’re not trusted with the ‘real’ coding.
• No real way to speed up the project since things can only go as fast as the tech lead.
• Little mentoring since the tech lead is to busy coding to get others up to speed.
• At the end of the project very little improvement of the team for the next project.

I’ve seen this hierarchical model fail many times. The only time it appears to work when the project is small enough that the tech lead can pull off the superman role and code practically the whole app on their own. While common on waterfall projects, I’ve even seen this on Agile projects where the lead developer asks for less developers on the project because they don’t have enough coding tasks they want to give up.

Random trivia, but it turns out that the Google Mini uses special screws to keep you from opening up their box. Administration is purely through a web console. Our Unix sysadmins are a bit ticked about it, but heck it’s an appliance.