Compound Thinking

The Dangers of Paying Too Well

Paying people too well can lead to all kinds of social and motivational problems. Of course, you can also run out of money, but I’m not going to talk about that problem. I’m talking about salaries that are maintainable but significantly above the market norm.

Clark Ching recently blogged about something I’ve seen a couple of times. He worked for a company that paid developers very well. You’d think that would be good for morale, but it wasn’t. Clark puts it this way:

It was horrible. Everyone who worked there agreed.

People who hated their jobs stayed just because of the money. This meant that everybody had to work with people who hated being there, and that meant that nobody wanted to be there ;)

Good pay reduces turnover, which is generally a good thing. But some turnover is good turnover, so too much pay can actually hurt you. Beyond that great pay keeps people around, but bad experiences with managers and coworkers can do more to kill morale than you can ever replace with money.

The long and short of it is that you can’t paper over morale problems with money, and you can’t fix them by instilling a sense of urgency. Paul Graham suggests one solution — do something good. If you’re doing something good for the world people want to help you. I’d extend that to say if you’re building something people can be proud of, you’re far more likely to create the kind of positive morale which lasts through hard times.

Case in point, this story of a couple of apple employees worked on the graphing calculator that was shipped with the original Macintosh computer. The interesting part is not that they were excited to work on the project, but that they kept working on it under-cover for months and months after they had been laid off.

Why would they do that?

I had long been proud of the elegance and simplicity of our design…. I had designed it for all users, even those who know little about computers and hate math.

I wanted to make mathematics as easy and enjoyable as playing a game.

They did because they were proud of what they’d done, and because they wanted to make mathematics more accessible.

So many revolutions, so little time.

Tim Bray is blogging about “inflection points” in the uptake of various technologies.

Python get’s a very positive review:

Today you’d be nuts not to look seriously at PHP, Python, and Ruby.

So, the rise of the so-called scripting languages is one of the inflection points, but it’s not the only one.

He singles out web-framework development as one place where there’s a lot of stuff happening, and a lot of new “rails-like” frameworks are cropping up all the time. TurboGears will live or die in the context of a much larger web-development revolution, and we need to be prepared to make our way forward in the midst of that.

What comes after rails will not be a rails clone. It will learn the right lessons from rails, avoid the pitfalls of rails, but it will also need to carve out something new and better than rails. For RDBMS users, I think the key difference between TG and Rails is the power and flexibility of SQLAlchemy. We need to “sell” this better.

There are a lot of other revolutions coming according to Tim. And I do think we’re looking at big changes in terms of everything from programming language choice, to web-development tools, to end-user desktops, and data persistence mechanisms. We’re also just beginning to see what the world of high-end javascript and other “rich” internet applications is going to do to our view of end-user software.

He doesn’t even mention the rise of EC2 and the Google App Engine as sea-changes in the way we buy computational resources, and I think that’s going to have a huge impact.

In the end my prediction is that the way we develop applications will change more in the next 5 years than it did in the last 5, and it’s time to start getting our heads wrapped around these issues, or we’ll be left behind.

Authentication in TG2

Chris McDonough just posted a pretty extensive writeup of something he and Florent hacked up recently. Basically he helped us to put together some helpers that turn the repoze.who project into very similar authentication/authorization system to what we had in Turbogears 1.0.

The cool thing about this is that we get to share the stuff that makes sense to share, and yet maintain a backwards compatable API. We started a project (authority) which did the same thing, all on our own, but it’s much better to be able to share. ;) The Authority project turned out to provide a lot of useful bits and pieces which have since found homes, and that process will likely continue.

I’ve said before that I’m very impressed with the work that the Repoze folks have been doing, but I think this is a particularly good example of how it’s possible to collaborate in interesting new ways on top of a shared set of interfaces.

There’s a lot more to be done to make python web development work better, and I’m excited because we continue to move towards a world where innovating in one area doesn’t require building a whole new stack.

I think there are big benefits for users of having a healthy and diverse ecosystem.

Urgency vs. Motivation

If stress is a weed, urgency is the seed.

–Jason Fried

Just the other day a project manager I know asked me how she can “instill a sense of urgency” in her team. She wants to get more done, and get it done faster. Increasing developer productivity is a laudable goal. And she is being asked by internal and external customers for more and more stuff.

But I think there’s something wrong with the question. Urgency and “time pressure” are viewed as tools which can increase productivity. And I think this is wrong. But, it does work — in the short term.

In the long term motivation, tools, skills, and processes along with things like good unit test coverage, and good “architecture” determine productivity. Constant urgency, looming deadlines (particularly if they are artificial), and constant pressure actually hurt motivation, remove the slack required for building tools, discourage process improvements, and create all kinds of technical debt. This debt can be measured in terms of decreased test coverage, and “short-cut” coding techneques which undermine good architectural choices.

To put it more bluntly, urgency often produces short term results at the expense of long-term productivity.

If you push the question a little bit, as I did with my friend, you will usually find that the problem is not a lack of urgency, it’s a lack of motivation. Motivating people is hard, and if they have been burned out by too much “urgency” it just gets harder.

I’ve done it too. But now-days when I hear people pushing a “sense of urgency” I take it as an opportunity to start looking for deeper motivation issues.