Stories
Slash Boxes
Comments
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 ]

nite_man (3972)

nite_man
  (email not shown publicly)
http://stepanoff.org/
Yahoo! ID: nite_man_2001 (Add User, Send Message)

Journal of nite_man (3972)

Friday June 17, 2005
02:08 AM

Why I don't satisfy my work

[ #25248 ]

After developing a billing system (pure Perl application) for a company where I work during three years I've understood that it's terrible for programmers to develop some application for their company!

I can explain why. Let's see the application for some external customer. You have a specification and if customer wants to change it you can free-hearted to charge him additional payment. Also, you can (possibly have to) do it if customer will ask you make some changes after release. Another thing is release. You have to follow a time schedule and release the application timely. Especially for me, the release is associated with a milestone. I can see the product of my work after its releasing. It's like evolution!

In case some internal application very very often there are not any specifications. Moreover, sometimes developers have a rough idea how the application will develop. Dead-line in that kind of projects is not so strong and releases are not created. Because, the application is modified often (in my case, around 10 times per day).

Also, people come to you and ask "Let's do that". Ok, you do. After some time they came again and ask "Let's do this". But you already did 'that' ( the company shouldn't pay in advanced for every addition changes). And this process is perpetual! You don't have a clear specification, you don't have releases, you cannot find satisfaction in your work.

That why I hate this kind of projects and I don't satisfy my work! Sure, it's only my opinion and possibily other people have better examples of thier work.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • We have a fair number of internal projects at work too, but, we insist on doing them the same way as external projects - Enhancements have to be specced up, documented, original project needs to be completely specified. Your manager should be a buffer between you and feature requests... Insist on this, show your boss how much more beneficial it is, etc