Mixing
How effective is time recording software? [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
-3
down vote
favorite
Many local software companies expect their employees to log the time they spend at work against tasks in some time recording software. This is usually to track how long employees take to complete specific tasks, but is often also intended to see that tasks remain within the expected estimates.
Can these objectives really be achieved by the use of time recording software? Arguably, time recording software can greatly constrain developers who need to be dynamic in the face of changing requirements, cross-cutting concerns, design decisions, function points with unknowns requiring research, etc.
In my experience it is simply not possible to categorise every little thing, nor is it possible to accurately estimate every little thing, especially where unknowns are involved. Rather than forcing employees to get in line with the estimates, such software tends to show that the estimates were wrong in the first place.
How effective is time recording software in reality, especially within the software development industry?
software-industry time-management
asked Sep 13 '14 at 7:20
Gigi
999612
closed as primarily opinion-based by Jim G., Jan Doggen, gnat, David S., IDrinkandIKnowThings Sep 15 '14 at 13:34
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
 |Â
show 2 more comments
up vote
-3
down vote
favorite
Many local software companies expect their employees to log the time they spend at work against tasks in some time recording software. This is usually to track how long employees take to complete specific tasks, but is often also intended to see that tasks remain within the expected estimates.
Can these objectives really be achieved by the use of time recording software? Arguably, time recording software can greatly constrain developers who need to be dynamic in the face of changing requirements, cross-cutting concerns, design decisions, function points with unknowns requiring research, etc.
In my experience it is simply not possible to categorise every little thing, nor is it possible to accurately estimate every little thing, especially where unknowns are involved. Rather than forcing employees to get in line with the estimates, such software tends to show that the estimates were wrong in the first place.
How effective is time recording software in reality, especially within the software development industry?
software-industry time-management
asked Sep 13 '14 at 7:20
Gigi
999612
closed as primarily opinion-based by Jim G., Jan Doggen, gnat, David S., IDrinkandIKnowThings Sep 15 '14 at 13:34
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
Just to clarify, do you mean a system where the employees fill out a time sheet of some sort? E.g. "9 to 10.15am: Meeting about client A" Or do you mean a more complex project management software; something like Atlassian?
– Alpar
Sep 13 '14 at 9:05
The former. But if you would like to compare both approaches, by all means go ahead.
– Gigi
Sep 13 '14 at 9:40
it's not only about log what the employees are doing, it's also about to bill the hours to the customer.
– Guido Preite
Sep 13 '14 at 10:53
That isn't the case when the projects are fixed-price.
– Gigi
Sep 13 '14 at 11:17
1
and how they can measure the profitability of a fixed-price project if they don't know how many hours took to complete the project?
– Guido Preite
Sep 14 '14 at 6:49
 |Â
show 2 more comments
up vote
-3
down vote
favorite
up vote
-3
down vote
favorite
Many local software companies expect their employees to log the time they spend at work against tasks in some time recording software. This is usually to track how long employees take to complete specific tasks, but is often also intended to see that tasks remain within the expected estimates.
Can these objectives really be achieved by the use of time recording software? Arguably, time recording software can greatly constrain developers who need to be dynamic in the face of changing requirements, cross-cutting concerns, design decisions, function points with unknowns requiring research, etc.
In my experience it is simply not possible to categorise every little thing, nor is it possible to accurately estimate every little thing, especially where unknowns are involved. Rather than forcing employees to get in line with the estimates, such software tends to show that the estimates were wrong in the first place.
How effective is time recording software in reality, especially within the software development industry?
software-industry time-management
asked Sep 13 '14 at 7:20
Gigi
999612
Many local software companies expect their employees to log the time they spend at work against tasks in some time recording software. This is usually to track how long employees take to complete specific tasks, but is often also intended to see that tasks remain within the expected estimates.
Can these objectives really be achieved by the use of time recording software? Arguably, time recording software can greatly constrain developers who need to be dynamic in the face of changing requirements, cross-cutting concerns, design decisions, function points with unknowns requiring research, etc.
In my experience it is simply not possible to categorise every little thing, nor is it possible to accurately estimate every little thing, especially where unknowns are involved. Rather than forcing employees to get in line with the estimates, such software tends to show that the estimates were wrong in the first place.
How effective is time recording software in reality, especially within the software development industry?
software-industry time-management
asked Sep 13 '14 at 7:20
Gigi
999612
asked Sep 13 '14 at 7:20
Gigi
999612
asked Sep 13 '14 at 7:20
Gigi
999612
asked Sep 13 '14 at 7:20
Gigi
999612
999612
closed as primarily opinion-based by Jim G., Jan Doggen, gnat, David S., IDrinkandIKnowThings Sep 15 '14 at 13:34
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as primarily opinion-based by Jim G., Jan Doggen, gnat, David S., IDrinkandIKnowThings Sep 15 '14 at 13:34
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
Just to clarify, do you mean a system where the employees fill out a time sheet of some sort? E.g. "9 to 10.15am: Meeting about client A" Or do you mean a more complex project management software; something like Atlassian?
– Alpar
Sep 13 '14 at 9:05
The former. But if you would like to compare both approaches, by all means go ahead.
– Gigi
Sep 13 '14 at 9:40
it's not only about log what the employees are doing, it's also about to bill the hours to the customer.
– Guido Preite
Sep 13 '14 at 10:53
That isn't the case when the projects are fixed-price.
– Gigi
Sep 13 '14 at 11:17
1
and how they can measure the profitability of a fixed-price project if they don't know how many hours took to complete the project?
– Guido Preite
Sep 14 '14 at 6:49
 |Â
show 2 more comments
Just to clarify, do you mean a system where the employees fill out a time sheet of some sort? E.g. "9 to 10.15am: Meeting about client A" Or do you mean a more complex project management software; something like Atlassian?
– Alpar
Sep 13 '14 at 9:05
The former. But if you would like to compare both approaches, by all means go ahead.
– Gigi
Sep 13 '14 at 9:40
it's not only about log what the employees are doing, it's also about to bill the hours to the customer.
– Guido Preite
Sep 13 '14 at 10:53
That isn't the case when the projects are fixed-price.
– Gigi
Sep 13 '14 at 11:17
1
and how they can measure the profitability of a fixed-price project if they don't know how many hours took to complete the project?
– Guido Preite
Sep 14 '14 at 6:49
Just to clarify, do you mean a system where the employees fill out a time sheet of some sort? E.g. "9 to 10.15am: Meeting about client A" Or do you mean a more complex project management software; something like Atlassian?
– Alpar
Sep 13 '14 at 9:05
Just to clarify, do you mean a system where the employees fill out a time sheet of some sort? E.g. "9 to 10.15am: Meeting about client A" Or do you mean a more complex project management software; something like Atlassian?
– Alpar
Sep 13 '14 at 9:05
The former. But if you would like to compare both approaches, by all means go ahead.
– Gigi
Sep 13 '14 at 9:40
The former. But if you would like to compare both approaches, by all means go ahead.
– Gigi
Sep 13 '14 at 9:40
it's not only about log what the employees are doing, it's also about to bill the hours to the customer.
– Guido Preite
Sep 13 '14 at 10:53
it's not only about log what the employees are doing, it's also about to bill the hours to the customer.
– Guido Preite
Sep 13 '14 at 10:53
That isn't the case when the projects are fixed-price.
– Gigi
Sep 13 '14 at 11:17
That isn't the case when the projects are fixed-price.
– Gigi
Sep 13 '14 at 11:17
1
1
and how they can measure the profitability of a fixed-price project if they don't know how many hours took to complete the project?
– Guido Preite
Sep 14 '14 at 6:49
and how they can measure the profitability of a fixed-price project if they don't know how many hours took to complete the project?
– Guido Preite
Sep 14 '14 at 6:49
 |Â
show 2 more comments
3 Answers
3
active
oldest
votes
up vote
4
down vote
accepted
The only legitimate use I know of for this kind of tool is when you're billing your customers by the hour. In that case, knowing how many hours are spent on each customer as opposed to on company support tasks -- especially if some of your people are supporting multiple customers at once -- is legitimate. A classic example of this is US Government contracts, where they really insist that you keep those records.
As a tool for managing staff: It's ridiculous. Reducto ad absurdam: Say you've got someone who gets more done each week than anyone else in the group despite never showing up on Fridays. Do you really want to complain about the Fridays, dock his pay, and risk losing this star player?
answered Sep 13 '14 at 14:19
keshlam
41.5k1267144
Billing by the hour isn't the only legitimate use. If you're doing fixed-price work, it's important to estimate the time required for various tasks so that you can submit a bid that accurately reflects the time the project will take (you may not end up billing by the hour, but bidding $4000 job that ultimately consumes $8000 worth of employee time is bad for business). If you record how long tasks take, you can use that information for future projects to scope & estimate similar tasks in those projects - we know it'll take X hours to build a server, Y hours to set up a database, etc.
– alroc
Sep 13 '14 at 20:40
2
@alroc - You can gather those metrics without wasting time by trying to keep tedious, meticulous, and ultimately, inaccurate records of how much time was spent on every little task. If you simply assign a story-point estimate to each top-level task and track how many story-points, on average, get completed every week or so, you'll get velocity data that is just as good and with a fraction of the overhead to boot. There's a reason practically everyone is doing Agile now.
– aroth
Sep 14 '14 at 1:33
@aroth - even if you don't know how much time your developers had taken up by support tasks for other clients in any given week?
– Carson63000
Sep 14 '14 at 4:42
@Carson63000 - Yes. It's the law of averages. There will almost always be at least some support tasks, meetings, or other distractions. So while individual datapoints may show some variance between one and the next, if you average a handful of them together you get a reasonably accurate result. The point is to do your monitoring/benchmarking over a large enough span of time that your transient minimas and maximas cancel each other out.
– aroth
Sep 14 '14 at 4:57
suggest improvements |Â
up vote
3
down vote
Time and motion study and work measurement are techniques used in manufacturing and process industries to check the time required by a worker to complete a task, thereby arrive at time required for optimum results, estimate maximum and minimum production capacity and so on. In software industry programmers are paid according to number of hours put in to write software. If some guys are lazy and slow , will they get more money ? Those who are smart and fast will be paid less ? Historically, the English classic littérateur would be paid according to number of pages, hence all standard classical books are massive with author's fancy descriptions and long passages. This simply cannot be taken as efficient work, hence not applicable to software industry.
answered Sep 13 '14 at 9:06
AAI
604412
1
Exactly, you can't run a software company like you'd run a factory. If we're going to grade our work based on number of hours, we might as well grade it using the number of lines of code, which I think you'll agree is quite stupid.
– Gigi
Sep 13 '14 at 11:19
2
"In software industry programmers are paid according to number of hours put in to write software" - Careful. Most of the programmers I know are salaried, and get paid the same whether they put in a 40 hour week or a 60 hour week.
– aroth
Sep 14 '14 at 1:29
1
@aroth I guess that depends on where you're from. Over here, if you do more than 40 hours you are usually paid overtime (but not always).
– Gigi
Sep 14 '14 at 8:10
suggest improvements |Â
up vote
0
down vote
Keeping track of your time, reporting your time, and getting stuff done precisely in the time originally estimated for that stuff are three entirely different things.
- tracking your time (using something informal like a piece of paper, a spreadsheet, a journaling app on your phone that your employers never see) is incredibly effective. Whether you want know just how much time you spend waiting for conference calls to start or wading through emails, or compare which of your fixed-revenue buckets-of-work are making you more per hour, tracking your time is vital
- reporting your time is sometimes useful, depending on who you're reporting it to. Management needs to know "that took us ten hours because of changing requirements, cross-cutting concerns, design decisions, function points with unknowns requiring research, etc but we are only able to bill two as in the original estimate." Making sure they know this is the only way you will ever get out of unpaid overtime, apologizing for lateness you didn't cause, etc
- pretending something only took two hours because that's all you can bill for it, and hiding the other eight somewhere else or not reporting it, is not effective at all - and if you work somewhere that demands you do so, deal (if you can) with that, not with the tracking and reporting of time.
Some people have had success by creating a non billable bucket called "churn and backtrack due to communication issues" and letting numbers pile up in there until someone does something about it. However it's entirely possible that the someone is you, the bucket is also called "unpaid overtime that I was supposed to apologize for spending", and the something you do is change jobs. But should that happen, you'll be doing it for a sensible logical reason after tracking what's been happening for a while, and not impulsively because you feel things aren't fair lately.
answered Sep 14 '14 at 15:45
Kate Gregory
105k40232334
suggest improvements |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
The only legitimate use I know of for this kind of tool is when you're billing your customers by the hour. In that case, knowing how many hours are spent on each customer as opposed to on company support tasks -- especially if some of your people are supporting multiple customers at once -- is legitimate. A classic example of this is US Government contracts, where they really insist that you keep those records.
As a tool for managing staff: It's ridiculous. Reducto ad absurdam: Say you've got someone who gets more done each week than anyone else in the group despite never showing up on Fridays. Do you really want to complain about the Fridays, dock his pay, and risk losing this star player?
answered Sep 13 '14 at 14:19
keshlam
41.5k1267144
Billing by the hour isn't the only legitimate use. If you're doing fixed-price work, it's important to estimate the time required for various tasks so that you can submit a bid that accurately reflects the time the project will take (you may not end up billing by the hour, but bidding $4000 job that ultimately consumes $8000 worth of employee time is bad for business). If you record how long tasks take, you can use that information for future projects to scope & estimate similar tasks in those projects - we know it'll take X hours to build a server, Y hours to set up a database, etc.
– alroc
Sep 13 '14 at 20:40
2
@alroc - You can gather those metrics without wasting time by trying to keep tedious, meticulous, and ultimately, inaccurate records of how much time was spent on every little task. If you simply assign a story-point estimate to each top-level task and track how many story-points, on average, get completed every week or so, you'll get velocity data that is just as good and with a fraction of the overhead to boot. There's a reason practically everyone is doing Agile now.
– aroth
Sep 14 '14 at 1:33
@aroth - even if you don't know how much time your developers had taken up by support tasks for other clients in any given week?
– Carson63000
Sep 14 '14 at 4:42
@Carson63000 - Yes. It's the law of averages. There will almost always be at least some support tasks, meetings, or other distractions. So while individual datapoints may show some variance between one and the next, if you average a handful of them together you get a reasonably accurate result. The point is to do your monitoring/benchmarking over a large enough span of time that your transient minimas and maximas cancel each other out.
– aroth
Sep 14 '14 at 4:57
suggest improvements |Â
up vote
4
down vote
accepted
The only legitimate use I know of for this kind of tool is when you're billing your customers by the hour. In that case, knowing how many hours are spent on each customer as opposed to on company support tasks -- especially if some of your people are supporting multiple customers at once -- is legitimate. A classic example of this is US Government contracts, where they really insist that you keep those records.
As a tool for managing staff: It's ridiculous. Reducto ad absurdam: Say you've got someone who gets more done each week than anyone else in the group despite never showing up on Fridays. Do you really want to complain about the Fridays, dock his pay, and risk losing this star player?
answered Sep 13 '14 at 14:19
keshlam
41.5k1267144
Billing by the hour isn't the only legitimate use. If you're doing fixed-price work, it's important to estimate the time required for various tasks so that you can submit a bid that accurately reflects the time the project will take (you may not end up billing by the hour, but bidding $4000 job that ultimately consumes $8000 worth of employee time is bad for business). If you record how long tasks take, you can use that information for future projects to scope & estimate similar tasks in those projects - we know it'll take X hours to build a server, Y hours to set up a database, etc.
– alroc
Sep 13 '14 at 20:40
2
@alroc - You can gather those metrics without wasting time by trying to keep tedious, meticulous, and ultimately, inaccurate records of how much time was spent on every little task. If you simply assign a story-point estimate to each top-level task and track how many story-points, on average, get completed every week or so, you'll get velocity data that is just as good and with a fraction of the overhead to boot. There's a reason practically everyone is doing Agile now.
– aroth
Sep 14 '14 at 1:33
@aroth - even if you don't know how much time your developers had taken up by support tasks for other clients in any given week?
– Carson63000
Sep 14 '14 at 4:42
@Carson63000 - Yes. It's the law of averages. There will almost always be at least some support tasks, meetings, or other distractions. So while individual datapoints may show some variance between one and the next, if you average a handful of them together you get a reasonably accurate result. The point is to do your monitoring/benchmarking over a large enough span of time that your transient minimas and maximas cancel each other out.
– aroth
Sep 14 '14 at 4:57
suggest improvements |Â
up vote
4
down vote
accepted
up vote
4
down vote
accepted
The only legitimate use I know of for this kind of tool is when you're billing your customers by the hour. In that case, knowing how many hours are spent on each customer as opposed to on company support tasks -- especially if some of your people are supporting multiple customers at once -- is legitimate. A classic example of this is US Government contracts, where they really insist that you keep those records.
As a tool for managing staff: It's ridiculous. Reducto ad absurdam: Say you've got someone who gets more done each week than anyone else in the group despite never showing up on Fridays. Do you really want to complain about the Fridays, dock his pay, and risk losing this star player?
answered Sep 13 '14 at 14:19
keshlam
41.5k1267144
The only legitimate use I know of for this kind of tool is when you're billing your customers by the hour. In that case, knowing how many hours are spent on each customer as opposed to on company support tasks -- especially if some of your people are supporting multiple customers at once -- is legitimate. A classic example of this is US Government contracts, where they really insist that you keep those records.
As a tool for managing staff: It's ridiculous. Reducto ad absurdam: Say you've got someone who gets more done each week than anyone else in the group despite never showing up on Fridays. Do you really want to complain about the Fridays, dock his pay, and risk losing this star player?
answered Sep 13 '14 at 14:19
keshlam
41.5k1267144
answered Sep 13 '14 at 14:19
keshlam
41.5k1267144
answered Sep 13 '14 at 14:19
keshlam
41.5k1267144
answered Sep 13 '14 at 14:19
keshlam
41.5k1267144
41.5k1267144
Billing by the hour isn't the only legitimate use. If you're doing fixed-price work, it's important to estimate the time required for various tasks so that you can submit a bid that accurately reflects the time the project will take (you may not end up billing by the hour, but bidding $4000 job that ultimately consumes $8000 worth of employee time is bad for business). If you record how long tasks take, you can use that information for future projects to scope & estimate similar tasks in those projects - we know it'll take X hours to build a server, Y hours to set up a database, etc.
– alroc
Sep 13 '14 at 20:40
2
@alroc - You can gather those metrics without wasting time by trying to keep tedious, meticulous, and ultimately, inaccurate records of how much time was spent on every little task. If you simply assign a story-point estimate to each top-level task and track how many story-points, on average, get completed every week or so, you'll get velocity data that is just as good and with a fraction of the overhead to boot. There's a reason practically everyone is doing Agile now.
– aroth
Sep 14 '14 at 1:33
@aroth - even if you don't know how much time your developers had taken up by support tasks for other clients in any given week?
– Carson63000
Sep 14 '14 at 4:42
@Carson63000 - Yes. It's the law of averages. There will almost always be at least some support tasks, meetings, or other distractions. So while individual datapoints may show some variance between one and the next, if you average a handful of them together you get a reasonably accurate result. The point is to do your monitoring/benchmarking over a large enough span of time that your transient minimas and maximas cancel each other out.
– aroth
Sep 14 '14 at 4:57
suggest improvements |Â
Billing by the hour isn't the only legitimate use. If you're doing fixed-price work, it's important to estimate the time required for various tasks so that you can submit a bid that accurately reflects the time the project will take (you may not end up billing by the hour, but bidding $4000 job that ultimately consumes $8000 worth of employee time is bad for business). If you record how long tasks take, you can use that information for future projects to scope & estimate similar tasks in those projects - we know it'll take X hours to build a server, Y hours to set up a database, etc.
– alroc
Sep 13 '14 at 20:40
2
@alroc - You can gather those metrics without wasting time by trying to keep tedious, meticulous, and ultimately, inaccurate records of how much time was spent on every little task. If you simply assign a story-point estimate to each top-level task and track how many story-points, on average, get completed every week or so, you'll get velocity data that is just as good and with a fraction of the overhead to boot. There's a reason practically everyone is doing Agile now.
– aroth
Sep 14 '14 at 1:33
@aroth - even if you don't know how much time your developers had taken up by support tasks for other clients in any given week?
– Carson63000
Sep 14 '14 at 4:42
@Carson63000 - Yes. It's the law of averages. There will almost always be at least some support tasks, meetings, or other distractions. So while individual datapoints may show some variance between one and the next, if you average a handful of them together you get a reasonably accurate result. The point is to do your monitoring/benchmarking over a large enough span of time that your transient minimas and maximas cancel each other out.
– aroth
Sep 14 '14 at 4:57
Billing by the hour isn't the only legitimate use. If you're doing fixed-price work, it's important to estimate the time required for various tasks so that you can submit a bid that accurately reflects the time the project will take (you may not end up billing by the hour, but bidding $4000 job that ultimately consumes $8000 worth of employee time is bad for business). If you record how long tasks take, you can use that information for future projects to scope & estimate similar tasks in those projects - we know it'll take X hours to build a server, Y hours to set up a database, etc.
– alroc
Sep 13 '14 at 20:40
Billing by the hour isn't the only legitimate use. If you're doing fixed-price work, it's important to estimate the time required for various tasks so that you can submit a bid that accurately reflects the time the project will take (you may not end up billing by the hour, but bidding $4000 job that ultimately consumes $8000 worth of employee time is bad for business). If you record how long tasks take, you can use that information for future projects to scope & estimate similar tasks in those projects - we know it'll take X hours to build a server, Y hours to set up a database, etc.
– alroc
Sep 13 '14 at 20:40
2
2
@alroc - You can gather those metrics without wasting time by trying to keep tedious, meticulous, and ultimately, inaccurate records of how much time was spent on every little task. If you simply assign a story-point estimate to each top-level task and track how many story-points, on average, get completed every week or so, you'll get velocity data that is just as good and with a fraction of the overhead to boot. There's a reason practically everyone is doing Agile now.
– aroth
Sep 14 '14 at 1:33
@alroc - You can gather those metrics without wasting time by trying to keep tedious, meticulous, and ultimately, inaccurate records of how much time was spent on every little task. If you simply assign a story-point estimate to each top-level task and track how many story-points, on average, get completed every week or so, you'll get velocity data that is just as good and with a fraction of the overhead to boot. There's a reason practically everyone is doing Agile now.
– aroth
Sep 14 '14 at 1:33
@aroth - even if you don't know how much time your developers had taken up by support tasks for other clients in any given week?
– Carson63000
Sep 14 '14 at 4:42
@aroth - even if you don't know how much time your developers had taken up by support tasks for other clients in any given week?
– Carson63000
Sep 14 '14 at 4:42
@Carson63000 - Yes. It's the law of averages. There will almost always be at least some support tasks, meetings, or other distractions. So while individual datapoints may show some variance between one and the next, if you average a handful of them together you get a reasonably accurate result. The point is to do your monitoring/benchmarking over a large enough span of time that your transient minimas and maximas cancel each other out.
– aroth
Sep 14 '14 at 4:57
@Carson63000 - Yes. It's the law of averages. There will almost always be at least some support tasks, meetings, or other distractions. So while individual datapoints may show some variance between one and the next, if you average a handful of them together you get a reasonably accurate result. The point is to do your monitoring/benchmarking over a large enough span of time that your transient minimas and maximas cancel each other out.
– aroth
Sep 14 '14 at 4:57
suggest improvements |Â
up vote
3
down vote
Time and motion study and work measurement are techniques used in manufacturing and process industries to check the time required by a worker to complete a task, thereby arrive at time required for optimum results, estimate maximum and minimum production capacity and so on. In software industry programmers are paid according to number of hours put in to write software. If some guys are lazy and slow , will they get more money ? Those who are smart and fast will be paid less ? Historically, the English classic littérateur would be paid according to number of pages, hence all standard classical books are massive with author's fancy descriptions and long passages. This simply cannot be taken as efficient work, hence not applicable to software industry.
answered Sep 13 '14 at 9:06
AAI
604412
1
Exactly, you can't run a software company like you'd run a factory. If we're going to grade our work based on number of hours, we might as well grade it using the number of lines of code, which I think you'll agree is quite stupid.
– Gigi
Sep 13 '14 at 11:19
2
"In software industry programmers are paid according to number of hours put in to write software" - Careful. Most of the programmers I know are salaried, and get paid the same whether they put in a 40 hour week or a 60 hour week.
– aroth
Sep 14 '14 at 1:29
1
@aroth I guess that depends on where you're from. Over here, if you do more than 40 hours you are usually paid overtime (but not always).
– Gigi
Sep 14 '14 at 8:10
suggest improvements |Â
up vote
3
down vote
Time and motion study and work measurement are techniques used in manufacturing and process industries to check the time required by a worker to complete a task, thereby arrive at time required for optimum results, estimate maximum and minimum production capacity and so on. In software industry programmers are paid according to number of hours put in to write software. If some guys are lazy and slow , will they get more money ? Those who are smart and fast will be paid less ? Historically, the English classic littérateur would be paid according to number of pages, hence all standard classical books are massive with author's fancy descriptions and long passages. This simply cannot be taken as efficient work, hence not applicable to software industry.
answered Sep 13 '14 at 9:06
AAI
604412
1
Exactly, you can't run a software company like you'd run a factory. If we're going to grade our work based on number of hours, we might as well grade it using the number of lines of code, which I think you'll agree is quite stupid.
– Gigi
Sep 13 '14 at 11:19
2
"In software industry programmers are paid according to number of hours put in to write software" - Careful. Most of the programmers I know are salaried, and get paid the same whether they put in a 40 hour week or a 60 hour week.
– aroth
Sep 14 '14 at 1:29
1
@aroth I guess that depends on where you're from. Over here, if you do more than 40 hours you are usually paid overtime (but not always).
– Gigi
Sep 14 '14 at 8:10
suggest improvements |Â
up vote
3
down vote
up vote
3
down vote
Time and motion study and work measurement are techniques used in manufacturing and process industries to check the time required by a worker to complete a task, thereby arrive at time required for optimum results, estimate maximum and minimum production capacity and so on. In software industry programmers are paid according to number of hours put in to write software. If some guys are lazy and slow , will they get more money ? Those who are smart and fast will be paid less ? Historically, the English classic littérateur would be paid according to number of pages, hence all standard classical books are massive with author's fancy descriptions and long passages. This simply cannot be taken as efficient work, hence not applicable to software industry.
answered Sep 13 '14 at 9:06
AAI
604412
Time and motion study and work measurement are techniques used in manufacturing and process industries to check the time required by a worker to complete a task, thereby arrive at time required for optimum results, estimate maximum and minimum production capacity and so on. In software industry programmers are paid according to number of hours put in to write software. If some guys are lazy and slow , will they get more money ? Those who are smart and fast will be paid less ? Historically, the English classic littérateur would be paid according to number of pages, hence all standard classical books are massive with author's fancy descriptions and long passages. This simply cannot be taken as efficient work, hence not applicable to software industry.
answered Sep 13 '14 at 9:06
AAI
604412
answered Sep 13 '14 at 9:06
AAI
604412
answered Sep 13 '14 at 9:06
AAI
604412
answered Sep 13 '14 at 9:06
AAI
604412
604412
1
Exactly, you can't run a software company like you'd run a factory. If we're going to grade our work based on number of hours, we might as well grade it using the number of lines of code, which I think you'll agree is quite stupid.
– Gigi
Sep 13 '14 at 11:19
2
"In software industry programmers are paid according to number of hours put in to write software" - Careful. Most of the programmers I know are salaried, and get paid the same whether they put in a 40 hour week or a 60 hour week.
– aroth
Sep 14 '14 at 1:29
1
@aroth I guess that depends on where you're from. Over here, if you do more than 40 hours you are usually paid overtime (but not always).
– Gigi
Sep 14 '14 at 8:10
suggest improvements |Â
1
Exactly, you can't run a software company like you'd run a factory. If we're going to grade our work based on number of hours, we might as well grade it using the number of lines of code, which I think you'll agree is quite stupid.
– Gigi
Sep 13 '14 at 11:19
2
"In software industry programmers are paid according to number of hours put in to write software" - Careful. Most of the programmers I know are salaried, and get paid the same whether they put in a 40 hour week or a 60 hour week.
– aroth
Sep 14 '14 at 1:29
1
@aroth I guess that depends on where you're from. Over here, if you do more than 40 hours you are usually paid overtime (but not always).
– Gigi
Sep 14 '14 at 8:10
1
1
Exactly, you can't run a software company like you'd run a factory. If we're going to grade our work based on number of hours, we might as well grade it using the number of lines of code, which I think you'll agree is quite stupid.
– Gigi
Sep 13 '14 at 11:19
Exactly, you can't run a software company like you'd run a factory. If we're going to grade our work based on number of hours, we might as well grade it using the number of lines of code, which I think you'll agree is quite stupid.
– Gigi
Sep 13 '14 at 11:19
2
2
"In software industry programmers are paid according to number of hours put in to write software" - Careful. Most of the programmers I know are salaried, and get paid the same whether they put in a 40 hour week or a 60 hour week.
– aroth
Sep 14 '14 at 1:29
"In software industry programmers are paid according to number of hours put in to write software" - Careful. Most of the programmers I know are salaried, and get paid the same whether they put in a 40 hour week or a 60 hour week.
– aroth
Sep 14 '14 at 1:29
1
1
@aroth I guess that depends on where you're from. Over here, if you do more than 40 hours you are usually paid overtime (but not always).
– Gigi
Sep 14 '14 at 8:10
@aroth I guess that depends on where you're from. Over here, if you do more than 40 hours you are usually paid overtime (but not always).
– Gigi
Sep 14 '14 at 8:10
suggest improvements |Â
up vote
0
down vote
Keeping track of your time, reporting your time, and getting stuff done precisely in the time originally estimated for that stuff are three entirely different things.
- tracking your time (using something informal like a piece of paper, a spreadsheet, a journaling app on your phone that your employers never see) is incredibly effective. Whether you want know just how much time you spend waiting for conference calls to start or wading through emails, or compare which of your fixed-revenue buckets-of-work are making you more per hour, tracking your time is vital
- reporting your time is sometimes useful, depending on who you're reporting it to. Management needs to know "that took us ten hours because of changing requirements, cross-cutting concerns, design decisions, function points with unknowns requiring research, etc but we are only able to bill two as in the original estimate." Making sure they know this is the only way you will ever get out of unpaid overtime, apologizing for lateness you didn't cause, etc
- pretending something only took two hours because that's all you can bill for it, and hiding the other eight somewhere else or not reporting it, is not effective at all - and if you work somewhere that demands you do so, deal (if you can) with that, not with the tracking and reporting of time.
Some people have had success by creating a non billable bucket called "churn and backtrack due to communication issues" and letting numbers pile up in there until someone does something about it. However it's entirely possible that the someone is you, the bucket is also called "unpaid overtime that I was supposed to apologize for spending", and the something you do is change jobs. But should that happen, you'll be doing it for a sensible logical reason after tracking what's been happening for a while, and not impulsively because you feel things aren't fair lately.
answered Sep 14 '14 at 15:45
Kate Gregory
105k40232334
suggest improvements |Â
up vote
0
down vote
Keeping track of your time, reporting your time, and getting stuff done precisely in the time originally estimated for that stuff are three entirely different things.
- tracking your time (using something informal like a piece of paper, a spreadsheet, a journaling app on your phone that your employers never see) is incredibly effective. Whether you want know just how much time you spend waiting for conference calls to start or wading through emails, or compare which of your fixed-revenue buckets-of-work are making you more per hour, tracking your time is vital
- reporting your time is sometimes useful, depending on who you're reporting it to. Management needs to know "that took us ten hours because of changing requirements, cross-cutting concerns, design decisions, function points with unknowns requiring research, etc but we are only able to bill two as in the original estimate." Making sure they know this is the only way you will ever get out of unpaid overtime, apologizing for lateness you didn't cause, etc
- pretending something only took two hours because that's all you can bill for it, and hiding the other eight somewhere else or not reporting it, is not effective at all - and if you work somewhere that demands you do so, deal (if you can) with that, not with the tracking and reporting of time.
Some people have had success by creating a non billable bucket called "churn and backtrack due to communication issues" and letting numbers pile up in there until someone does something about it. However it's entirely possible that the someone is you, the bucket is also called "unpaid overtime that I was supposed to apologize for spending", and the something you do is change jobs. But should that happen, you'll be doing it for a sensible logical reason after tracking what's been happening for a while, and not impulsively because you feel things aren't fair lately.
answered Sep 14 '14 at 15:45
Kate Gregory
105k40232334
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
Keeping track of your time, reporting your time, and getting stuff done precisely in the time originally estimated for that stuff are three entirely different things.
- tracking your time (using something informal like a piece of paper, a spreadsheet, a journaling app on your phone that your employers never see) is incredibly effective. Whether you want know just how much time you spend waiting for conference calls to start or wading through emails, or compare which of your fixed-revenue buckets-of-work are making you more per hour, tracking your time is vital
- reporting your time is sometimes useful, depending on who you're reporting it to. Management needs to know "that took us ten hours because of changing requirements, cross-cutting concerns, design decisions, function points with unknowns requiring research, etc but we are only able to bill two as in the original estimate." Making sure they know this is the only way you will ever get out of unpaid overtime, apologizing for lateness you didn't cause, etc
- pretending something only took two hours because that's all you can bill for it, and hiding the other eight somewhere else or not reporting it, is not effective at all - and if you work somewhere that demands you do so, deal (if you can) with that, not with the tracking and reporting of time.
Some people have had success by creating a non billable bucket called "churn and backtrack due to communication issues" and letting numbers pile up in there until someone does something about it. However it's entirely possible that the someone is you, the bucket is also called "unpaid overtime that I was supposed to apologize for spending", and the something you do is change jobs. But should that happen, you'll be doing it for a sensible logical reason after tracking what's been happening for a while, and not impulsively because you feel things aren't fair lately.
answered Sep 14 '14 at 15:45
Kate Gregory
105k40232334
Keeping track of your time, reporting your time, and getting stuff done precisely in the time originally estimated for that stuff are three entirely different things.
- tracking your time (using something informal like a piece of paper, a spreadsheet, a journaling app on your phone that your employers never see) is incredibly effective. Whether you want know just how much time you spend waiting for conference calls to start or wading through emails, or compare which of your fixed-revenue buckets-of-work are making you more per hour, tracking your time is vital
- reporting your time is sometimes useful, depending on who you're reporting it to. Management needs to know "that took us ten hours because of changing requirements, cross-cutting concerns, design decisions, function points with unknowns requiring research, etc but we are only able to bill two as in the original estimate." Making sure they know this is the only way you will ever get out of unpaid overtime, apologizing for lateness you didn't cause, etc
- pretending something only took two hours because that's all you can bill for it, and hiding the other eight somewhere else or not reporting it, is not effective at all - and if you work somewhere that demands you do so, deal (if you can) with that, not with the tracking and reporting of time.
Some people have had success by creating a non billable bucket called "churn and backtrack due to communication issues" and letting numbers pile up in there until someone does something about it. However it's entirely possible that the someone is you, the bucket is also called "unpaid overtime that I was supposed to apologize for spending", and the something you do is change jobs. But should that happen, you'll be doing it for a sensible logical reason after tracking what's been happening for a while, and not impulsively because you feel things aren't fair lately.
answered Sep 14 '14 at 15:45
Kate Gregory
105k40232334
answered Sep 14 '14 at 15:45
Kate Gregory
105k40232334
answered Sep 14 '14 at 15:45
Kate Gregory
105k40232334
answered Sep 14 '14 at 15:45
Kate Gregory
105k40232334
105k40232334
suggest improvements |Â
suggest improvements |Â
Just to clarify, do you mean a system where the employees fill out a time sheet of some sort? E.g. "9 to 10.15am: Meeting about client A" Or do you mean a more complex project management software; something like Atlassian?
– Alpar
Sep 13 '14 at 9:05
The former. But if you would like to compare both approaches, by all means go ahead.
– Gigi
Sep 13 '14 at 9:40
it's not only about log what the employees are doing, it's also about to bill the hours to the customer.
– Guido Preite
Sep 13 '14 at 10:53
That isn't the case when the projects are fixed-price.
– Gigi
Sep 13 '14 at 11:17
1
and how they can measure the profitability of a fixed-price project if they don't know how many hours took to complete the project?
– Guido Preite
Sep 14 '14 at 6:49