Re: Typical work day
- From: "Phlip" <phlipcpp@xxxxxxxxx>
- Date: Thu, 29 Sep 2005 04:01:17 GMT
Anon wrote:
> Just checked back to see and they were related to additional "minor" tasks
> and modifications to existing programs. None to do with the current main
> project, but all work related. There weren't too many of these emails
> actually, most of the others were automatic error reports from programs,
> messages directed to the wrong person or messages sent to all staff (new
> procedures for reporting mistakes made by other departments, that sort of
> thing).
The pattern here is of firefighting, again.
> Well he didn't actually send an email until after 4pm, it was all oral
> before that but at many different points throughout the day. I guess I
> should mention that he sits directly adjacant to me.
Yay! That changes the nature of interruptions; the disruptions. You can
track what he's up to out of the corner of your eye, and not be surprised.
> There's about 80 staff in total in the company. In the IT department there
> is me and 2 other windows developers, a web developer, assistant web
> developer (who started last week) and a network administrator. Here's the
> rough history of of staff within the department... (sorry if this is a bit
> lengthy)
Okay, the IT department has programming and firefighting. No, this is not
typical. Programming and helpdesk should be separate in process (even if the
same people work with them).
> My workload increased dramatically after the other programmer left as I
> inherited all his code. During the time we were both there, he was fixing
> bugs and fulfilling minor change requests for his existing programs all of
> the time without any time left for new projects.
Because this has been going on for a while, the code is showing the effects
of years of frequent interruptions. If you can't spend time after writing a
feature to polish the code and clean it up, then when you get interrupted
later to fix it, you will forget how it works, and your patch will reduce
quality.
> He refused to let anyone
> see his code
That is a crisis.
> (even the IT manager couldn't get access as he had no control
> other this other programmer who was a relative of the managing director).
Ouch.
> I
> inherited over a hundred bug-ridden VB programs with Z1 to Z56 or whatever
> as the variable names (all globals) and functions that dealt with getting
> the difference between 2 dates by storing the dates as strings and
> extracting the month, day, etc instead of just using DateDiff() and the
> Date
> datatype. For quite a long time after that most of my time was used up on
> maintenance of these programs (combination of changes in the company
> causing
> these programs to break easily plus new feature requests). Fortunately
> we're
> now at a level where many of these programs have been replaced and the
> rest
> are fairly stable (though still difficult to extend).
Okay, now these quality issues have been compounded by the interruption
schedule. Your shop needs some rules.
>> do you have a "helpdesk ticket" system to triage
>> these requests?
>
> No, but we could do with such a system. I'll pass the suggestion on, but
> to
> be honest I think if one was developed nobody would bother using it.
"Developed"? You do understand you should just download and install one,
right?
> The managing director originally wanted
> the whole project completed the same day, which we told him was
> impossible.
> He came in the next day shouting stuff like "I wanted this done by the end
> of yesterday - I feel like I'm talking to a brick wall!" etc.
If you had a ticket system, the developer would estimate the time to
complete each ticket. The average of these estimates (and actuals) is your
Velocity, and it's very reliable.
Without it, frustration bubbles up, so bosses see fit to "estimate" for you.
This is incredibly wrong and abusive. Only developers should estimate.
But without tickets, without sustained flow, without timeboxed iterations,
no time estimates will be worthwhile. Let the boss scream, and work on what
it screamed loudest over.
>> (Did it have automated unit tests, written at the same time?)
>
> If it was inner code that actually did the work and accessed the database
> etc and it's what I'm thinking of (work on a re-usable product class - we
> don't actually have a proper business layer and I'm trying to build one up
> by putting code required for various projects into a re-usable library)
> then
> I think it had a small amount of testing code done at the same time (very
> brief so I wouldn't even really call it a unit test). If it was user
> interface work then no.
Do y'all run the tests over and over again?
> Yes, though in many cases someone who is stuck can consult someone else
> who
> uses the same software to find out, there is nobody specifically to deal
> with tech support and it usually ends up being whichever developer
> produced
> the software.
I suspect the ticket systems support the ability to generate a knowledge
base.
> don't think anyone really ever bothered checking the help files.
That's why I Google USENET before reading the help files. If at all. True
FAQs - things frequently _asked_ - are better indexes for answers than all
the help files in the world.
> Generally nowadays though we're instructed not to waste time on
> documentation. The good news is I think our company may be employing
> someone
> specifically for the purpose of writing documentation soon. The bad news
> is
> I don't know how long it'll last - we got our first system analyst about a
> month ago and from day 1 he ended up doing human resources leaving no time
> for his real job (he's since left the company for this very reason).
Right. Throwing more people at the situation - more roles - won't work.
You guys need to get a helpdesk ticket system and _enforce_ it. Put a sign
on the door to the IT room saying "did you write a ticket for that?"
Any verbal request, any channel, you bounce it with that question. Then
_reward_ people for using the system by doing everything you can too keep
its backlog short.
Next...
> Certainly, I think you have helped highlight this issue. I read somewhere
> recently that for small development teams it's an idea for programmer 1 to
> do development in the morning, tech support in the afternoon. Programmer 2
> does the opposite. Unfortunately this wouldn't really work for us since we
> mostly have our own programs that we know, and don't see that much of each
> others code.
The lack of interchangability is part of the problem. Make a real effort to
learn to work on each others' modules. Pair program, then do this trick:
Take the keyboard, and say "now tell me exactly what to type". You will
learn the techniques your colleague was using to manage their code.
> ...code reviews..."we don't have time!"...comment my code...
Those techniques add time to the schedule. I'm talking about techniques that
force the time down between completing each little task. Forget comments
until you can write them for your colleagues' modules.
> A lot of the problem with recording things is the time it actually takes
> to
> record and the fact that there's a "drop everything and do this right now"
> to every request from the managing director. When he makes a demand and
> stands behind you saying "tick tock tick tock tick tock"
I hope you are kidding. Managers must _not_ do that; it's a form of
bullying, and it betrays the most blatant insecurities.
--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
.
- Follow-Ups:
- Re: Typical work day
- From: Anon
- Re: Typical work day
- References:
- Typical work day
- From: Anon
- Re: Typical work day
- From: Phlip
- Re: Typical work day
- From: Anon
- Typical work day
- Prev by Date: Re: Question
- Next by Date: Re: subset function for string in c++
- Previous by thread: Re: Typical work day
- Next by thread: Re: Typical work day
- Index(es):
Relevant Pages
|
