Laura Frieder and Jonathan Zittrain: “The average investor who buys a stock on the day it is most heavily touted and sells it 2 days after the touting ends will lose approximately 5.5%. For the top half of most thoroughly touted stocks, … a spammer who buys at the ask price on the day before unleashing touts and sells at the bid price on the day his or her touting is the heaviest will, on average, earn 5.79%.”

Leonard Richardson has a site which monitors daily stock spam activity. You can see from his charts that buying these scammy penny stocks is a guaranteed way to lose money.

Leonard, by the way, is the co-author of Ruby Cookbook, 906 pages of shiny, nearly perfect Ruby code with detailed explanations of everything, this book is a fantastic way to learn Ruby.

His wife works at Fog Creek Software; if you’ve emailed us lately and heard back from someone named Sumana, that’s her.

Of all the things broken at Microsoft, the way they use source control on the Windows team is not one of them.

A young Windows engineer writes:

“… prior to the restart effort of Longhorn, there were about seven [branches], reverse-integrating into one main branch every two or three weeks perhaps. Now, imagine several thousand developers checking in directly into seven branches. This will lead to two things:

“1. you check in frequently, and there’s a very high chance of either breaking the build, or breaking functionality in the OS, or 2., as a counter-reaction, you don’t check in very often, which clearly is bad, since now you don’t have a good delta history of what you did.

“So this clearly didn’t scale. As part of the restart effort, we decided that each team would get its own feature branch, each feature area (multiple teams) would go up to an aggregation branch, and those would lead up to the final main branch. (As such there’s now north of a hundred branches in tiers, leading up to about six aggregation branches.) Teams were free to choose how many sub-feature branches they wanted, if any, and they were free to choose how often they wanted to push up their changes to the aggregation branch. As part of the reverse-integration (RI, i.e. pushing up) process, various quality gates had to pass, including performance tests. Due to how comprehensive those gates ended up being, this would take at least a day to run, plus perhaps a day or two to triage issues if any cropped up; so there was a possibly considerable cost to doing an RI in the first place. However, these gates were essential in upholding the quality of the main branch, and had they not existed, the OS would have never shipped. I suppose it’s one of those ‘what doesn’t kill you…’ type deals.

“Some teams did manage to manufacture pathological cases for themselves where changes wouldn’t RI up for several months, but that’s the individual team’s fault (or their release management), and not the process. Generally, the more disciplined teams were about quality, the faster and more frequently they’d RI. From what you know about the varying levels of stability/quality of components of the OS, it’s pretty easy to map that back to RI velocity and so forth, since it all goes hand-in-hand pretty nicely.”

When you’re working with source control on a huge team, the best way to organize things is to create branches and sub-branches that correspond to your individual feature teams, down to a high level of granularity. If your tools support it, you can even have private branches for every developer. So they can check in as often as they want, only merging up when they feel that their code is stable. Your QA department owns the “junction points” above each merge. That is, as soon as a developer merges their private branch with their team branch, QA gets to look at it and they only merge it up if it meets their quality bar.

The best way to imagine this is to look at this screenshot from Accurev. As you can see there are a lot of “leaf” branches but as things get merged up towards the trunk, they have to pass through QA which basically just checks that it’s OK and then merges it closer to the trunk. By the way, Accurev makes a nice source control system that is designed for this style of intensive branching and merging. The Windows team itself uses their own source control system which, it is rumoured, is just an old version of Perforce for which they bought a source license; Perforce has a reputation among developers for being expensive, solid, and extremely fast when working with extremely large source code bases.

Arno Gourdol on the design of the off button in Mac OS X: “And finally, how often do you need to manually set your computer to Sleep? I just close the lid of my MacBook and it goes to sleep: a simple mechanical, physical interaction: no need for a software command.”

Right. Here’s what the current Mac OS X shut down dialog looks like:

PS: We still have a few hundred copies of Aardvark’d (the movie) in stock. That’s the documentary about summer internships at Fog Creek and the making of Copilot. They make great gifts.

Moishe Lettvin, who spent a year working on the menu I criticized yesterday: “So that nets us a conservative estimate of 24 people involved in this feature.”

