Thoughts on Process

Process sucks.

One of the things I’ve learned about process is that it tends to grow exponentially with the size of an organization. I’ve also learned that beyond its optimal point, process directly hinders productivity. Because of this, productivity tends to only increase logarithmically as a function of group size.

This is not a new observation. It is probably most famously studied in The Mythical Man-Month. Increasing manpower produces diminishing returns because work cannot be perfectly parallelized; and even when it can, communication lines increase and introduce overhead. What really drove it home for me was working the full gamut of companies – from the 3 man startup to the largest software company in the world.

The organizations that do the worst tend to be the ones that have far too much process given their size. Sometimes this is a result of a smaller group operating within the context of a larger company (and often adopting process as a top-down mandate). Sometimes it is a smaller company pretending to be a larger company (and thus gaining all the disadvantages but none of the advantages of a big company). However it happened, process often intended to increase productivity or decrease risk has the opposite effect – either hindering productivity, or increasing schedule risk.

There are also the rare organizations that have too little process given their size. These organizations increase the likelihood of catastrophic failure (and leadership either massively magnifies or mitigates this risk), and actually see decreases in productivity as a result of constant error-correcting. My conclusion is that this is a real threat, but it is mostly outweighed by the threat of too much process: death by stagnation and suppression of productivity.

Process, then, is really about tradeoffs: lean towards safety with more, or increase risk with less of it? Introducing much-needed process almost always results in better productivity. But it would appear that leaning towards less process instead of over-prescribing it reaps the largest rewards. This is, of course, domain-specific: we do not want medical or air traffic control systems built “agile.” But why exactly does process hinder us so much?

When code is free and software is paid for in human hours, time is the most expensive luxury. Every moment spent on formalities and overhead is time not spent executing. And if an engineer spends 1/4 of his time doing stuff other than coding, he doesn’t operate at 3/4 capacity – he operates at far less. This is not only because process always inevitably spills over into time it was never meant to occupy, but because it also distracts from real work by taking up mindshare. Adding tasks generates context switches for programmers, which is basically the most terrible thing you can do for productivity. In addition, process is often introduced top-down to benefit managers, who don’t fully appreciate the costs borne by individual contributors.

Because of this, naively adding up the time spent in overhead instead of coding makes it easy to underestimate the effect that process has on productivity. So whenever we add new process and observe the amazing new productivity it has enabled and the risk it has lowered, we often fail to account for the real total cost of it. Routinely underestimating the costs of process and overestimating its benefits causes most organizations to drift towards performing suboptimally by having too much process overhead. It’s a foregone conclusion.

These effects need to be consciously resisted: when you introduce process, account for its inevitable hidden time cost. Perhaps use the same principle that experienced schedulers apply to software scheduling: just add 20 or 40 percent to your best guess (depending on team experience and product maturity), and that’s roughly where you’ll land. Resist process and make it come from the bottom-up, where the people implementing it have the best information about its cost-benefit analysis.

The Teamwork Myth

During my college years, I was constantly being bombarded by the message that teamwork skills were going to be essential in the Real World. This is true, but this idea was uniformly misapplied in the classroom. Many courses that were superficially about learning technical things like data structures or operating systems turned into an exercise in herding cats and dealing with people who couldn’t tell an algorithm from their ass. I’m sure that many other competent programmers before me and after me will have to deal with the same. This is sad because this teamwork “curriculum” is based on a lie. Continue reading “The Teamwork Myth”

There's no Magic Setting to Increase Adsense Earnings

Browsing the various SEO forums you will come across the wackiest and most incorrect advice you’ll find anywhere. Most of these are pure theories or oft-repeated “common knowledge” that turns out to be baseless conjecture. Still more have an air of pseudo-scientific evidence, often based on a single sample and with no controls for the hundreds of variables that can affect earnings from day to day. Some of these include: The day of week, the day of month, advertising budgets, the economy, the news, the time of year, the price of gas, the weather, inbound or outbound links… Continue reading “There's no Magic Setting to Increase Adsense Earnings”

IBM Software Engineer Interview Questions

Here is a dump of some questions from an IBM software engineer interview.

Note, these questions are mostly behavioral, and are geared towards a student who will or has recently graduated from school. Copious notes are taken during this process.

Whether these should be questions of import in a software engineer interview, I will leave for another time.
Continue reading “IBM Software Engineer Interview Questions”

The Amazon SDE Interview

Amazon recruited on campus at UMass over last fall and I was lucky enough to snag a spot after running into them at the career fair. The rep at the table quizzed me on some generic stuff, recording my answers (what is the algorithmic complexity of the best comparison sort?) on the back of my resume.

The interviews are done over several days by 4 interviewers on campus. Each one lasts about 45 minutes. In the first interview, I am randomly assigned to one of the interviewers. I was not asked very challenging questions, but we briefly went over my resume and he described his engineering department and product. Continue reading “The Amazon SDE Interview”

Ruby: Too Smart for its own Good

A few years ago when I was learning rails, I sounded off that Ruby’s lax policy surrounding parentheses was a problem. Specifically, that it is impossible to tell the difference between a method call and a variable reference. There is now an open bug against Ruby 1.9.1 at that demonstrates the problem. Continue reading “Ruby: Too Smart for its own Good”

User-Agent is not a Security Feature

Using a user-agent string to prevent session hijacking is roughly equivalent to a stupidity test. “Hello, I see you’re trying to hijack a session there. Why don’t you prove to me you can supply the target’s UA string?”

Session hijacking is particularly useful for hackers because anyone with a familiarity with protocol understands that login credentials can’t be sent in the clear. So devs and ops work SSL into their login pages and call it a day, providing a false sense of security even though the next page request after logging in can compromise the entire session. Oops. Continue reading “User-Agent is not a Security Feature”

Virtualization is Bad for Database Integrity

One of the lessons about Amazon’s cloud failure last week is that the cloud is incredibly overhyped. The cloud doesn’t necessarily deliver a lot of the things implicitly promised – such as improved uptime or reliability, or even cost savings. But the real problem with the cloud is that you actually get less database reliability than proper hardware. This is because each layer of indirection introduces an additional unknown that must be accounted for. Continue reading “Virtualization is Bad for Database Integrity”

Things you didn't know about Java

Java — and in a more general sense — the garbage collector is partly responsible for the huge productivity gains in the past several decades as development moved increasingly to memory-managed environments. This has come at a cost, with less attention paid to the amount of memory consumed in such environments. Continue reading “Things you didn't know about Java”

The Microsoft SDE Interview

This is the first of several interviews from fall of 2010 that I will document.

The Microsoft Software Development Engineer Interview is hard. While no interview process is perfect, they do a lot of things right in terms of setting a high bar, as well as showing off what the company has to offer. It is exactly what you’d expect from a world-class software company that has fairly high standards for engineers. Continue reading “The Microsoft SDE Interview”