Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 11 down vote favorite
1

In a new project, a friend had to write tests where the time required to write them was calculated by an Excel macro written by his non-developer manager.

In such circumstances, should a developer accept the responsibility to write and run the tests in the calculated time? Are the results of these test trustworthy?

For information, my friend refused to be responsible for estimations he didn't made, ask succeed to work on another project, and have been replaced by an inexperienced out-of-the-school yes-guy.

share|improve this question
7  
What does it mean to "accept" an "estimation"? If you estimate it will take me 30 days to do something, what happens if I "accept" it? What do I care how long you estimate it will take me to do something? You can estimate I'll do it in a minute for all I care, you will be wrong, not me. – David Schwartz Aug 31 '11 at 12:49
2  
@David Accepting an estimate generally refers to reviewing the estimations and ensuring consensus. For example, if a parametric estimation tool is used, having project engineers review that data to ensure consistency, perhaps using a second methodology such as Wideband Delphi. – Thomas Owens♦ Aug 31 '11 at 13:15
12  
Sounds like something that should be sent to Scott Adams for a Dilbert cartoon. – MetalMikester Aug 31 '11 at 13:16
1  
As long as there is a review. I this particular example there were none. – Nelstaar Aug 31 '11 at 14:05
5  
Remember: an estimate, a commitment, a target, and a plan to meet a target are four different things. Make sure that everyone is clear on what those things are, and which of those four things the Excel output is. – nlawalker Aug 31 '11 at 14:06
show 7 more comments

11 Answers

up vote 14 down vote accepted

It depends on how sensible they look to the developer, and what data/logic they are based on. (they might be based on statistical data collected over several years about how much time was required - by this developer himself, and/or by others - to solve similar tasks in the past... or they might be based entirely on his manager's - correct or incorrect - assumptions.)

Ideally, he should discuss with his manager that one can't be reasonably expected to commit to and take responsibility for a task estimated by someone else.

Plainly refusing to commit to the estimates may indeed result in his prompt replacement, so it is better to have a softer approach and avoid direct confrontation if possible.

share|improve this answer
up vote 1 down vote

In theory, a developer should never accept an estimate made by any other person, no matter how it was arrived at. One reason is that giving a longer estimate than your manager is comfortable with immediately exposes a potential schedule problem or perhaps a misunderstanding about the scope of work to be done.

People generally find programming-time estimation even more difficult than programming itself, so if your manager can write an Excel macro can solve that problem, he can probably construct a macro to write the code (unlikely).

Now, in practice, if you understand the work and the estimates look reasonable, it makes sense to simply express some concern about the methodology in passing but then provisionally agree to see if you can meet them. Later, if the work is taking you longer than the estimates, you should bring this to your managers' attention at the earliest possible moment. Be prepared to discuss the exact reasons based on your actual implementation experience. Hopefully at that point your manager will not be unreasonable and continue to insist that you work to mechanically generated estimates.

share|improve this answer
up vote 1 down vote

Easy and short answer:

You don't care where the estimation is coming from.

What you actually care is the estimation itself. Agree with it or disagree and explain why and how much you would estimate. That is the most important.

share|improve this answer
1  
You should care where the estimate is coming from. A parametric model with valid and reasonable inputs, a random number generator, a first year computer science student, a software engineer with 5 years of experience with less than 6 months in the domain, and a software engineer turned project manager with 25 years of experience in the domain all have a different capacity to produce an effective estimate. This also goes back to a comment I made on a previous answer about the ethical/professional responsibility of a software engineer to represent, defend, and challenge estimates appropriately. – Thomas Owens♦ Aug 31 '11 at 16:30
Exactly: the most important is to discuss the estimation. I'd gladly approve using Excel macros if the estimations it made were more often right than a 25 years of experience engineer. What's important is the estimation, and the explanation that lead to it (workload, availables resources, difficulty), not by who or what it was announced. – Clement Herreman Sep 1 '11 at 14:52
You agree with me saying that your answer is wrong? Given the same inputs (such as workload, resources, difficulty, etc.), the who is just as important as the what and why. It comes down to a trust factor. I trust COCOMO (made and maintained by some leading minds in software cost estimation) more than an Excel macro (made by someone with limited experience and knowledge in cost estimation, much less the application domain). It's all about the big picture to establish how trustworthy is this estimate. – Thomas Owens♦ Sep 1 '11 at 15:02
No no, I guess I'm not clear enough. It's really not important who did the estimation. What is important is the accuracy of the estimation. Whenever I get an estimation, I compare it to what I'd estimation, then discuss it with my project manager if I agree or not. If their argument is good enough, then I agree with they, and accept the estimation. See? I've never talked nor thought about who estimated. – Clement Herreman Sep 1 '11 at 15:06
How do you determine the accuracy if you don't know who estimated and what methods they used? I could give the same data to two people - one is a first year software engineering student taking currently taking his first computer science course and the other is a senior software engineer with 15 years experience and 5 in the domain. Both use the same estimation methods (don't forget - often, inputs are estimates as well). The student can say it will take 6 months with a 95% confidence. The senior engineer can say it will take 15 months with 80% confidence. I'd trust the senior engineer more. – Thomas Owens♦ Sep 1 '11 at 15:11
show 3 more comments
up vote 3 down vote

