|
I wasn't trying to suggest that I thought it was wrong because of the ECJ ruling. More that I think it's wrong, and the ECJ ruling supports that idea.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: He's obviously targeting the "we hate the Internet, but we love magic and other nonsense" vote.
Wait, you're basically accusing DC of being a hippy.
Alberto Brandolini: The amount of energy necessary to refute bullshit is an order of magnitude bigger than to produce it.
|
|
|
|
|
I'm a programmer working in a small 7-man team of developers for a web design studio. We work in PHP/Symfony2 (rant for another day) and use Atlassian's JIRA ticket system for tracking issues.
We also use it for logging time.
This being the first job I've had in which time logging has been mandatory (log all work, log 7.5 hours per day) I'm finding it to be a huge obstacle to my productivity. A train of thought is a fragile thing, and stopping after every little thing (sending an e-mail, making a Git commit) to log the time I've spent on it and what I did is proving to be very effective at derailing it. Couple this with the pressure to get 7.5 hours logged on something or other every single day and I'm actually starting to dread coming to work in the morning.
Not only this, we now have a completely redundant physical whiteboard full of sticky-notes representing JIRA tickets/issues that must be kept in-sync with the digital system. By hand.
We're such a small team, we're all in the same room. But every time we want to fix an issue we need to:
- Go to JIRA, mark the issue as 'In Progress'.
- Stand up, walk over the the whiteboard and move the sticky-note to the 'In Progress' column.
- Sit back down, fix the issue.
- Go to JIRA, log the time spent on the issue and write a short description of what has been changed.
- Mark the issue as 'Ready for Review'.
- Stand up again, walk over to the whiteboard and move the sticky-note to the 'Ready for Review' column.
- Go back to JIRA again and message the QA guys that there's a new sticky note in the 'Ready for Review' column.
I stress again, we're a 7-man web development team trying to be time-efficient, fast and agile. Everyone's practically going crazy about how everything takes too long. Part of it's to do with the bulky toolset we're using, but it baffles me that we can't slim down the ridiculous admin and let the developers do what they do best without having to watch the clock all the time.
So what's the verdict? Am I a crybaby or is this genuinely as silly as it all seems?
modified 2-Aug-18 21:02pm.
|
|
|
|
|
You'll probably find that this is more for whoever is bankrolling your development efforts so they can get an idea of how their money is being spent
Pain in the ass? Definitely, but it's probably keeping you employed, at least until the thing you are building starts to justify itself
Just a thought
|
|
|
|
|
That is all fouled up. Seriously? The board o doom is not meant to be such a chore. Ditching the manual board will be a great start.
|
|
|
|
|
Sounds like a real PITA.
What you might do is estimate the time spent doing the BS as opposed to actual work and submit it to the bosses. I would imagine if the time spent on BS is large enough they will find a way to slim it down?
Have you ever just looked at someone and knew the wheel was turning but the hamster was dead?
Trying to understand the behavior of some people is like trying to smell the color 9.
|
|
|
|
|
Log the time spent on logging the time and determine a percentage of total time spent. Of course, you have to log the time of logging the time and it becomes recursive.
I'm not a programmer but I play one at the office
|
|
|
|
|
Lilith.C wrote: Log the time spent on logging the time and determine a percentage of total time spent. Of course, you have to log the time of logging the time and it becomes recursive.
Exactly, then there's the time going to the coffee machine and those times when team members want to come in and talk about nothing but just interesting enough to totally distract you...well you get the picture.
Have you ever just looked at someone and knew the wheel was turning but the hamster was dead?
Trying to understand the behavior of some people is like trying to smell the color 9.
|
|
|
|
|
The board is just plain stupid. If someone (manager?) wants to see what everyone is working on when he enters the room he can but large TV and hook it up with agile JIRA dashboard - should be cheaper in a month or two considering all your trips to the board.
As for the JIRA itself.. well.. there have to be some kind of tracking where the money goes. The problem may start if client can see it as it may be sometimes hard to explain why what they see (!) as simple change took 3 days.
--
"My software never has bugs. It just develops random features."
|
|
|
|
|
Seems like a terrible waste of time and effort. Have you considered logging the time spent on logging? That may result in a one way trip to the ext door or it may communicate that this is an inefficient process.
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
I once worked for a company that briefly wanted me to log everything in 15 minute increments and submit the log weekly. After the first week I turned my log in and my boss appeared in my office shortly thereafter. Seems he wanted to know why I had 4 hours logged as "logging time" for the week. I asked if he actually knew how long it took to check your watch every few minutes to see if 15 minutes had gone by, then write down what you did for that 15 minutes, then transcribe and summarize it at the end of a week.
They trashed the time logging after I explained the process to a few coworkers.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
And I once worked for a company that demanded that all employees PLAN their next 30 day activities IN ADVANCE in 15 MINUTE INCREMENTS! I asked the VP if he wanted me to plan (and then log) my bathroom breaks before asking him how anyone could possibly plan all of their next 15 minute work increments for 30 days in advanced. An extremely broken company that I am very happy I left!
- Grant
|
|
|
|
|
Songshu Xinxu wrote: I stress again, we're a 7-man web development team
And therein lies the problem; men do not multi-task well.. you need a woman on the team to truly get multitasking done...
|
|
|
|
|
But with women on the team the men won't do any (productive) work at all anymore
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
If the woman is an above average programmer, she can do all the work.
If she's not, but above average in looks, she can probably get the men to do all her work.
If she's average, she can probably keep everyone organized enough to do all the work.
|
|
|
|
|
The manual board is seriously stupid if there is a digital system.
However, I work for a defense contractor and we must log our work to 6 minute increments. This must be logged daily for accounting and auditing purposes. We are billing the government after all.
I just keep notes when I change a task, mark the time, and continue working.
At the end of the day I fill out the reporting, which takes about 5 minutes, and I'm done. It didn't take long to get the hang of it and now it's not all that disruptive.
I'm sure there is a way to streamline your process so it seems less disruptive.
As others have said, whoever is funding the effort probably would like to see how the money is spent.
I wouldn't get too caught up in the process, and just make sure you do solid work.
|
|
|
|
|
Welcome to corporate life. They just want to see where the money is being spent. It's not too bad if they don't get really anal about it, but then again most bean counters do.
That being said, I still don't like doing it. It's retarded, but I understand why it's done.
Jeremy Falcon
|
|
|
|
|
I used Tiddlywiki, slightly modified, with the TaskTimer plugin. Bascially I click the button type a sentence then go on. Worked pretty well but I wasn't trying to track for billing purposes.
Jack of all trades, master of none, though often times better than master of one.
|
|
|
|
|
Songshu Xinxu wrote: By hand.
Songshu Xinxu wrote: Am I a crybaby or is this genuinely as silly as it all seems? Silly would be a nice understatement.
Songshu Xinxu wrote: let the developers do what they do best without having to watch the clock all
the time. Ehr.. when done right, planning time is something that is beneficial. Using it against your developers means you're not making friends.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I've worked in a number of places that try to do time logging - and usually have fought against it for its entire lack of usefulness.
First thing I did was write a small proggy (what we used to call Apps back in the day!) to log my time so I could click a button every time I did anything, type in some text, and then display it at the end of the day/week.
When I went to log my time, I had millionis of entries - 2 minutes going to the loo, time spent getting coffee or tea, talking to someone, having a meeting, responding to an email from the boss asking if I had updated my times etc. etc.
They soon had so much data it was entirely unmanageable.
There is, though, a very good reason for logging the approximate time spend on tasks - and that is to improve processes and estimation.
If a task was estimated as 1/2 day and actually takes significantly longer, it's useful to know why to prevent under-estimation in future.
PooperPig - Coming Soon
|
|
|
|
|
Jira is about time management and project costs.
The sticky notes are about communicating with other people.
Hmm.
I think I might see why developers think both are a waste of time.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
The process is sound, but you shouldn't be doing it by hand! There are plenty of programs that would do a much better job of keeping track of bug fixes and similar.
We use the Mantis bugtracker software. We haven't installed it ourselves, so I can't provide a link, but I'm sure it's not hard to look up. It does require some effort (and a server) to install, but it's much less painfull to use, works remotely without additional effort, and even lets you view the entire history of a given issue, in case it keeps popping up. There are other systems that may be commercial, may focus on other capabilities, and may be easier or harder to use or install. You just need to find the one that does the best job for you.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I think they're asking you to waste your time. I can see the advantages of measuring the metrics however they must realise that pointless admin takes time.
I do record what I work on in a spreadsheet, however I do not include hours spent on a task. I record the tasks I work on for my own benefit as I am constantly switching and need to keep track of what types of work I do overall.
Simon Lee Shugar (Software Developer)
www.simonshugar.co.uk
"If something goes by a false name, would it mean that thing is fake? False by nature?" By Gilbert Durandil
|
|
|
|
|
Pardon my comment, i am retired now... But I would never give a work to do to an enterprise wasting so much time doing things by HAND! Are U an IT firm?
|
|
|
|
|
We did some time logging on one sprint but developers estimated how much time was spent on tasks like email, meetings, support, etc.
We found that development took up about 35% of the week.
Since then the number of meetings has shrunk dramatically and everyone manages email better.
I estimate that some 70% of the time is now spent in development and the team ( about the same size as yours) have become far more productive.
I try to note at the end of the day what I have done, since it will be needed for my performance review, but I try to ensure it takes no more than a minute or two. And then summarise ( again in 5 minutes) at the end of the month.
|
|
|
|