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 ;--)

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.)

---
It's all fine and dandy until someone has to look at the code.

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

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.

---
$world=~s/war/peace/g

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. :)

----
My mission: To boldy split infinitives that have never been split before!

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.

So, have you taken a walk around your factory floor lately? I suggest you try it soon -- you might discover some things you'd be really interested to find out.

I support manufacturing test so I'm on the actual factory floor most days! But RealVNC saves a lot of shoe-leather :) Although we don't actually manufacture anything anymore, we ship in boxes from suppliers, test the hardware and ship it out, but that seems to be the modern way.

Unfortunately, due to the amount of legacy software, the amount of small changes to the hardware we test and even the way some of the product engineers work and make change requests and even because the life of the test platform (Windows) is shorter than the life of the product, I've been on my job for just over two years and am still firefighting, not managing.

Fortunately, the code tends not to be so complicated (in a functional sense, not a maintainability sense :( ) that if it is working, we try to leave it, especially since a botched upgrade can affect production.

I've been on my job for just over two years and am still firefighting, not managing.

That's a very interesting point.

I would expect someone to be in a fire-fighting mode for the first three to six months, but after that there should be enough of an infrastructure in place that you can get onto the good stuff. Unless your managers are dumping exponentially more and more stuff on top of you.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

(And if it's all your own code, what are you managing, exactly?)

Good point. Software development is kind of a Zen thing anyway .. all this stuff is imaginary. And it's difficult for a sole developer to look at his own code, trying to find problems or solve a bug, because it's like looking in a mirror.

When I walked around the factory floor, I *was* managing -- even got addressed as 'Sir' at one point by a guy half a dozen years older than me (I looked over my shoulder, then realized he was talking to me). My title was still Junior Design Engineer, but if I reported a problem or suggested a solution, I'd discuss it with the real managers, and the change would get made.

Watching the log files recently, I was trying to detach myself from my 'developer' persona and take on a 'consultant' or 'manager' persona and watch for any anomalies in the behaviour of the application. Any problems I found I entered into the bug database, for my co-worker the SysAdmin, for the Director of Deevlopment and for the CTO to look at and ponder. After a suitable period of meditation, we'll decide what's important and/or useful and I'll go ahead and make those changes.

It's tough being a development department of one, because although you do get to do the cool stuff, you also have to do the grunt work and 100% of the support. But my job continues to be amusing and intriguing, so I guess I'll be here for a while.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

C:\>wn copacetic -over

Overview of adj copacetic

The adj copacetic has 1 sense (no senses from tagged texts)

1. copacetic, copasetic, copesetic, copesettic -- (completely 
satisfactory; "his smile said that everything was copacetic")

C:\>
[download]