Archive for July, 2010

If I were Microsoft…

Saturday, July 24th, 2010

I’d be running sales on XBLA games to small cross-sections of the XBL community, and using the returns on that to judge the actual price elasticity of the game in the XBox marketplace. If the sample shows that you make more money per XBLA member with a lower price, then you lower the price for everybody. If not, then keep the price high until the returns are in.

I’d be running them on demand; you can run hundreds of these market experiments at a time, and they need only last maybe a few days or a week.

Developer Management for the Lone Programmer

Friday, July 2nd, 2010

I’ve been managing software developers going on ten months now, and although I could have done way better, I’m not the kind of guy to do something for ten months and not learn anything from it. I don’t pretend that anything below is original–you can learn most all of it in any introductory management book. I’m not entirely sure I’m even right about all this stuff, but they are the truest things I know as of now.

Let Go

You’ve got to let go of the development you were doing before you became a manager. Sure, that’s the first thing you read in every management textbook, but….it’s hard. It’s really hard. Not just at an emotional level, but logistically speaking. Transferring development from one person or team to another is hard, and that’s why we avoid doing it where possible.

Take a phased approach. Give bug fixes to other people. Give small refactors to other people. Make yourself available to the new owner of the code (they probably report to you anyway, right?)

I think every new manager wants to avoid looking like a micromanaging jackhole, and I’m certainly not recommending you become one, but it will be easier and safer to let go of the coding of your projects if you stay closely engaged at the beginning  with the other aspects of the development.

You’ll need to let go of your current responsibilities before you can…

Grab Hold

The people that work for you are a force multiplier. Before you had to depend on yourself and whoever you could Shanghai into helping you to accomplish the goals you wanted to accomplish.

You now have a whole team of people at your disposal, and it’s your job to deploy them as best you can to change the way business gets done. If you’re a manager, I assume that you believe you know how to do business (or government) better than anybody else, or at least anybody else available. I very much hope you have good reasons for believing this.

Regardless of whether your ideas are good or bad, it’s now your job to put them into action, and your team allows you to accomplish many, many times more work in this direction than you can do by yourself. You’ve been given a fantastic opportunity to change your department, your company, or the world for the better. Take every advantage of it.

Software development is in its infancy, or at least an infantile state. The rate of change is incredible, and if you’re standing still, then you have lost. The way you did things a year ago is not good enough for today. Keeping the foo counters turning is necessary to good management, but is in no way sufficient. Know the state of the art in software development, and make intelligent decisions about if and how to apply it.

Try new things all the time, and put your ideas into action. Get proactive. Look for a problem space that nobody owns and fill it with solutions.

Own the Code

You may not be responsible for writing the code, but you still exercise vast control over the quality of the software your team produces, way more than any single developer.

You’re technical; sit in on use case and requirements gathering sessions. Make sure designs are optimal and forward-looking. Make sure code gets reviewed. Make sure it gets tested. Stay personally involved in all of these tasks as much as possible.

If you do not provide guidance and keep your product aligned with your goals, your team is a set of developers, each with different habits and history and inclinations, and they will produce a body of software with inconsistent design and uneven quality, software that pulls in all directions at once.

Be Responsible

I’m not talking about the basic job responsibility of keeping everybody in work and producing useful software. You have a responsibility to your people to make sure they get to do the best possible work in the best possible way.

Even a talented developer can end up with a crappy resume if their boss is a loser who puts them on pointless projects and gives them no direction. If you do a poor job, you’re not just hurting your career, you’re hurting the careers of all those who depend on you. If you do a fantastic job, then you can sleep easy at night knowing you’ve done right by the people who put their trust in you.

Production Monitoring Tips for the Internet Enterprise

Thursday, July 1st, 2010

I will here tell you a few truths, the most valuable ones I know on this subject:

Your primary monitoring should try imitate a customer as closely as possible, covering every major function a customer needs.

Prefer functional tests over diagnostic tests. Functional tests tell you whether a system is doing a job. Diagnostics only tell you whether a system thinks it’s doing its job.

Determine log retention in consultation with legal, and enforce it. It makes disk-full outages less likely, and costs more predictable.

Alerts should have tunable noisiness. Don’t turn the noisiness down until you’re sure you know what’s noise.

Spend your money monitoring what costs you money. Metrics you don’t use are a wasted expense.

But: Data is cheap. Get a lot of it. Constantly think of ways to turn it into information that you can use to your profit.