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 ]

jonasbn (1153)

  reversethis-{gro.napc} {ta} {nbsanoj}
AOL IM: BJonasN (Add Buddy, Send Message)

Perl Programmer located in Copenhagen, Denmark. Active member of Copenhagen Perl Mongers.

Author of:

  • Business::DK::CPR
  • Business::DK::CVR
  • Business::DK::PO
  • Business::OnlinePayment::CashCow
  • Date::Holidays
  • Date::Holidays::Abstract
  • Date::Holidays::Super
  • Date::Pregnancy
  • Games::Bingo
  • Games::Bingo::Bot
  • Games::Bingo::Print
  • Module::Info::File
  • Module::Template::Setup
  • Test::Timer

and maintainer of:

  • Tie::Tools
  • XML::Conf
  • Workflow

Journal of jonasbn (1153)

Monday January 19, 2004
03:12 PM

Meeting with the Boss

[ #16911 ]

After being relieved from my duties as team-lead for the helpdesk (application support) I adressed my manager's criticism of my efforts in an email.

This rather long mail was sent to him a little more than a week ago after a meeting where we disagreed on a lot of points and I was critized for my work as a team-lead.

In the mail I adressed the following:

The extensive focus on tasks in RT3 (the responsibility of the helpdesk)

The sole measurment on performance in RT3 (no other teams are currently monitored and measured).

The use of limited fixes and not refactorings (we have reported redundant bugs in redundant code (of course) to the development team)

The unfair comparison of the team-lead role in helpdesk and in the project groups, where I simply think that the work is too different, so a direct comparison is unfair (I might be too nitty-gritty on this one)

The proces of reporting wishes for improvements and bug fixes to the development team, where I do not think that our requests where taken serious enough and the priorities assigned was not reflecting the seriousness of our requests

My manager's view on overtime and the role of the team-lead, where he thinks that team-leads should lead the way by being role models (working overtime etc.)

The lacking focus on proper fixes, instead we treat the symptoms

The resource allocation where the development team is more focused on new projects instead of fixing the existing system

The low quality of the system

The lacking backwards propagation of the post-launch accumulated best-practices and experience (error handling, Oracle WF implementation, DLL use)

And finally my opinion on the diversity in my manager and my views on software development

So today we had a follow-up meeting, this meeting had been postponed once by me due to work load.

The meeting when somewhat as I expected. I was told "to comply" with the way things were running. My manager adressed my mail on a more general level indicating that he felt that he had met my points of critique and he saw all these things as being adressed slowly over time. He might be right that this is what will happen, but since he is not the one dealing with the day-to-day business of clearing the garbage. I do not understand why he can say that our system's quality is acceptable, perhaps my standards are too high?

Another thing was that I wanted to adress any possible refactorings/major changes/fixes to the system I should document the economic gain from such an endavour. This is already the case for the fixes we require from the development team and perhaps therefor we cannot compete with the finance, customer service and other departments - and no matter how we calculate this, they either know more about the economics or they are so many more people than us and we simply loose on head count.

I guess I knew what his answers would be and but I was disappointed hearing the words spelled out. He simply explained to me that he had to see an economic gain before allowing anything.

This kind of software development enviroment is somewhat scary to me, since it implies both an accept of a possible low quality, bugs/errors, multiple manual processes and a code base, which will become less and less appealing to work with.

Our development manager was also present at the meating, he is very skillfull and I respect him alot. Me and him have always agree on a lot of points when it comes to software development and especially the project surrounding this system.

He did not utter anything of value.

I never felt so alone in the world, I really wonder whether it is me who is a total idiot for addressing all these things, maybe I am not a good team-lead, maybe I am a bad programmer - but this does just not feel good, my gut feeling tells me it is not the right way.

I think it is time for me to move on.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • It does certainly sound as if the time is right for finding somewhere else to spend your 7.4 daily hours of rest and recreation ;-)

    I now understand your earlier log on Stagnating Career []. You have my deepest sympathy. I fear that I will be in your situation in the not to far future as the PHBs here are conviced that .Net is the owrlds greatest invention since the wheel and hot running water.

  • I once worked at a place like this. I didn't realize what a burden it was until I left.

    Run fast. Don't look back.
  • "Okay boss, you know how much it costs to fix a bug? If that bug is in code that's duplicated somewhere else in the system, double those costs. Don't forget to double the cost of actually finding the bug. If it's duplicated two other places in the system, triple the costs. Do that for every piece of duplicate code. That's the cost of not refactoring."

    • And the actual cost of bugs isn't even the cost of fixing them. It's the cost of them appearing, screwing things up for you and your customers, and the cost of cleaning up the mess. And then fixing the bug.

      Now, the cost of fixing the bug, not realizing there's a duplicate over there, ready to strike again...
      • Right.

        Now if you work in a place that would rather take the risk that bugs will not cost more than refactoring, brian has the right of it. You're better off working elsewhere, in the long term.