Every piece of evidence I’ve heard from developers inside Microsoft supports my theory that the company has become completely tangled up in bureaucracy, layers of management, meetings ad infinitum, and overstaffing. The only way Microsoft has managed to hire so many people has been by lowering their hiring standards significantly. In the early nineties Microsoft looked at IBM, especially the bloated OS/2 team, as a case study of what not to do; somehow in the fifteen year period from 1991 – 2006 they became the bloated monster that takes five years to ship an incoherent upgrade to their flagship product.

Dmitri Zimine has a hypothetical story of how interrupting a programmer for a two hour emergency request needed to close some sale can actually waste two weeks. “If Sarah spends just two hours thinking of her old project, she loses a day of productive work on the new one,” he says.

I agree that context switching is harmful. Absolutely.

Dmitri points out that the development manager should “tell the developer to stick to the original plan. Offer to protect her from switching her mind context. Remind her how cool it is to work single-mindedly on an important and interesting project. Ensure her that I’ll handle the pressure.”

This sounds like something I would agree with, too. I completely agree that management has a responsibility to provide an abstraction layer for programmers, so programmers can pretend that the outside world doesn’t exist while they work on code.

However, something in the conclusion here strikes me as odd. Dmitri is only looking at one side of the cost/benefit equation. He’s laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn’t even mentioned arguments for the other side: the important sale that will be lost.

Agile development is supposed to be about agility. It’s supposed to mean that you can change plans quickly. It’s not supposed to be about rigid programming teams who are so slavishly devoted to their Two Week Plans that they can’t rearrange their schedule a bit to serve the needs of the customer. Dmitri’s conclusion, I’m afraid, strikes me as the very opposite of agile development. Agile is not supposed to be about swapping out one set of bureaucratic, rigid procedures for another equally rigid set of procedures that still doesn’t take customer’s needs into account.

I don’t know the details of this hypothetical example. Maybe in real life the customer’s needs weren’t really that urgent. But maybe they were? Maybe this customer would have saved the company and made everyone a web 3.0 millionaire, but Sarah’s doctrinaire insistence on following the Two Week Plan (because it was “agile”) made them lose interest? Not sure… there’s only one side of the story here.

Recently Microsoft released a new version of Internet Explorer. They introduced a bug in proxy detection code which caused a very small number of Copilot customers to experience crashes. Meanwhile, the Copilot development team, informally known inside Fog Creek as “Ben,” was busy trying to get Copilot 2.0 out the door. But you know what? Our customers who had installed IE 7 were experiencing crashes. This was not acceptable. Ben stopped what he was doing, installed the old version of the compiler, checked out the old source code, fixed the crash, and pushed a patch out to the server. It interrupted and delayed Copilot 2.0, and the context switching was harmful. But it was still the right decision to make. Being able to do mentally difficult things like context switching makes our product better. This Is Why Programmers Get The Big Bucks. The whole reason you gave them Aeron chairs, unlimited M&Ms, free catered lunches, and the kickass computers with the 30″ LCDs is so they can deal with new bugs Microsoft introduced in their code by messing up a DLL that used to work.

Yes, context switching is painful. Yes, you need to take into account the costs of context switching when you interrupt someone’s work. But every decision has pros and cons and when I hear a manager who is just talking about the cons without considering the pros, that manager is not doing their job.

A management consultant at Bain wrote me a nice email, that included the following sentence:

“Our team is conducting a benchmarking effort to gather an outside-in view on development performance metrics and best practice approaches to issues of process and organization from companies involved in a variety of software development (and systems integration).”

I didn’t understand a thing he wrote. The email contained a lot of words (“benchmarking,” “outside in,” “performance metrics,” “best practice,” “process and organization”) each of which set off a loud buzzing alarm-like sound in my head. The noise from the buzzing was so loud and so distracting that I found myself completely unable to parse the email.

I think it was something about measuring performance in software organizations? aHA! YES! I know all about that. You can’t do that. Quit it. Stop it.

Listen. Let me tell you a secret about management consulting companies and software organizations.

Here is how the game is played.

Big Consulting Company calls up Big Oil Company. “Hey,” they say, “do you guys need help being more productive developing software?”

Big Oil Company says, “Yeah, sure, whatever, we’ll buy anything,” and they buy a $1,000,000 software productivity consulting deal.

The consulting company comes on site, measures a bunch of bogus things like Lines of Code Per Developer, or, if they’re really fancy shmancy, Number of Function Points Per Programmer Per Day. Then they tell the oil company, “Gosh, you’re only getting 73.844% productivity. Pay us another $2,000,000 and we’ll double your productivity.”

