Letters – Eric F. Savage

December 26, 2006

The Honorable George W. Bush
President of the United States
The White House
1600 Pennsylvania Avenue NW
Washington, DC 20500

Dear Mr. President,

I hope the holidays find you well, and wish you happy and productive new year.

I am not an expert on the topic of voting, nor am I a professional security expert, but I do try and follow the news with regards to the intersection of the two. I watched the HBO documentary “Hacking Democracy” this weekend while wrapping presents, and was flat-out disgusted. It was not especially well-made, made no attempt at being objective, nor was most of its information news to me, but I was moved when I watched a mock election be rigged using actual voting systems and saw a real, respected election official be speechless and dumbfounded that his job was completely undermined.

There is no simple solution to secure voting, nor is it remotely probable that any election will ever be 100.0% honest, but there are some monumentally obvious flaws in the way we currently count votes. The largest is the issue of the lack of openness of the software, systems, and processes that are involved.

I am a software developer and most non-programmers I’ve talked to have a difficult time understanding the idea that public access to the “secret codes” of software, AKA the source code, is more secure than private or closed source code. The general opinion is that if you can see the inner workings of something, it’s easier to break it, which is valid and true. The next step in this thought process, however, is more critical and is one that most people don’t take. That is that if you cannot see the inner workings of something that is broken, it’s more difficult to fix it.

The idea of “security by obscurity”, sometimes referred to as “obsecurity”, is valid and necessary when it comes to information such as private financial data, personal information like medical histories, and intelligence gathered by our military and other government agencies. However, regarding mechanisms and processes, such as software, obscurity lessens security. This is doubly true when those mechanisms are designed to collect and analyze public data, such as votes.

Here’s a dirty secret of the programming craft: 99.9999% of software is broken. By broken I mean there is some bug somewhere in it. In new or rarely used software these bugs can be serious and misleading. In most mature software, it’s nothing serious; something doesn’t display right, some obscure error condition is handled poorly, etc. This applies to video games, email programs, ATM software, Windows, Linux, etc. as well as voting software.

So how do you weed out these bugs? You test, over and over and over again. When you find a bug, you test again, even things that you didn’t fix (AKA regression testing). Eventually, you’ve fixed all or most of the bugs that were found, satisfied your unit tests and requirements, and you ship it. Then your customer does something you never planned on, maybe because they are being silly or stupid, or you aren’t the programming god you thought you were, or your QA staff is overworked, or it just wasn’t possible for you to test in the lab. This is why you get Windows updates every week, and why there are dozens of bug fixes for every Linux kernel, patches for every video game, it’s simply unavoidable. The more something is used, the more bugs are found, and the better it becomes.

Voting software isn’t used very much. Most machines are used one day every year or two. Excel has been used by millions of people every day for nearly 20 years, and there are still bugs in it. If I’m making an inventory of my baseball cards and have a problem with Excel I can report it to Microsoft and hopefully a ticket will be opened and hopefully they will fix it. The difference between a spreadsheet package and a voting system is that my grandfathers didn’t risk their lives overseas to make sure “=SUM(D3:D13)” was accurate, they did it so that I would grow up in a better world than they did, and just as importantly, have the power to make it better for my grandkids.

It is absolutely imperative that we apply the highest possible standards of scrutiny, security, and integrity to the systems that facilitate our most sacred public right. Voting software, hardware, and system should not only be open, they should be the zenith of openness. The public should be able to download complete specifications for every piece of hardware on every type of voting machine out there, from the device I vote on to the system that tabulates it to the printers that make the reports. We should have access to every line of code used in the entire process. I should be able to test it myself and find flaws or solicit advice from those I trust. The public should have as much access to the hardware as is feasible. Regular citizens, universities and vendors should be encouraged with bounties to find and report flaws they find. Defect reports on voting systems should be legal documents, also open to review by all. There should be digitally signed video publicly viewable via live broadcast or within hours of all access to every machine with the sole exception of the person casting a ballot. There is room for only ONE secret in this entire process, and that is who an individual voted for.

I would be exceptionally pleased if you would propose or support legislation to help protect our votes by virtue of an open and honest process. It would not only validate the sacrifices millions of Americans have already made, but it would set an example that other democracies and future generations will aspire to.

Sincerely,

Eric F. Savage

Also sent to my Senators Kennedy and Kerry, Representative Frank, Governor-Elect Patrick, State Senators Brown and Creem and Secretary of the Commonwealth Galvin. If you feel similarly I encourage you do write to your officials and feel free to borrow or copy from my letter.

For more, better information on this topic I recommend checking out Ben Adida’s Blog and Black Box Voting. A web search for ‘secure voting’ or similar topics will also turn up piles of other opinions and (often scary) facts.

Dear Recruiter/ Staffing Specialist/ Hiring Manager/ Headhunter/ HR Ninja,

Nobody's calling :( As you likely know all too well, the job market is red hot for developers right now. Getting a good senior developer to even return your calls is a challenge. You offer competitive salaries, have a nice benefits package, flexible schedules and relaxed dress codes. You’re doing everything you can, and the only responses you’re getting to your job listings are dummies and spammers. So what are you doing wrong? Well, I don’t have the complete answer, as I too am having trouble finding people, but I’d like to offer advice on one area, your job listing.

