Re: Managing By Walking Around: from 1982 to 2006

[mirod]

I try to use the software I write.

For example one of the systems I wrote, and which I have been maintaining for a number of years now, handles subscription orders. Everytime the person that normally uses the software goes on vacation, I cover for her, and handles the orders myself. It's a boring job, but the volume is low enough that it isn't a huge burden. The thing is, for the first few years, every time she would come back from vacation, she would find the system slightly improved. There's nothing like experiencing first hand the annoyances of a system to make you improve it presto!

I try to do this with a much of the software I write as possible, even if it isn't always possible (but yes, I do use XML::Twig ;--)

[kwaping]

To complement and counter this post, I find that soliciting input from the end user is invaluable. This should be done during the planning and design phase as well as after release, ideally. You'll get the same input as if you were using it yourself, but you don't have to go around actually using all the code you write.

I've found that some/many coders and companies try to predict what users want, instead of actually asking the users. While there's nothing wrong with coming up with your own good ideas, I'm sure there are always things that you wouldn't have thought of that a daily user of your product is just itching to tell you about. A valuable side-effect of asking your users what they want and then giving it to them is that you appear to actually care about them. (Whether you actually do or not is irrelevant.)

[jdtoronto]

It's all very well asking the users up front, it gives you somehwere to start. But all too often my users don't decide what they want until the job is done - so I get them in once I have the first cut of something new done - that way I don't get too angry when they say it's not what they asked for at all.!

jdtoronto

[demerphq]

I totally agree.

My team used to have a policy (although thats a bit too formal of a term) that we would do operational tasks in conjunction with the operational support team for the first "period" after rollout (period being contextual). It was common to discover that there were rough edges that needed resolving before it would be fair to expect ops to take full responsibility.

[DentArthurDent]

I work for a company that does network monitoring. Most of the devs run only monitoring a handful of elements, just enough to test what they're working on at the time. I decided that I was going to make my system run with more elements in an attempt to catch scale problems before they start. If I've been working on the backup code, I'll make sure I've got a job running even after I've tested and checked in to make sure that it is actually working as designed over a longer haul.

I've already found a few bugs this way. Keep testing after you're done testing is my point, I guess. :)

[spiritway]

I try to use the software I write.

++ for that. Although I know it's not always possible, I think this should be done far more often. I have often had the experience of finding some often-used feature buried deep in a menu or requiring an awkward key combination. This wouldn't happen so much, if the programmers had to use their product. They'd get tired of the menus or key-combinations, and come up with something more workable.