Sounds like you are asking two different questions:

Are the results of these test trustworthy?

Excel is a tool like any other one that we work with and what the calculations was written in shouldn't really have an impact upon the results of the algorithm itself. The fact that the estimation is coming from an Excel macro is irrelevant to whether or not the results of the calculation (i.e. the validity of the estimate) is valid. If you have bad assumptions in the underlying model it doesn't matter what you use to do the calculation as the underlying assumptions are incorrect.

In such circumstances, should a developer accept the responsibility to write and run the tests in the calculated time?

If the requirement that the developer do the work in the indicated time is in their contact then there is not much they can do to argue with it as long as the estimates are reasonable. Which leads into the next point: if the calculations are giving a reasonable amount of time and they are similar to the estimates the developer would give themselves then there is no reason not to object to the timelines given. In fact, it might work to the developers advantage as they might be able to influence the assumptions used in the module as opposed to if they are given an arbitrary timeline.

If the timelines seem infeasible for the amount of work required then obviously they should raise this concern and try and work with the manager to get more realistic timelines, but if the timeline are feasible then they are going to have a hard time objecting to them.

In terms of project management and estimating timelines, yes, it can be done but it is highly dependent upon the nature of work being done. You are likely going to see more accurate estimates being given for the time required to write unit testing code (assuming the developer understands the framework and has written them before) than you will for writing new code against the use cases the testing code is being written for.

share|improve this answer
I agree this method can/could be used as long as there is a dialog between actors of the project. – Nelstaar Aug 31 '11 at 14:01
1  
@Nelstaar - Pretty much anything I've ever read on project management and estimation involves a running dialog and tuning things as time goes on. Usually most reliable estimates have a probability associated with them in regards to the odds of hitting the target indicated (i.e. 90% chance of the task taking 8 hours). – Rob Z Aug 31 '11 at 14:07
up vote 3 down vote

In a new project, a friend had to write tests where the time required to write them was calculated by an Excel macro written by his non-developer manager.

There are parametric estimation models for estimating completion time of projects, including software projects. Usually, the estimate is for production code, but I don't see why it can't be extrapolated to estimate how long it will take to write test code. These estimates are only as good as the data that is fed into them, though.

Assuming that the method used is a valid estimation model and the data is accurate and valid, there's no reason why a good estimate can't come from an Excel macro written by a non-developer manager.

In such circumstances, should a developer accept the responsibility to write and run the tests in the calculated time?

