Archive for April, 2008

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.

On Layoffs, “Jelled Teams,” and my new job status

I don’t think it’s possible to over emphasize the importance of developing teams in software companies. Software production is a group activity, and Brooks, Lister, Demarco and Weinberg all announced this same thing in various ways. And they have been saying it for a long time. The Mythical Man Month, The Peopleware Papers, and The Psychology of Computer were all written over a quarter century ago.

But, in spite of 30 years, and thousands of pages written, people still don’t get it.

Up until Monday I was working on a suite of fantastic applications for patient data and hospital management. I was part of a small, but very talented team of developers doing amazing things. Sure we had great tools like Python, Ext.js, TurboGears, etc. But the fundamental reason we were so successful is that we had a great team that worked together really well.

How do you know you’ve got a great team?

Chad Fowler’s very good (but very poorly titled) book My Job Went to India: and all I got was this book has a chapter explaining how before he became a programmer he was a musician, and someone gave him this powerful advice:

“Always try to be the worst player in the band.”

If you seek out people who are better than you, people who will push you — people who will make you grow just to keep up — you won’t have the option of stagnating. You either get better, or you get out. That’s how I felt on this team, and I know it’s how we all felt.

We knew each-other, knew our strengths and weaknesses, and we knew that together we could make things happen. We knew how to challenge one another, and if something went wrong, we would take action to fix it as a team.

Great teams are a huge asset

I can honestly say that it was the best team of people I’ve ever worked with, and we were producing products with real revenue attached — in other words, we were making money, and lots of it.

But as you can probably guess, after the acquisition came layoffs. And the team was chopped in half. Even though the team consisted of the best developers in the company, even though we were the most profitable part of the company, even though things were going amazingly well in our little corner of the world — we were still torn asunder by layoffs.

There may be some higher corporate logic behind this. And perhaps at some level it was the right thing to do, though I doubt it. I am convinced that Lister and Demarco are right is arguing (via peopleware) that a “jelled team” is an incredibly valuable resource for a company. They get stuff done, and get it done quickly, because they already know how to work together well. We cared about one another, cared about our work, and cared about our company, we were motivated, skilled, and we got things done. Loosing that is loosing a lot.

I got lucky

I was fortunate enough to be the newest member of the team, and was one of the folks that was let go. Why fortunate? Because I don’t have to sit around every day trying to get stuff done without the rest of the team, because I don’t have to be reminded every single day of what once was, but is no more.

And because I can take this opportunity to take a breath, look around and try to find a job which fits my long term goals. I don’t know exactly what I want to do yet, but I do know that I want to do something good for python, something good for the world, and something where I get to work with great people.

So if you’re interested, feel free to drop me an e-mail (mark.mchristensen@gmail.com).

Please hire these guys — they are amazing!

But more importantly there are some other great developers who are also looking for jobs. I’ve seen them perform miracles in C#, Java, Python, and any number of other languages. And I know them well enough to know that they would each be a huge asset to any company who’s looking to develop a great team.

One of the things you need the most in team development is someone who has a picture of how it could be better, of what’s possible, and the will to make it so. In addition to their technical skills, I know that’s something they all have. So, if you’re looking for one or more highly skilled software developers in the Atlanta area (or you’re willing to work with remote people) I can’t recommend them highly enough. Please send me e-mail if you’re interested and I’ll pass the info on to the right people.