99% of developer job listings seem to look like this (this is a slightly edited actual job listing):

Description:
Super Recruiter Staffers has partnered with a progressive e-business and marketing company in Smallville, KS, and is seeking a motivated and experienced Java Software Engineer.

The successful candidate will bring a solid understanding of J2EE to an experienced development team with a strong technology background.
Responsibilities:

Analyze, design, and implement Java and Java EE based software applications

Participate in all parts of the development life cycle

Responsible for the complete life cycle development of major components and sub-systems

Leverage past development experience

Requirements:

Required Skills/Background:

BS degree in Computer Science

2 years hands-on Java EE design and development experience in a professional capacity.

Experience with the following Java EE technologies; EJB, servlets, JMS, and JDBC

Proven experience with JSP, Struts, JDO, JPA, and Spring.

Proven experience using application server environments to build enterprise level multi-tiered applications

Proven experience architecting n-tier applications (Oracle 10gas preferred)

Excellent object-oriented analysis and development skills

Working knowledge of UML, XML, Ant

Self-starter with the ability to work both independently and as part of a team.

Ability to manage multiple priorities effectively

Excellent verbal and written communication skills

Other desired skills include:

Experience in performance tuning, load testing, deployments, and QA

Experience with full software development life cycle including functional & technical specification, documentation, QA processes, source control (CVS), maintenance, and deployments

Experience with Oracle 10g

Experience developing software for manufacturing industry

If you feel that you have the above qualifications and are interested in discussing this opportunity further, please apply today!

What’s wrong what that?, you ask. A lot, I say. Here’s what you’ve told me:

It’s a poorly defined position.

You listed a bunch of Java technologies, some of which I’ve used, some which I haven’t. It’s unlikely that all of these are needed, because you’ve listed typically opposing approaches like EJB & Spring, Struts & Servlets, etc. These can co-exist for sure, and maybe it’s part of a migration, but your shotgun approach isn’t tell me much. Also, you want “proven experience” in a technology that is brand new (JPA). I remember seeing job listings back in 2000 for people with “10+ years of Java development” (it had only been out for 5 years).

You aren’t being very honest.

You say that a BS in computer science is required. Of course it isn’t. Very few of the best developers I know have CS degrees. I’ve worked with people who had degrees in everything from Library Sciences to French to Math. If it’s not required, don’t say it is. What you really mean is “preferred”, but even that’s questionable. What this really tells me is that you just copy-and-pasted a boilerplate description and you’re not trying very hard, so why should I?

You want a Super Genius.

You want 2 years minimum experience. You also want someone who has “proven experience” in a wide array of technologies and can architect “enterprise level multi-tiered applications”. If you’re interviewing people with 2 years experience to architect enterprise software, you’re in trouble. And if you’re interviewing architects for a job that someone with 2 years of experience can do, you’re wasting everyone’s time.

I’d be part of a team of indeterminate size.

So I’d be part of a team, that’s valuable information, but it’s not nearly enough for me to gain specific interest. A small, agile, team? A large, influential team? What’s the purpose of the team? What department are they in? How many projects do they work on? Will I be a senior member or a rookie?

I’d be working for a company that does something, somewhere.

I’m either working for a manufacturing company, or for a company who has a manufacturing company for a client. That’s a fairly large distinction right there, and even if you answered that there’s other questions. What kind of manufacturing? Do they make DVD players or cinder blocks? If it’s a consulting firm, what else do they do? How big is this company? How long have they been around? Are they public?

How to fix it

Tell me exactly what you need done.

There are generally three types of hires:

You need to staff an existing or upcoming project.If this is the case, describe the project. This includes the team, the client, the goals, the timeline. “A new team building an e-commerce site for a Fortune 500 client” or “A small team developing a new medical billing product line for small practices”. I’ve worked on many types of projects for many types of clients, and I know what I like. If you hit some of my favorable notes, you’re much more likely to hear from me.
You want to grow your technology staff.For this one, tell me what I might be working on long-term. “We want to grow our retail software practice” or “We want someone to evangelize semantic web technology internally and to our clients” are good starts.
You need someone right now for a project, and you want a long term growth.This one is probably the most common, and is simply a combination of the previous two. Be as specific as you can, and if you can’t because it’s wide-open after the current project, say so.

Talk to the people this new hire will be working with.

You probably got your job description from a VP or director, with some input from a middle manager or two. Ask these people who they currently have that they want more of. Then go and interview these people. Developers generally abhor meetings and organizational details, but if they see their input having a direct effect on who they have to work with or for, I would bet they will be more helpful than you suspect.

Tell me about the company.

With so many choices out there, people can be very selective about who they want to sell a few years of their life to. The more companies that are hiring, the more info you should be giving. Is the company growing? How fast? Are there multiple offices? Do you keep pace with the market or exceed it? Do you invest in R&D? Is your organizational structure flat or deep? How long do people stay with the company? You don’t need to point out the flaws, but every strength you highlight is more bait on your hook.

This is just the beginning. The market is very competitive and the competition is very weak. Improving your ability to get people to answer your calls is not only valuable, but it’s really not that hard.