Oil company pays the $2m.

Consulting company comes in, gets all the programmers in a room, tells them all about Function Points and stuff, and how productivity is REALLY IMPORTANT.

Programmers remember that scene from Office Space where Bob and Bob, the consultants, recommended all the people to get fired.

Programmers start writing a heck of a lot more function points. For example you can triple the number of function points in your code simply by round tripping everything through an XML file. Big waste of time, prone to bugs, does nothing, but each file you touch adds a function point. W00t!

Consulting company comes back, measures again, and lo and behold, with all the round trips through XML the function point count is up drastically. Consultant announces that Oil Company is now at 151.29% productivity. MISSION ACCOMPLISHED.

But there’s one more step. Now the consultant goes to another Oil Company. “Hey, did you know your peers are getting 151.29% productivity? How are you doing?”

Oil Company #2 is scared. They pay for the initial study. They’re only getting 83.948% productivity. Shit. And the cycle starts anew.

The whole fraud is only possible because performance metrics in knowledge organizations are completely trivial to game. The best part is that most management consultants, the stunningly good-looking, bright, earnest chipmunks with 4.0s in Russian Lit from Harvard who work for these companies, have absolutely no way of knowing this, so they can go through this whole exercise without even knowing that they’re doing it! They get all the way through the 2-year associate program on their way to MBA school without even realizing that they haven’t done a goddamn thing about productivity, all they’ve done is caused a fairly pointless transfer of wealth from ExxonMobilConoco to BainMcKinseyGartner’s senior partners. And it’s a lot of fun! First class flights to Houston and Oslo! Helping the world be more productive! Rock on, young stunningly-good-looking Management Consultant.

Every Sunday morning when I was 12, I would listen to Casey Kasem on KQEO and write down a list of any new or upcoming songs. Then I would take my weekly allowance of $5 straight to the record store and spend it on 45s. They were a dollar each. Eventually I had a pretty good collection of, um, maybe 100 records, which my mother is now begging me to throw out.

What I never imagined is that when I grew up, I’d be able to expand my record collection to about 2,500,000 songs for just under $10 a month. I’ve been subscribing to Rhapsody (formerly Listen.com, now owned by Real) for the last four years or so, and it’s a great way to listen to music at the computer.

But laptops have lousy speakers, and I had been looking for a way to pump the music from the computer into other rooms of the house, so last January I finally got a Sonos system, which is probably the coolest piece of technology I’ve ever bought. Ever.

It’s kind of a confusing system–a combination between a stereo and a computer and a wifi network–so let me explain a bit how it works.

First, you get some ZonePlayers: one for each room where you want music. There are two kinds of ZonePlayers. The big one has its own amplifier. You just plug speakers into it. The little one doesn’t have an amplifier. You plug it in as an aux input on an existing stereo system.

You can get up to 32 of these. I bought three: one in the living room, one in the kitchen, and one in a bathroom. Usually, you put one of the ZonePlayers near your computer and connect it with an ethernet connection to your network; all the other ZonePlayers magically find each other using WiFi, so you don’t have to connect anything. It really is magical. The ease of configuration and setup is astonishing. It’s about ten times easier than installing a printer. It’s fifty times easier than getting Bluetooth to work. The Sonos developers obviously put a huge amount of work into making setup and configuration completely painless.

Next, you get one (or more) handheld controllers. These also use WiFi, and they also find the rest of the system pretty much automatically. They have a terrific user interface, an iPod-like thumbwheel, a big bright LCD color screen, and all kinds of brilliant UI touches. For example, to save batteries, the screen dims when you put it down, but if you pick it up again, a motion detector lights up the screen.

Finally, you can install the controller software on any home computers you have: Windows or Mac. This is a desktop application that more or less behaves exactly like the handheld controllers.

Now you pick up any of the controllers anywhere in the house, tell it what rooms you want to control, and browse through your music collection. You can play any music files stored on any attached computer: MP3s, WMAs, AACs, OGGs, etc. You can play internet radio stations–I use this to listen to Seattle’s NPR station to hear All Things Considered three hours later than I can get it in New York. If you want to play music from an iPod, an old vinyl turntable, or an eight track tape player, just plug it into the back of any ZonePlayer.