No estimate should ever be blindly accepted, under any circumstances. No estimate is ever perfect, regardless of how it is generated. It's up to the engineer to review any estimates, identify potential problems, assess their impact, and discuss and refine the estimate as needed.

Are the results of these test trustworthy?

Tests are only as good as the effort spent in designing and implementing them. If a tester produces low-quality tests, defects will slip through testing and make it to a later phase of the project. It stands to reason that schedule pressure will lead to low-quality tests, so if the time is insufficient to design the appropriate test cases and then implement those cases, then the tests would not be as useful.

share|improve this answer
up vote 2 down vote

I don't want to down-play writing tests, but the project has probably had several developers write them before. If estimates are based on these data, they may be more accurate than your friend has assumed. Since your friend left the project, made no attempt to create opposing estimates or see if they could be completed as predicted, we'll never know.

All he had to do was complete one or two tests to see how accurate the estimate was, and return to the manager with a legitimate arguement. There may be other team members who could have provided feedback on the reliability of the estimates or the consequences of falling behind. Sometimes one manager has to give 'something' to his boss to keep everyone happy. Developers see this as a false sense of security. Maybe if there was a movement for developers to provide estimates and show a willingness to get things done, management may develop more trust.

What I'm guessing is, if he were able to complete the tests in less time, he wouldn't say anything about it. Then again, excusing himself from a practice he does not believe in, may indicate a high-level of integrity.

share|improve this answer
+1 for giving feedback while working through the tasks in regards to the estimates. – Rob Z Aug 31 '11 at 14:05
up vote 4 down vote

Ugh!

This is a gigantic "job smell". That is incredible micro-management.

If they cannot trust their employees to give an estimate, what else don't they trust you with?

share|improve this answer
1  
99% of developers can't even come up with bad estimates based on anything objective let alone accurate estimates. So I see nothing indicating "job smell" because someone else came up with an estimate. Particularly if they used actual data to justify their numbers. If people are held accountable to meeting the estimate every task then that is a job smell issue. However, if the tool vastly underestimated all tasks then all developers would be missing the estimates. OTOH, if everyone else seems to meet most all the estimates and another developer never does then that is a developer smell issue. – Dunk Aug 31 '11 at 20:35
@Dunk - my point stands, micro management to this degree in developing software is a "job smell" and I wouldn't want to work there. – Ozz Sep 1 '11 at 13:54
1  
what you call micromanagement is the only way to do business in many industries. If you can't come up with reasonable cost and schedule estimates for large projects then your company will have a very difficult job getting contracts. Contrary to the agile-ideal, customers in many industries are not going to commit to tens of millions of dollar contracts if they don't know what they'll be getting in the end. They wouldn't be happy with the idea that their money is gone, they have a working product, but it only does 50% of what they need or wanted. – Dunk Sep 7 '11 at 17:52
@dunk - If you are happy with management producing estimates for you, go right ahead. I'd rather have the development team producing estimates. Ludicrous management estimates (together with constantly changing reqs, a whole other discussion) are why many software projects fail to deliver on time and in scheduled budget. I'd rather trust the people who do the work. – Ozz Sep 8 '11 at 12:24
It is not a question of management doing estimates or the people doing the work coming up with the estimates. It is a question of pulling estimates out of your butt or attempting to base your estimates on some objective data. It has been my experience that in comparing management estimates to developer estimates you would find that management estimates tend to result in longer times to complete. Developers tend to be optimistic..... – Dunk Sep 12 '11 at 15:36
show 2 more comments
up vote 3 down vote

Absolutely NO.

I promise you that manager is not so deluded to think that his Excel macro can accurately predict estimations. I am not even arguing what should be a well known fact that there are too many variables involved to accurately predict something like this in an algorithm. If he invented such an algorithm he should patent it and make millions in my opinion.

What is really happening here is the manager is using this supposed Excel macro as a thinly veiled disguise to hide the fact that he is forcing unrealistic expectations and undue pressure on his developers.

