Tuesday, July 27, 2004

Emergent Design Works for Cleaning Up Offices Too

I’m a big fan of emergent schedules (see the rolling wave planning and low tech scheduling entries). I also write that way. I generally have an idea of what I’m going to say, but I’m never quite sure how I’m going to get there until I’m done writing.

Emergent design also works for me as a way of organizing. Many of you have heard me complain about my messy office — for the last ten years :-) I never could understand why my office was so messy and disorganized until yesterday. After all, when I worked inside other people’s companies, I was able to organize my office and know where everything was. I just wasn’t able to do that with my own office.

At first, my office was literally too small. When you’re self-employed, you need room for stuff — printers, paper, supplies — as well as room for the projects you’re working on (including projects for which you need to do research). So, for the first few years, my office was too small to organize well. I was able to expand my office, which helped for about three weeks, but then I couldn’t keep it picked up.

What I realized yesterday (when Esther helped me organize my office) was that I can’t file stuff when I don’t know how to organize it. I’m an “everything out” person — I like to be able to see all the things I’m working on. So, filing behind doors doesn’t work for me. And if I don’t know how to file it, I can’t. But here’s the breakthrough: Esther explained I don’t have to know how I’m going to file it permanently — I only have to know how I’ll file it for now. I can change my filing system when I know more.

Ok, so maybe you folks all figured out that emergent design works for filing systems, as well as for project scheduling , writing, and systems architecture. But it was news to me!

If you’re having trouble cleaning up your office, try what I did. Take a storage box and put a bunch of hanging folders in it. Take a bunch of file folders and put them on one side. Take one of your piles. For each piece of paper, decide if you can throw it out or recycle it. If not, see if it fits in an already-existing folder. If not, take a folder, write something descriptive, and put the piece of paper into it. Place the folder in the storage box. Repeat for all your piles. At the end, look at the stuff in the box. If you want to change the name or file it somewhere else, do so. If not, leave it. I’m leaving my stuff because I still don’t know where it all goes. But it’s no longer in piles on every horizontal surface :-)

Monday, July 26, 2004

Increase Your Value

I was at the Rational User Conference last week. I took away one significant idea from the keynotes and one of the track sessions: Writing software, according to Grady Booch is a “priviledge and a responsibility.” Systems are becoming more complex because we need them to do more things faster. We need people who can increase their value to the organization by providing these systems, taking their responsibility seriously.

Gary Cernosek gave a thought-provoking presentation in “Evolution of the Developer Role.” His premise was the developers need to turn into architects. I’m not sure about that. I do agree that continuous design a larefactoring is necessary and that developers as do all of us need to continuously increase their value to the organization.

If you’re not increasing your value to the organization every day, you’re becoming less useful and more expensive. And, you’re becoming a commodity. Commodity goods and services move to the cheapest provider.

I wrote about this earlier here, and suggested how you consider your career growth here.

Saturday, July 17, 2004

Women and Names

After reading Where Are the Women — And Their Names?, I tried to leave this comment on the FC blog, but was unable to, so I’ll post it here:

I hope the trend is for people to make choices that fit for them. My daughters have my husband’s name. We only have trouble traveling when I want to use my frequent flyer miles for them. For some reason, airlines make it incomprehensively difficult for a person to use miles for someone with another last name. You’d think with all the divorces and recreated families, they’d have caught on by now.

I’m of the opinion that feminism is really for everyone. The more one sex placates the other (at home, in the workplace, wherever), the less society as a whole can use the talents of that sex.

A trap that too many execs (women and men) seem to fall into is: work more hours and get more done. People don’t work more hours and get more done. They work stupider and make more work for other people. I blogged a bit about this a while ago: here. My hope is that feminism (peoplelism??) will help everyone make choices that fit for them, depending on their circumstances.

For me, it’s not about names, it’s about being able to hire the more suitable person — no matter what he or she looks like. It’s about creating an environment in which people perform their best work — without requiring people give up their personal lives. And it’s about releasing products (whatever those look like) that fit the customers’ needs.

Monday, July 12, 2004

Initial Experiences with Pair-Writing

Esther and I are working together this week, starting over again with the management book. This time, we’re pair-writing, and it worked surprisingly well today. We collaborate — and we have conflict, where the person at the keyboard says, “Oh no, I’m not writing that down.” However, we worked until about 5:30 today, when we were were exhausted, but have close to two chapters in first draft form. And, this first draft is far superior to the previous first drafts.

Writing English (or any other natural language) is different than writing code. In English, it’s not just the design of the writing that we discuss, it’s also the structure and the actual words. Computer languages are much more structured and very specific on how the language can be used. So we have more options for every decision. It’s a challenge, but it’s working. With any luck we’ll have more to share later this week.

By the Dashboard Light Posted

My Stickyminds column this month is about testing dashboards. If you’ve seen something even better, I hope you post a comment there or here.

Friday, July 9, 2004

Survey About New Product Development Practices

A colleague of mine, Brad Goldense, does a biannual survey about new product development practices. It’s time for another one. Here’s what he says:

Is Product Development important to you and your company?

Wednesday, July 7, 2004

Adaptability

I’m a Tour de France addict. I bicycle like those guys only in my dreams. But when I was watching the race last night, I realized something: the riders who are in a position to win the Tour are adaptable riders. They don’t excel at just sprinting, or just mountains, or just rolling-hills, or just endurance. They have enough endurance and skill in all of the riding conditions to stay competitive every day. They adapt their knowledge of the road, their practice in each type of riding, and their preferences for each type of riding to the current moment’s conditions.

So what the heck does this have to do with development? If you’re staffing a project, make sure you have enough people who are adaptable to several types of work. Maybe that means you need an architect who can also mow down defects. Maybe that means you use people who can pair with anyone else at any time. Maybe that means you have testers who can also design test architectures. It definitely means that as a project manager, you need more than one approach to project management.

The riskier the project, the more adaptable the people need to be. That way the project team can work itself out of any problems that arise. I’ll be avidly watching the Tour to watch the cycling and to see what problems arise and what the teams and individual cyclists solve them.