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 6 down vote favorite

What books have you read that helped you, as a programmer, learn to estimate time for completing small-to-medium programming tasks, such as bug fixes or implementing new features? Which have you the most helpful?

Please describe how it helped you, citing its strengths and weaknesses.

share|improve this question
1  
possible duplicate of What is the canonical book on software estimation? – Graham Lee Sep 2 '11 at 15:01
@Graham Please see the comments of that question. The creation of this question was recommended there. – Matthew Rodatus Sep 2 '11 at 15:03
@Graham It's not. See the discussion on the question there. There is a distinct difference between estimating projects (how the original question was interpreted) and time estimation for tasks by individual programmers (original intent of that question). Per comments, that question was rolled back to be about software project estimation and this question created to be about task time estimation. – Thomas Owens♦ Sep 2 '11 at 15:04
@Matthew I tried to clean up both questions to make them more unique. Thoughts? – Thomas Owens♦ Sep 2 '11 at 15:11
@Thomas I don't like the use of "canonical," because what is helpful for one person may not be helpful for all. Otherwise, it looks great. Thank you! – Matthew Rodatus Sep 2 '11 at 15:20
show 1 more comment

3 Answers

up vote 2 down vote accepted

I would suggest looking into the Personal Software Process. Watts Humphrey has three books that might be of interest - Introduction to the Personal Software Process, A Discipline for Software Engineering, and PSP: A Self-Improvement Process for Software Engineers.

Introduction to the Personal Software Process is probably where you want to begin. The PSP is a phased process, and it introduces the first phases of the process. I believe it introduces concepts through PSP 1.1, which are process discipline, measurement, estimation, and planning. This sounds very much like the topics that you are interested in. It's also a much easier read, focusing more on the practices and less on the statistical analysis that is part of full-blown PSP.

A Discipline for Software Engineering goes much deeper into these topics, and also includes the rest of the PSP (quality management, design) and begins to introduce the Team Software Process for larger projects. PSP: A Self-Improvement Process for Software Engineers is extremely in-depth and also covers the entire PSP. The difference is in the focus. A Discipline for Software Engineering is designed for a graduate course and discusses some of the research and topics of academic interest, while PSP: A Self-Improvement Process for Software Engineers is written for people working in industry and improving the process of software developers, omitting topics that are purely academic in nature.

I should add a warning that "out of the box" PSP is very heavy and script/form driven. However, it doesn't need to necessarily be that way - it's a framework that can be tailored. Also, many of the PSP practices can be integrated with an existing process without a significant amount of overhead.

share|improve this answer
Awesome, thank you! +1 – Matthew Rodatus Sep 2 '11 at 15:04
Two common criticisms of Watts Humphrey's PSP: 1. So, where's all his code? 2. PSP seems designed to take all the fun out of programming. Geoffrey Phipps used PSP to good effect in Comparing Observed Bug and Productivity Rates for Java and C++, however (citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.97.7580). – Bruce Ediger Sep 2 '11 at 15:10
@Bruce I don't understand the first critisism. What do you mean "where's the code"? Could you elaborate on it? I totally see the second one, but as an engineer, I prefer having measurability, repeatability, data, and continuous improvement. – Thomas Owens♦ Sep 2 '11 at 15:13
Not to speak ill of the dead, but "Where's all his code?" is usually meant as "Where is all the great software Humphrey produced himself using PSP?" The rise of open source software could have given Humphrey a bully pulpit for PSP. Yet we don't see anything at all he wrote. Maybe he didn't practice what he preached since he wasn't one of the people he was preaching too, but folks like Donald Knuth, Rob Pike, all manage to have a body of sotware out there. – Bruce Ediger Sep 2 '11 at 15:18
@Bruce Ah. I see what you mean. The only problem with that argument is that Humphrey spent a lot of his time researching software quality, process improvement, and project management at the SEI and teaching at CMU, after working as a manager (directory and later VP) at IBM. A lot of influential people in the process side of software engineering (Boehm, Brooks, Basili, Royce, Parnas) weren't prolific software developers (at least publicly available software, since a number worked in the defense industry for various contractors or the DoD). – Thomas Owens♦ Sep 2 '11 at 15:25
up vote 2 down vote

Here is a good site I have referenced before:

http://jamesshore.com/Agile-Book/estimating.html

We do use Agile development however.

It helped me by getting down to realistic estimations, and being able to more clearly explain and back those estimations.

share|improve this answer
up vote 1 down vote

It isn't a book, but ...

The founder of Stack Overflow and Stack Exchange created a reasonable estimating and scheduling methodology that he called "Evidence-based scheduling". The methodology was implemented in the FogBugz bug tracking and development management system.

Short summary:
** break features/tasks into small chunks, no bigger than 16 hours each.
** have the programmers make estimates of the time.
** keep track of the actual time spent.
** Use estimate v. actual history to predict actual from estimates and build a schedule.

Note: the very first bit of Joel's writing I read was his "Painless Software Scheduling" article. Joel has since deprecated it in favor of EBS, but it may have some value as a starting point while you build history or if you are working alone.

share|improve this answer
Thank you! The Painless Software Scheduling article is what inspired my question in the first place. – Matthew Rodatus Sep 2 '11 at 15:25

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.