He knows it is BS and doesn't care, it is an excuse to overbook resources and try to get things done faster by making all of his "worthless" developers perpetually "LATE".

This manager sounds like an exploitative jerk.

share|improve this answer
1  
Eh, just because the manager is generating estimates for the developers doesn't mean that they are inaccurate and we really can't draw that conclusion without more information. If the manager is competent they they should recognize realistic versus unrealistically fairly easily adjust things accordingly. – Rob Z Aug 31 '11 at 14:04
1  
@Rob, You are forgetting the key point that the OP made, that they are being held to these estimates (assumed strictly because the previous developer on the team mentioned "did not want to be held to the estimates" and was reassigned). There is nothing wrong with estimation models but they should be a rough guideline and nothing to "hold developers to", which I unfortunately have seen management do to a LOT of people. – maple_shaft♦ Aug 31 '11 at 14:11
2  
Here the problem was these estimations were directly move in the customer's invoice. Why some managers keep calling it estimates ? – Nelstaar Aug 31 '11 at 14:16
@maple_shaft - Without knowing what the estimates are it is hard to say if the they were unreasonable and therefore objections to being held to them were valid. If they were fair estimates (i.e. "Eight hours to write Hello World") then there is no problem with being held to them beyond philosophy. – Rob Z Aug 31 '11 at 14:19
up vote 5 down vote

Most definitely NO.

A small program, even a large, complicated program, cannot possibly estimate how long any programming job will take. See Mathematical Limits to Software Estimation for reasons why. A longer, peer-reviewed paper, Large Limits to Software Estimation is also available.

I would also reconsider my opinion of the manager in question: why does he or she believe that a spreadsheet macro hasn't been tried in the past, given that everything else has been tried to estimate software task duration in the past.

share|improve this answer
1  
I haven't read those papers in full (yet), but parametric methods have been widely used to estimate software projects within 15% for well over 20 years, assuming that the input data is valid. In addition, collaborative methods such as Wideband Delphi can (and have been used) to confirm the accuracy of parametric models. See Software Engineering Economics (Boehm) for a discussion of parametric methods and applying Wideband Delphi on software projects (both with and without paremetric models as well). – Thomas Owens♦ Aug 31 '11 at 13:19
I agree with Thomas. While you can't accurately predict every single task for an entire project, over the course of a project and using historical data for a specific organization you can get in the ballpark. Some tasks will take longer and some shorter but in the end they average out. Particularly if the project is similar to ones already done by the organization. With that said, estimates can't account for really bad unexpected things, like the hardware/software doesn't work as advertised, new technologies are far harder than anticipated, developer shortages, poor leadership and management. – Dunk Aug 31 '11 at 20:43
1  
You folks need to read and comprehend the paper. A simple spreadsheet macro doesn't have a chance of estimating correctly. Software is math, and mathematical systems are sometimes subject to a little problem known as incompleteness. I guarantee you that the manager in question is fooling him or herself, and that the macro's results do not correlate with reality. – Bruce Ediger Aug 31 '11 at 23:37
1  
@Bruce: Having used formula's (including Excel spreadsheets) for project estimation with success, I can most certainly claim that neither Thomas, the Manager or myself are necessarily fooling ourselves. As I stated, each individual task is going to vary, but over the course of a project they tend to even out. I have found that using formula's (developed and modified over time) has been far more accurate than individual developer estimates. Generally, developers are overly optimistic or overly pessimistic. Of course, the formulas only work when given reasonable data,skill is certainly a factor. – Dunk Sep 1 '11 at 13:18
I read those papers last night. They go against over 40 years of evidence in project management and over 30 years of evidence in software project management. See iiasa.ac.at/Admin/PUB/Documents/RM-75-071.pdf and sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html – Thomas Owens♦ Sep 1 '11 at 15:35
up vote -1 down vote