And, in the ultimate coolness, if you get a subscription to Rhapsody Unlimited, you can browse and play any of Rhapsody’s 2,500,000 songs anywhere in your house.

So now if one of my guests is complaining about the music, I hand them the controller, and they browse around for something they like and play that instead.

The one thing I can’t stop talking about is what a nice job Sonos has done with the user interface. This really is a zero-configuration system. Everything is easy. A long time ago I wrote: “Every time you provide an option, you’re asking the user to make a decision. That means they will have to think about something and decide about it.” Users don’t want to decide if the WiFi network should use WEP or WPA. They do want to decide whether to listen to the Big Mountain version of Baby, I Love Your Way or the Peter Frampton version. Or one of the ten other versions Rhapsody has online (check out Mig Ayesa’s). No extra charge.

Geek Stuff

I asked Nick Millington, the Director of Software Engineering at Sonos, to tell me a little bit about the software development environment. It turns out the controller and the ZonePlayers are running Linux. “We started with a standard Linux kernel,” he told me, “then added some of our own device drivers for audio, our buttons, scroll wheel, and other controls, and networking (the latter employing strict Office Hungarian in its source code I might add, in possibly a ‘first’ for Linux kernel modules).”

More from Nick: “All of our applications use a shared code layer written in C++ for their basic network communications protocol stack. The controller applications share a ‘household’ data model that manages knowledge of the set of ZonePlayers that you own, how they are linked together, what music is playing, and so forth. Finally, there is a platform specific UI layer for each controller: a custom-built UI layer on the CR100, a Win32 UI based on WTL (Windows Template Library) on Windows, and a Cocoa/Objective C UI layer on the Macintosh. WTL and Cocoa have both worked out well for us. WTL succeeds in taking away a lot of the drudgery of programming directly against the metal without hiding how Windows actually works to the point of being dangerous because developers forget how to fly without the autopilot. Cocoa has been nice as well–I’m sure everyone in the Mac world knows about this, but coming from Windows I found its approach to memory management (where each pump of the message loop gets you effectively a fresh ‘heap’ that is automatically cleared when returning to the message loop) pretty cool. It allows you to actually write code that returns something like a string, without putting in place the overhead of a garbage collection scheme.

“We use the de facto ‘native’ compilers for the platform we are building on (gcc for Linux, MSVC for Windows, and the gcc that comes with Xcode on the Mac). It has been relatively easy to keep our code portable across these 3 compilers, which we enforce by doing daily builds on all the platforms. The build is all wrapped up into one nightly cron job that checks everything out of source control, kicks off the Linux builds, contacts the Windows and Mac build machines to do their part of the work, and waits for everything to finish up. Then end product is an ‘online update’ package that gets posted directly to our intranet upgrade server and allows testers to install our daily builds on all the hardware in their test systems.”

Kiere: “After using my new help desk system for about 100 tickets and 45 knowledge base articles, I can honestly say this has been my favorite tool yet. It is fast, productive and simple.”

I tried to sign up for an online site.

The signup page wanted a secret question and secret answer. For the secret question, I put “what is aunt Vera’s cat’s color”. It complained about the apostrophe in the question. OK, fine. I deleted that apostrophe.

For the secret answer, I put “Aunt Vera doesn’t have a cat.”

And I got this:

1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘t have a cat’, ‘male’)’ at line 1

This means that the programmers are in the habit of taking strings that they got from the user (i.e. GET or POST parameters) and concatenating them together with other bits and pieces of SQL to generate SQL statements.

For example, in PHP with PostgreSQL:

$x = pg_query("select * from accounts where name='" . $_GET["name"] . "'");

(For non-PHP programmers: “.” is the string concatenation operator).

I’m not surprised that they are in the habit of doing this; a lot of programming books, tutorials, and documentation use examples like this.

Unfortunately it’s a gigantic security hole called SQL injection.

The user, if malicious, can close the string that you opened, finish your select statement, put in a semicolon (the SQL statement separator), and then type any SQL code they want, and it will run.

So, for example, if the user supplies this as name:

foo'; delete from accounts --

… the SQL statement executed will be:

select * from accounts where name='foo'; delete from accounts --'

… which will do exactly what it looks like: it will delete the entire table of accounts.

This is an extremely common problem: Michael Sutton did a little research project and found that 11.3% of web applications have SQL injection vulnerabilities.