Tuesday, 16 August 2005
Re: What Business Can Learn From Open Source
Passion
Early last week, I read Paul Graham’s What Business Can Learn From Open Source. In it, Graham analyzes the success of open source software and blogging to determine what they can teach businesses about doing things The Right Way™. From what I understood, his thesis seems to be that open source is successful because people work on it because of the love of coding. When people do what they love, great things happen. Graham argues that business can be most successful when harboring an atmosphere where people work on what they want.
In other words, if you leave really smart, passionate people alone together in a room, something great will come out the other end. Kind of like the old joke that, statistically speaking, a bunch of monkeys pounding on keyboards will eventually write the [insert famous document here]. But with the smart people in the room, you have better odds.
Graham states that “people work a lot harder on stuff they like.” I would agree whole-heartedly with that one, as I do it myself. Some days, I’ll spend all my time at work thinking about what I get to hack on when I get home that night. Sometimes I wish that when I got an idea for something, I could leave work for a couple of weeks to explore it full-time, if nothing more than to get it out of my system.
You see, there is only so much time a person (i.e., me) can spend working. I can spend 40 hours a week at my job, and then come home and spend another 10 – 20 a week on my own stuff, but only for about two weeks, four tops, before my family, garden, house, etc., come calling because of my neglect. Then, I have a hard time motivating myself to get back to what I was doing.
Slow and steady wins the race, they say. Sometimes, though, I get so excited, I get too impatient to be patient.
Location Doesn’t Matter
Graham’s article served as validation for something I have believed for a long time: work location does not matter for software engineers. Software is a different industry than most. I might only be saying this because I work in software, but I think it stands true. There are very few industries/jobs/occupations, where it literally doesn’t matter where you work. If you are working in the back-office of a bank, executing trades, you probably can not do that as well if you were at home. A salesman for a car dealership probably can’t sell too many cars from home. If you are in charge of screwing the caps onto toothpaste tubes, you can not do that from your local coffee shop.
But software is a creative process. It requires the creator to be in a comfortable place where he can think and create. It is hard for this to happen in a place of cubicles, white walls, and no windows, where the intercom is constantly blaring, people are switching offices a couple of times a week, and your coworkers schedule three meetings a day just to discuss your status.
As Graham writes,
The atmosphere of the average workplace is to productivity what flames painted on the side of a car are to speed.
When writing software, all you need is a computer. It rarely matters where that computer is located.
Most software engineers love what they do. They love it so much that, instead of paying $49.95 for software that organizes their collection of spores, molds, and fungus, they write their own. The really good software engineers are not through coding when they leave the office. Nope. Usually, they have another few hours of “work” to do once they get home. Not because they have two jobs, but they love putting together bits.
As Graham writes:
Like rich food, idleness only seems desirable when you don’t get enough of it. I think we were designed to work, just as we were designed to eat a certain amount of fiber, and we feel bad if we don’t.
Yes, yes yes! This is Truth™. But companies seem to think the opposite of people. They operate under the assumption that people will only work if they are being monitored, and the only way to monitor you is to hire an armed guard to make sure you are working “core hours”.
But this just seems odd to me. If a company does not trust somebody to work, why did it hire him in the first place? Graham explains the apparent contradiction:
bq. [T]he reason most employees work fixed hours is that the company can’t measure their productivity.
Process versus Knowledge
When all employees do is fill out ledgers, activate presses, or flip burgers, it is easy to measure productivity. But for people who create, it is simply impossible. Is Mozart walking down the street looking for ants to fry with his magnifying glass, or is he composing an entire symphony in his head? Is Picasso doodling in a park, or preparing for his next painting? You never know because the bulk of the work happens inside their heads.
My wife used to work in the back-office of a major bank. She is a very intelligent woman, which was not reflected in her job responsibilities. Her main function was to execute the trades that the higher-ups had decided to make in the retirement funds the bank managed. The bank was always doing “cross-training”, where another worker in her department would follow her around for a day, learning her responsibilities so that if she was hit by a bus on the way home, somebody else could step in and replace her. In essence, she was completely and totally replaceable, because all she had to do was memorize a process.
Software, however, is different. You can’t have Julie follow me around for a couple of days getting “cross-trained” so that she can pick up right where I left off when I get hit by a bus. There are things crammed into my noodle about variables, class names, hierarchies, patterns, etc., that come from writing and maintaining code for two years. The only way to get that knowledge into somebody else’s noodle is to have him maintain the code. No amount of design documents or use cases or design reviews are going to change that.
The difference between knowledge and process workers, I think, is the difference between being a lego block, and being the lego block builder. There are hundreds of different kinds of lego blocks, from `1 × 2` to `2 × 2` to `2 × 8`. Each piece has its usefulness, but when it comes down to it, they are all interchangeable. The Builder, however, is not interchangeable. He takes the pieces, mixing and matching them as he sees fit, to build something beautiful. No matter how hard I tried as a kid, I could never make anything more original than a square-looking Triceratops.
That Sword Cuts Both Ways
The other problem with pretend work is that it often looks better than real work. When I’m writing or hacking I spend as much time just thinking as I do actually typing. Half the time I’m sitting drinking a cup of tea, or walking around the neighborhood. This is a critical phase— this is where ideas come from— and yet I’d feel guilty doing this in most offices, with everyone else looking busy.
Knowledge workers have to think, think, think. We are always thinking and analyzing, looking for unique and better ways to solve problems. Sometimes it keeps us up at night. Sometimes it keeps us working until 6 p.m., 9 p.m., midnight or 2 a.m. Thinking, working. Thinking, working. During dinner, on the ride home, weeding the garden. Ideas can hit us at any time.
For most employers, this is great. They love it when their software engineers are working outside “core hours” (i.e., working late).
“I love that you stay late and work on the weekend! I’m so impressed, I nominated you for the Employee of the Year award!” you hear your Vice President of Documentation cheering.
But heaven forbid you not arrive everyday at 9 a.m. Suddenly, you’re suspected of not doing your job. You come into work one day and your technical lead takes you for a walk to talk about the hours you are keeping (yes, this really happened to me). Why flexibility at one end of the day and not the other? Why do your bosses not walk around at 5 p.m., drag everybody to their cars, and lock the office doors? The “core hours” sword cuts both ways.
When writing software, I do not have to be at work to be working.
Collaboration
The big argument against this willy-nilly approach to “core hours”, is that of collaboration. “This is a company of meetings,” I had one of my bosses tell me, “you need to be here between 10 a.m. and 3 p.m..” To a certain extent, I agree. Software does require collaboration. But why don’t you let me and my team work that out? If we need to spend a day or two at whiteboards, designing our next stage of work, we will organize ourselves to do that.
I would be the first to tell you that it is crucial that members of software teams communicate with each other, and the best way to communicate is face-to-face. Even with e-mail, instant messaging, video conferencing, and the plethora of other communication channels, it is still quicker to walk down the hall to ask one of my colleagues a question.
Graham points out that open source software “show[s] us what real work looks like.” Why? Because something comes out the other end! Developers work, software comes out. How simple. But most organizations are not put together to churn out code. They are put together to keep track of their employees and making sure they can survive if one of them gets hit by a bus or finds a better job (whichever comes first).
The Chip
Companies operate under a simple equation. According to Graham, a “company has some money, and they pay it to [an] employee in the hope that he’ll make something worth more than they paid him”. Every creative individual knows this, even if it is subconsciously, and they hate it. In the middle of the quarterly pump-up-the-troops meeting, when everybody is trying to bring the company together and unify them under The New Direction™, it just eats at us that they are motivating us to fill somebody else’s pockets.
I think this is why musicians do not like The Establishment, and are constantly criticizing bands and artists for “selling out”. Software developers understand this as well. They know that every time they ship a successful product, somebody else is making money. It is a chip that every software developer has on their shoulder.
The Solution
Graham proposes an elegant solution:
If you could measure how much work people did, many companies wouldn’t need any fixed workday. You could just say: this is what you have to do. Do it whenever you like, wherever you like. If your work requires you to talk to other people in the company, then you may need to be here a certain amount. Otherwise we don’t care…. [I]f you work here we expect you to get a lot done. Don’t try to fool us just by being here a lot.
That is how I want to work, and that is how I try and work, “core hours” notwithstanding.
Graham writes:
I see the disadvantage of the employer-employee relationship because I have been on both sides of a better one: the investor-founder relationship….
The big advantage of investment over employment, as the examples of open source… suggest, is that people working on projects of their own are enormously more productive. And a startup is a project of one’s own in two senses, both of them important: it’s creatively one’s own, and also economically one’s own….
At the moment, even the smartest students leave school thinking they have to get a job. Actually what they need to do is make something valuable. A job is one way to do that, but the more ambitious ones will ordinarily be better off taking money from an investor than an employer.
Oh, how I would love this! How I would love to be invested in! I am a human being, not a machine in a factory. I am a software developer who loves what he does so much, that I do it at night, when I come home, and on the weekend when I can. At this moment, I have an idea for three software products that I wish I could write but do not have the time.
Hey, Mr. Graham, do you have some money to invest in me?