One of the most newest software development methodologies is agile, and one of the well-known agile frameworks is scrum. But in this methodology, developers (scrum team) is responsible for calculating the required time to do a task or implement a user story.

I definitely say NO. Because:

  1. A non-developer manager can't estimate the required time for doing a job
  2. Estimating the required time for doing any job needs some human intelligence, which Excel doesn't have
  3. By accepting such working practices, manager progressively get used to replace developers in estimating times. This can result in catastrophe. Consider this scenario in which your manager says:

I want to start a new project for selling bicycles online and I know that it takes 3 weeks for you and John to accomplish it.

share|improve this answer
5  
The OP has no mention of his friend's team using agile methods. I don't think agile rules have any relevance for teams using other methods (or no method at all). Common sense should, though :-) Moreover, it is obvious that it was not Excel which decided about the estimates, it only executed some calculation based on some (unknown to us) assumptions and data (each of which may be correct or incorrect). If I enter estimates for a given task by each of our team members, then set Excel to calculate the average of these, is Excel making the estimation? – Péter Török Aug 31 '11 at 12:54
3  
1 and 2 are blatently false. Parametric estimation models are widely accepted in software project management and have been for well over 20 years, and anyone with project management training (software engineer or not) can be trained to use these tools, assuming that they (or, preferably, the project engineers) are able to provide accurate estimates of the inputs. – Thomas Owens♦ Aug 31 '11 at 13:14
3  
-1 - This does not answer the question, has obvious errors ("...newest software development methodologies is agile"), and does not appear to add anything of relevance. I am not sure what the upvotes or the accepted answer were for. – Morgan Herlocker Aug 31 '11 at 13:36
1  
we certainly don't know from the question if parametric estimation is the norm at this company and/or if it's based on a good history for their business; if that is the case than as much as I hate to say it, refusal to do one's job in accordance with the organization's accepted operating procedures (without following a reasonable path of questioning) is imprudent. – StevenV Aug 31 '11 at 13:52
2  
@Thomas I agree, I just think there's too much we don't know about the situation to categorically answer Yes or No. In any case, flat-out refusal without a good discussion to make sure the situation and reasoning is understood is rarely a good career move. – StevenV Aug 31 '11 at 15:08
show 7 more comments
up vote 7 down vote

Presumably the macro is operating on some sort of input data, it's not just a random number generator? So, in order to answer your question we need to know what the input data is and what the macro does. Without this any answer is pretty meaningless.

Or, is your question really about accepting estimates produced by a manager who lacks relevant experience? In this case the answer is no, you (or your friend) should produce their own estimates and submit those to the manager. If the 2 figures do not match then they need to work together to figure out the best way forward - maybe agreeing to write fewer tests or maybe taking longer to write them all.

Point blank refusal isn't going to help anyone, and working to a timescale you can't meet is no fun either, the solution lies in taking a professional approach and coming to a compromise that allows work to proceed.

share|improve this answer
The tests are sliced in sub-sub-parts (almost atomic) and one gets a small estimation. – Nelstaar Aug 31 '11 at 12:26
I think using this method the final tester don't see/test the big picture. – Nelstaar Aug 31 '11 at 12:27
1  
"Presumably the macro is operating on some sort of input data, it's not just a random number generator" It might as well be random because their is no way to capture EVERY variable that would make such an algorithm accurate. – maple_shaft♦ Aug 31 '11 at 12:59
1  
@maple_shaft: That's why they call it an estimate - it isn't (or shouldn't be) expected to be accurate. Whether you estimate using some calculations in Excel, or with pencil and paper, doesn't make any difference. Using Excel for estimations makes much more sense than some other 'techniques' I have seen in use... – Treb Aug 31 '11 at 13:33
@Treb Estimates should be as accurate as the provided data and current project status allow for, given the Cone of Uncertainty. – Thomas Owens♦ Aug 31 '11 at 13:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.