Author Archives: Gabriel

25 Tricks To Appear Smart In Emails And Meetings

by - Reading Time: < 1 minute

Sarah Cooper is now a freelance designer and writes The Cooper Review, but before that, she worked as a designer at Yahoo! and Google. Clearly, the years she put in there have given her plenty of ammunition for tech satire, because at least three of her listicles are hilariously spot on. They include such gems as:

  • Using a “sent from mobile” signature even from your laptop, to appear busier
  • Answering unimportant emails or ones from important people right away
  • The use of nerd language like “orthogonal”, TL;DR and other acronyms
  • Encouraging everyone to take a step back
  • Asking presenters to back up a slide
  • Taking important phone calls in meetings
  • The importance of making fun of product managers

All these tips and more, conveniently available in poster form:

Bonuses Don’t Motivate Developers

by - Reading Time: 4 minutes

First, let me reassure you that they don’t: 50 years of research have shown us that if anything, incentives demotivate employees. And not just developers, but any job that requires some thought beyond mechanistic, rote work like the assembly line.

This is succinctly explained in the most popular RSA Animate video so far (you can watch it below) — a speech given by Dan Pink, who literally wrote the book on motivation. In it, he explains how an experiment funded by the Federal Reserve and conducted by MIT, Carnegie Mellon and the University of Chicago showed that bonuses led to poorer performance for any tasks that required anything above “rudimentary cognitive skill”.

Increasing the bonuses didn’t just not do anything, it actually made people perform worse, and it held true for populations both in the US and in rural India. But this hugely valuable research is mostly ignored, despite being basically ancient by now:

  • Herbert Mayer wrote in a 1975 paper that

    “…  merit pay emphasizes the direct relationship between job performance and dollar rewards, thereby detracting from intrinsic motivation in the work itself. A system that would switch the emphasis to rewards for self-development and opportunities for greater responsibility would seem to serve both individual and organizational goals in a more effective manner.”

  • Alfie Kohn, author of another book on motivation, wrote in a Harvard Business Review article in 1993:

    “As for productivity, at least two dozen studies over the last three decades have conclusively shown that people who expect to receive a reward for completing a task or for doing that task successfully simply do not perform as well as those who expect no reward at all. “

  • Joel Spolsky, after quoting the above, wrote in 2000:

    “… any kind of workplace competition, any scheme of rewards and punishments, and even the old fashion trick of ‘catching people doing something right and rewarding them,’ all do more harm than good. Giving somebody positive reinforcement (such as stupid company ceremonies where people get plaques) implies that they only did it for the lucite plaque; it implies that they are not independent enough to work unless they are going to get a cookie; and it’s insulting and demeaning.”

  • Joel again, in 2006, writing about what he calls the “Econ 101 Management Method“:

    “But when you offer people money to do things that they wanted to do, anyway, they suffer from something called the Overjustification Effect. “I must be writing bug-free code because I like the money I get for it,” they think, and the extrinsic motivation displaces the intrinsic motivation. Since extrinsic motivation is a much weaker effect, the net result is that you’ve actually reduced their desire to do a good job. When you stop paying the bonus, or when they decide they don’t care that much about the money, they no longer think that they care about bug free code.”

So the rule is that money does not motivate, with two caveats:

  1. Rote, mechanistic tasks: more money works beautifully in that specific case. Which is why we have bonuses at all, because it worked so well in the factories where Henry Ford pioneered the concept of paying workers a better wage for better performance.
  2. Too little money: if workers think they’re not being paid fairly, it becomes a sticking point and all they think about is how they’re being screwed, which obviously prevents them from performing at their full potential.

Joel had another article in 2006, called “Identity Management Method“, in which he described how to create intrinsic motivation:

“To be an Identity Method manager, you have to summon all the social skills you have to make your employees identify with the goals of the organization, so that they are highly motivated, then you need to give them the information they need to steer in the right direction.”

Fast forward to Dan Pink’s 2009 book and 2010 RSA Animate, and he continues the same idea, breaking it down into three factors that do increase performance:

  1. Autonomy: as a manager, giving your employees autonomy is the best way to get them engaged in the work. He mentions Atlassian’s ShipIt Days as an example of how autonomy leads to great things, and should’ve mentioned Google’s 20% time as well.
  2. Mastery: “the urge to get better at stuff”. This is a big reason why the open source movement exists.
  3. Purpose: an important reason to do what you’re doing. The open source movement ties in here, and also crowd sourced efforts like Wikipedia, but increasingly, companies: Apple, Google, Facebook all have self-invented lofty purposes for their existence, and this inspires their employees.

Bonuses are related to none of those. The only reason to ever dangle bonuses in front of developers, is maybe as compensation for the rare big push requiring lots of overtime; and in that case, it’s just to prevent them from feeling exploited. Otherwise, bonuses will actually hurt productivity. And that’s a scientific fact. To get better performance out of your employees, hire smart people and let them be smart. Tell them the company story and why the job is important, then simply get out of the way and help them when they need it.

Why Great Functional Specs Are So Important

by - Reading Time: 5 minutes

Way back in the year 2000, the venerable Joel Spolsky wrote a blog post called Painless Functional Specifications – Part 1: Why Bother? It was the first of a four-part series on writing functional specs, and it featured a tale of two software companies: Hasty Bananas Software (HBS) and The Well-Tempered Software Company, a.k.a WellTemperSoft (WTS). Guess which one’s the good one. They both work on the same task of writing a file converter, but WTS does it with a spec and HBS does it without one. Contrived results? Sure:

