End of day reports?

dropstar

Hi there

Just wondering if any other software devs have to fill in EODs as part of their job, detailing all the things you did that day and sending it to a mailing list? I have to do it where I work, and I wonder if it's a common practice.

[CrimsonGhost]

Sounds like micro-management to me, and no more useful than lines of code produced any given day by a developer, which I was called up on in a previous job. If it's an option try to automate it. E.g. if you're writing code, write something to generate the mail as a list of svn/git diffs and then mail it at 6pm each evening.

dropstar

[CrimsonGhost] wrote: »

Sounds like micro-management to me, and no more useful than lines of code produced any given day by a developer, which I was called up on in a previous job. If it's an option try to automate it. E.g. if you're writing code, write something to generate the mail as a list of svn/git diffs and then mail it at 6pm each evening.

Yes my thoughts exactly. Programmers typically spend days or weeks on the same project, so if you took an EOD at face value it would look like they weren't doing anything. Development isn't the company's core business, it's very sales-centric but mgmt obviously couldn't sleep at night knowing that there weren't any KPIs being used to evaluate our team, even though we were about the only one that consistently shipped on time. Measuring programmer productivity is really hard - lines of code is fundamentally flawed as the more able programmers will write less, functionally equivalent or superior code than juniors, and language syntax will have a role too - 10 times the number of C++ for comparable LISP, for instance.
So the fact that they use EODs demonstrates how out of their depth they really are.

EODs were pitched to us initially as a tool through which different org. units within the company could communicate their current projects and share knowledge, but to me it seems like thinly-veiled micromanagement. I have thousands of EODs in my inbox from other people and i don't think we've called on a single one to see has anyone previously solved a problem we were then working on.

DublinWriter

Sounds very Dilbertesque to me.

Most I can remember would have been weekly status meetings at most, or perhaps filling out client billable hours sheets.

If I were you I would give as good as I got - if they want to play silly buggers with you then list every item in almost indecipherable management-speak, for example, 'testing' becomes 'ensuring the inherent technical quality of the up-stream product experience in the overall value-chain'.

FSL

dropstar wrote: »

EODs were pitched to us initially as a tool through which different org. units within the company could communicate their current projects and share knowledge, but to me it seems like thinly-veiled micromanagement. I have thousands of EODs in my inbox from other people and i don't think we've called on a single one to see has anyone previously solved a problem we were then working on.

Therein lies your problem. Theoretically if someone somewhere else in the organisation has already found a solution or is working on the same/ similar problem you should be able to get the solution or exchange ideas. Practically it seems a lack of format, organisation or unwillingness is rendering the system unworkable. If you followed The previous posters advice you would be taking more time to compile a useless report. Instead try and come up with a format/ key word approach which would make the system more usable and improve productivity.

kayos

Ah while its not a written report if you follow agile/scrum you give a daily status report verbally every day. This along with updating your task progress in what ever tool or if you use a physical task board (in which case your scrum master will do up the burn down etc) give as much as people need and doesn't clog up a mailbox.

My current role requires a weekly report and I hate it. Scrum just works so much better IMHO (I am a csm not that that's hard to get but does make me biased). A few of us new starts are trying to introduce agile and even if we fail to get full agile I look forward to at least having a daily scrum again.

Honestly kick your business managers in the ass and go agile. Its an easy sell and tracking velocity is all part and Parcel of the process. They get nice graphs and over time the measures they will be looking at are far better than lines of Code and track the progress of the sprint/release.

Manach

A weekly report here. Has an advantage of reminding manager what is being worked on and to revise for end of year reviews.

Beano

Item No 1 on EOD : 30 Minutes writing EOD.

See how long you get asked to do them after that.

dazberry

Did a short stint in an MN that insisted we fill them out. Very fussy about them they were too. Total PITA.

D.

cornbb

I send an EOD every day, but I work in an environment where I a) have deliverables and deadlines every day and b) need to hand off my work to others. Reading my colleagues' EODs is an invaluable source of information to me and it takes about 3 minutes to throw one together. If I forget to send it once in a while its no big deal, we don't get gip about forgetting to attach new cover sheets to the TPS reports But then again my job is unusual; yes I work in a type of software engineering role but its not a traditional one where one's work tends to be quite autonomous and deadlines come many months apart.

TL;DR EODs may or may not be a waste of time depending on the job you're doing.