alternative title: Cliff notes on software-developer productivity where I quote Joel Spolsky and Tom DeMarco a lot.
This is a Work In Progress. Pardon the mess. Suggestions are welcome.
To spark conversations about office culture, productivity, and team-project success.
The ideas I present below are borrowed from non-controversial industry figures like DeMarco and Spolsky.
Workarea and Productivity
- The manager’s function is not to make people work, but to make it possible for people to work.
- Developers should have private offices, or at least quiet spaces to work.
Complex work is done best while being in “the zone” or in a state called “flow”. Getting there requires concentration, which requires peace and quiet, which requires feeling safe enough to let down your guard and let go of the world around you. One way to achieve this feeling of safety is to have control over your environment.
How often do you see headphones in an open office layout? Or little mirrors mounted on peoples monitors? These are attempts to exercise control over our environment. To create peace. To get into “the zone.”
Nerf wars are fun — I once had a holster under my desk! — but a single shot could snap me out of “the zone” for a good 10 minutes. A lot of energy would be rerouted from coding into attempting to zen back into the flowing sea of productivity.
The mere presence of a nerf-gun can inspire constant vigilance due to fear of impending attack. And when the world around you is louder than the gentle hum of your computer screen, you can’t enter the state of flow — without which no complex work gets done.
During single-minded work time, people are ideally in a state that psychologists call flow . It is a condition of deep, nearly meditative involvement, a gentle sense of euphoria when one is largely unaware of the passage of time. For anyone involved in engineering, design, development, writing or similar tasks, flow is a must. These are high-momentum tasks that only go well when you’re in flow. Unfortunately, it can’t be turned on like a switch, it takes a slow descent into the subject, 15 minutes of more of concentration before the state is locked in. Each time you’re interrupted, you require an additional immersion period to get back into flow. During this immersion, you’re not really doing work.
An Endless State of No-Flow
If an average incoming call takes 5 minutes and your reimmersion period is 15 minutes, the real cost of that call in work time lost is 20 minutes. A dozen phone calls use up 1/2 a day, a dozen other interruptions and the day is gone. As important as the loss of effective time is the accompanying frustration. Workers who keep trying to get into flow and are interrupted each time end up unhappy. A few days like that and anybody is ready to look for a new job. Managers tend to be unsympathetic to the frustrations of being in no-flow because their own work is done in interrupt-mode, but they have to understand that it reduces effectiveness and satisfaction of their workers, increasing the cost of getting work done.
Time Accounting Based on Flow
Most company’s accounting model is based on the conventional model assuming work accomplished is proportional to number of hours put in, making no distinction between hours spent doing meaningful work and hours of pure frustration. They account for body time rather than brain time. To really measure uninterrupted hours honestly, you have to remove the onus from logging too few uninterrupted hours. People have to be assured that it’s not their fault if they only manage 1 or 2 uninterrupted hours per week, rather it’s the organization’s fault for not providing a flow-conducive environment. The first huge benefit is that it focuses your people’s attention on the importance of flow time. The resultant interrupt-consciousness helps protect them from casual interruption by peers. The other big benefit is a record of how much meaningful time has been applied to a project. Project management using body-present hours is a futile endeavour.
Thinking on the Job
Tom DeMarco was at Bell Labs sharing an office with Wendl Thomis who went on the build a small empire as an electronic toy maker. One day, while Wendl was staring into space pondering problems of extreme complexity with his feet propped up on the desk. Their boss came in and asked, “Wendl! What are you doing?” Wendl said, “I’m thinking.” And the boss said, “Can’t you do that at home?” At least in those days they had the option of thinking. Your people bring their brains in with them every morning. They could put them to work for you at no additional cost if only there were a small measure of peace and quiet in the workplace.
If you’re in a noisy bullpen environment like the type that caffeinated dotcoms love to create, with marketing guys screaming on the phone next to programmers, your productivity will plunge as knowledge workers get interrupted time after time and never get into the zone.
With programmers, it’s especially hard. Productivity depends on being able to juggle a lot of little details in short term memory all at once. Any kind of interruption can cause these details to come crashing down. When you resume work, you can’t remember any of the details (like local variable names you were using, or where you were up to in implementing that search algorithm) and you have to keep looking these things up, which slows you down a lot until you get back up to speed.
— Joel Spolsky’s “Where do they get their unoriginal ideas?”
A warning about Performance Reviews
Performance reviews can encourage supervisors to save up insightful comments until the “review period.” Don’t do that. The last thing you want is a 3-6 months delay in dealing with a problem. Help your team members improve every day.
Imagine applying “performance reviews” in a personal relationship. Would it make sense to hear what your significant other thinks 6 months after the fact? No. That would be dreadful. You stop and deal with problems immediately: real-time relationship debugging!
Performance review metrics get gamed
If you have a metric called “the number of bugs a programmer causes” then programmers will fight with testers, trying to convince them that something is not a bug in order to keep their bug counts low.
The effect of reviews on morale is lopsided: while negative reviews hurt morale a lot, positive reviews have no effect on morale or productivity. The people who get them are already working productively. For them, a positive review makes them feel like they are doing good work in order to get the positive review… as if they were Pavlovian dogs working for a treat, instead of professionals who actually care about the quality of the work that they do.
And herein lies the rub. Most people think that they do pretty good work (even if they don’t). It’s just a little trick our minds play on us to keep life bearable. So if everybody thinks they do good work, and the reviews are merely correct (which is not very easy to achieve), then most people will be disappointed by their reviews. The cost of this in morale is hard to understate. On teams where performance reviews are done honestly, they tend to result in a week or so of depressed morale, moping, and some resignations. They tend to drive wedges between team members, often because the poorly-rated are jealous of the highly-rated, in a process that DeMarco and Lister call teamicide: the inadvertent destruction of jelled teams.
— Joel Spolsky on Incentive Pay Considered Harmful
Psychologists talk about two kinds of motivation: intrinsic and extrinsic. Intrinsic motivation is what drives you to do something regardless of whether you will receive a reward. Why do you spend an hour cleaning the inside of your stove? Nobody looks in there. Your intrinsic motivation compels you to do a thorough job. We all have it — in fact, most people start out with the desire to excel at whatever they do. Extrinsic motivation is the drive to do something precisely because you expect to receive compensation, and it’s the weaker of the two.
The interesting thing, according to psychologists, is that extrinsic motivation has a way of displacing intrinsic motivation. The very act of rewarding workers for a job well done tends to make them think they are doing it solely for the reward; if the reward stops, the good work stops. And if the reward is too low, workers might think, Gosh, this is not worth it. They will forget their innate, intrinsic desire to do good work.
— Joel Spolsky
- Avoid technological and methodological hype. Treat quality and self-esteem as a goal. Bend schedules and methodologies to serve this goal.
Stuck between a tight deadline and a fixed scope, developers and designers often sacrifice usability, quality and performance. Often manifested as technical debt.
Software is a living and breathing thing, it must evolve to respond to a changing environment, it is never complete. But don’t worry, Agile methodologies can help tremendously!
Agile can’t be faked
The trick to making Agile succeed is authenticity and avoiding the Cargo Cult. Really let it penetrate every aspect of the company’s culture. Set a conscious goal of avoiding overtime, prioritize and comb the backlog, have healthy realistic sprints.
A team that practices Scrum’s standup meetings and has Kanban boards around the office, but still depends on overtime to accomplish scope by an arbitrary deadline is as Agile as me eating a jar of peanut butter while watching a Game of Thrones marathon is athletic. Though that does sound fun.
Avoid overtime. This is so important, it has it’s own section!
Unattainable goals, often fueled by tight deadlines and waterfall methodologies, lead to 80 or even 100 hour work-week death-marches that burn health in exchange for diminishing progress. Eventually people get sick. Bitterness breeds and complaints begin to appear about wages as people conclude: “If I’m going to be miserable, I might as well get paid for it!”
Hours overtime always turn into hours undertime as physical, mental, and emotional exhaustion makes people unproductive. Teams become unstable as irritability and bitterness destroy hard earned team chemistry. Turnover grows. A pre-filtered pool of quality candidates dries up as fast as the reputation of the company spreads among employees’ friends.
Don’t do overtime. Don’t do crunch time. Ignore comments about “bonding” that programmers say we feel having survived a death-march. Victims of abusive relationships can get addicted to the thrill of surviving them, do not enable them. Be their hero!
QA can automate testing and provide actionable insights. It’s a great example of an intern training program any company can launch that will yield a direct increase in the quality of its products and prep interns for future developer roles within the organization.
Programming has more in common with writing and surgery than with architecture and buildings. In reality we quite often don’t know how long something new will take until we are deep in it. And quite often, the greatest progress happens during spontaneous moments of inspiration, rather than a carefully constructed plan. Be very careful with estimates:
Never, ever let managers tell programmers to reduce an estimate.
Many rookie software managers think that they can “motivate” their programmers to work faster by giving them nice, “tight” (unrealistically short) schedules. I think this kind of motivation is brain-dead. When I’m behind schedule, I feel doomed and depressed and unmotivated. When I’m working ahead of schedule, I’m cheerful and productive. The schedule is not the place to play psychological games.
— Joel Spolsky on software schedules
In the workplace, the major arouser of emotions is threatened self-esteem. We all tend to tie our self-esteem strongly to the quality of the product we produce: any step you take that may jeopardize the quality of the product is likely to set the emotions of your staff directly against you. Managers jeopardize product quality by setting unreachable deadlines: workers know the only thing to give on will be quality, and they hate it.
— Peopleware Chapter 4: Quality – if time permits
Goals, Morale, and Teamicide
You want Jelled teams. Avoid Teamicide.
Jelled Teams — “group of people so strongly knit that the whole is greater than the sum of the parts. Productivity is greater than that of the same people working in unjelled form. Enjoyment that people derive from their work is greater than what you would expect from the nature of work itself.” A jelled team will have low turnover, a strong sense of identity (a sense of eliteness), and a feeling of joint ownership of the product being built. You want this!
Teamicide (nemesis of Jelled Teams) — “sure-fire ways to inhibit the formation of teams and disrupt project sociology” or specifically: what a lot of companies, including your competitors, are doing right this minute.
Programmers and Artists take pride in the quality of their work — it is a primary motivation. The common “quality if time permits” approach sacrifices quality and therefore destroys powerful intrinsic motivation. This disrupts teams, and will eventually cost you your high-performers.
High productivity requires job satisfaction. Satisfaction requires quality. Cultivate quality, trust, and pride. Read all about it in Peopleware! :)
TL;DR: This isn’t exactly black and white but as a general guide:
- Developers require peace and quiet — programming is like juggling a dozen flaming chainsaws, it requires focus.
- Keep it under 40 hours a week — seriously.
- Shower developers in user stories, use cases, and testing.
- Don’t treat programmers like interchangeable, expandable, glorified typists. They no likey.
- Devs thrive under Agile/XP methodologies — skip the formal procedures and meetings. Focus on iterative development cycles, keep a backlog, set quality as an active and conscious goal.
- Testing is NOT something you do at the end of the project a week before it ships. (Now that’s a good bumper sticker!)
- Programming doesn’t always go right, sometimes architectures fail, bugs prevail; murphy’s law is resilient! It’s like surgery, you don’t really know how long it will take until you are in it. Treat schedules as educated guesses and focus on prioritization and iteration. That way when time runs out, you have all the most important features done.
- Invest in testing and fixing bugs before implementing new features. Every once in a while, slow down and consolidate technical debt. Debugging recently written code is cheaper and easier than debugging 6 month old code, which is cheaper and easier still than a new developer debugging someone else’s old stale rushed code.
- Tight deadlines make us work faster not better. Quality is the first thing that gets cut.
- Performance reviews tend to mostly hurt morale. They are not the right place to provide feedback which would have been useful months earlier.
- Bonuses tied to performance destroy teams. [needs citation]
- Create schedules and estimates without playing mind games.
Developers’ self-esteem and enjoyment are undermined by the necessity of building a product of clearly lower quality than what they are capable of.
— Peopleware Chapter 20: Teamicide
- A copy of Tom DeMarco’s “Peopleware”
- Developers taking a yellow highlighter to the book.
- Management reading the resulting book.
Reading List For Make Benefit Your Work Place.
- Frederick Brooks’s Mythical Man Month (still accurate today)
- Tom DeMarco’s Peopleware (actionable start to finish)
- Nathaniel Branden’s Six Pillars of Self-Esteem – he survived a relationship with Ayn Rand, ’nuff said.
- This original wiki about Agile
- Anything by Kathy Sierra (she’s amazing!), Amy Hoy, and Patrick McKenzie, Joel Spolsky and Jeff Atwood.
Incredibly successful companies are practicing these ideas in wildly interesting ways:
- Valve’s New Employee Handbook is a rich vein of cultural ore. It’s an incredibly successful company with around 300 employees and 0 middle-managers.
- 37 Signals – a company whose name is synonymous with SaaS, startups, and Ruby on Rails, released a guide called Getting Real for succeeding in the modern tech space.
Did I miss anything?
Share your suggestions and experiences in the comments!