Total elapsed time for Mr. Rogers [at WTS]: 3 weeks and 1 hour. Elapsed time for Speedy [at HBS]: 4 weeks, but Speedy’s code is not as good.

The story had two morals: functional specs lead to better software design, and they save time communicating:

When you write a spec, you only have to communicate how the program is supposed to work once. Everybody on the team can just read the spec. The QA people read it so that they know how the program is supposed to work and they know what to test for. The marketing people use it to write their vague vaporware white papers to throw up on the web site about products that haven’t been created yet. The business development people misread it to spin weird fantasies about how the product will cure baldness and warts and stuff, but it gets investors, so that’s OK. The developers read it so that they know what code to write. The customers read it to make sure the developers are building a product that they would want to pay for. The technical writers read it and write a nice manual (that gets lost or thrown away, but that’s a different story). The managers read it so that they can look like they know what’s going on in management meetings. And so on.

When you don’t have a spec, all this communication still happens,because it has to, but it happens ad hoc.

Fourteen years later, there came a company called Sprintly, which makes agile project management software. They have a lot of data on how long developer tasks spend in the various stages of the task lifecycle, so they wrote a blog post about it. Turns out, bad functional specs waste a lot of time communicating:

… most of the variability occurs before a ticket has been started (Someday to Backlog). This is the stage when stakeholders are figuring out specs and prioritizing work.

From Sprintly

From Sprintly

In the graph above, the middle two states are when coding is being done. The first and last state are when people are arguing about the specs.

First, Business Bob writes something like “As a human, I want to look at cat videos, so that I’m distracted from writing specs”. Maybe he adds in something about how the videos should play on a mobile phone and not stop to buffer every three seconds. Satisfied with his thoroughness, he emails it to Developer Dave who promptly files it away. Six weeks later he’s ready to tackle the Cat Videos feature, pulls up the spec and realizes it’s so vague that he has no idea where to start. So Dave walks over to Bob’s desk and asks 52 questions:

  1. What format should the videos be in?
  2. Do we want to support multiple bitrates?
  3. Is doing it in HTML5 in the browser fine, or do we have to do Flash too?
  4. Are we hosting these cat videos?
  5. Are we supporting portrait mode on mobile devices?

…

52. Are we transcoding videos on the fly, or offline?

Business Bob now cringes, realizing what hell he’s gotten himself into, trying to remember why he even wanted the cat videos, and spends the next two days coming up with some decent answers. Except Dave now has follow-ups to those, like what the server hardware specs are gonna be for the video hosts. This goes on for a few more iterations, and Dave finally has a decent spec, so he codes up a storm, then hands it to QA.

Two more weeks later, Tester Tricia pulls up the spec (if you’re following along, we’re now in the last state in the graph above) and takes her turn to terrorize Business Bob:

  1. Should the user be allowed to use multi-touch in the mobile version?
  2. Can the user switch bitrates while playing the video?
  3. Is there a limit on the number of cat videos that can be stored?
  4. What versions of what browsers should be supported?
  5. Are dog videos allowed?

…

52. What is considered an unacceptable transcoding time?

This is why we can’t have nice things. If Dave did a great job reading Bob’s mind and covered all the bases, maybe the software will pass QA without defects being written against requirements that were changed after the software was written. Sprintly’s data backs up what Joel was saying long ago: unclear and changing requirements eat up developers’ time.

This is why we need great — not good but great — functional specs. It is likely the biggest efficiency gain any software process can make for the cost of a talented spec writer. And that’s key, because that writer will be hard to find.

They need to be technical, ideally have experience writing software (so they know what it’s like to need good specs, and what they entail), be very thorough, detail-oriented, be able to take a lot of criticism, be able to build consensus, to get input and sign-offs from all stakeholders, and most importantly, be a solid writer. Make those specs fun to read, because boring specs make people fall asleep and that’s not good for business.

The last point Sprintly makes is how expensive context switches are, and they link to another classic post by Joel. Turns out that lead developers, who switch contexts a lot, are at least twice as slow at finishing tasks as other developers. So throw out those daily meetings, make coding hours a sacred part of the work day, encourage sparse checking of email, and leave IM chatter for urgent business.

Spolsky must feel like Einstein after Pound-Rebka. Though, more alive.

From Sprintly and Joel on Software, via Slashdot

How To Control XBMC and WMC From The Same Remote

by - Reading Time: 2 minutes

My HTPC setup uses a GP-IR02BK Windows MCE remote to control XBMC on Windows 7. In order to use the remote to launch XBMC, I installed a wonderful script for Authotkey that I found on an XBMC forum thread, written by EliteGamer360. This worked great until I got a CableCARD and started using Windows Media Center (WMC) for live TV and XBMC for videos. Now, the remote couldn’t start the former since Autohotkey would start the latter when the Green Start Button (GSB) was pressed on it.

Green Start Button on the GP-IR02BK

Green Start Button on the GP-IR02BK

So, I modified the Autohotkey script so that when the GSB is pressed, it presents a dialog box asking if you want to watch videos or live TV, then launches XBMC for the former, or WMC in live TV mode for the latter. It also has some fixes for the remote buttons:

  • The power button (which presses ‘s’) now closes WMC
  • The guide button (which presses ‘c’) now sends Ctrl-g, to bring the guide up
  • Pressing the GSB within WMC will toggle full-screen mode

There are a lot of other improvements that could be made, but I spent a couple of hours on this already, so… later revisions.

If you missed the link above, you can download the script from my Github page, as well as the XBMC keymap configuration for the remote.