Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

pjf (2464)

  (email not shown publicly)
AOL IM: miyuki3k (Add Buddy, Send Message)

I run Perl Training Australia [].

I help with Melbourne Perl Mongers.

I spend an awful lot of time talking about Perl, and have had my picture in the Australian newspapers with a camel. That's rather scary.

Journal of pjf (2464)

Sunday February 06, 2005
06:45 PM

Development - Undesirable work

[ #23054 ]

Development - Undesirable work
I'm trying to change the make-up of work that I'm regularly doing. My goal is to do more training, more course development, a few more apperances at conferences, and less development.

Despite the fact that I really do enjoy development (and testing and even documentation), the process around it is not very enjoyable. For a start not many clients actually have a good idea of what they want. Often they want a system that replaces an existing way of doing things, but actually getting them to explain that current process can be nigh impossible. Either they don't have a good process, don't understand it, consider it obvious, or just don't see why it's relevant.

All of these are hurdles that can be overcome, but they all take time, and for some clients it takes longer than others. Depending upon the client there may also be other struggles -- in some cases large amounts of paperwork and contracts, or dealing with whoever looks after their system to get things installed.

None of these are surprises, anyone who's been in the software engineering business for any length of time should know about and expect the gauntlet of processes that are required to get a system produced for your average non-technical customer. However just because they're expected doesn't mean I enjoy them, and I value enjoyment of my work quite highly.

Technical customers are a little different, since they usually don't want to outsource their development, or when they do they already have a very good idea about what needs to be done. My experience with technical customers is that I'm usually brought in (on-site) for a few days to solve a specalist problem, hunt and kill well-defined bugs, or implement a well-scoped project. Furthermore they can usually make their own improvements and bugfixes once the hard part is over.

So training and 'consulting' for technical clients usually has excellent closure, but development for non-technical clients certainly does not. Good closure is very satisfying -- you can finish a job, know that you've done a good job, and go home with a clear mind.

However poor closure usually means lots of ongoing work and revenue streams, as the client keeps coming back for more improvements and additions. I'm not bothered by this, we have an excellent turnover on courses, regular work from other sources, and the reward for effort on development work is much lower than our other categories.

The hardest thing will be saying 'no' to work. I've never been very good at that.

New comment creation has been disabled on this discussion.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login
Loading... please wait.