#266 in Computers & technology books
Use arrows to jump to the previous/next product
Reddit mentions of Software Estimation: Demystifying the Black Art (Developer Best Practices)
Sentiment score: 9
Reddit mentions: 13
We found 13 Reddit mentions of Software Estimation: Demystifying the Black Art (Developer Best Practices). Here are the top ones.
Buying options
View on Amazon.comor
- Used Book in Good Condition
Features:
Specs:
Height | 8.81888 Inches |
Length | 7.32282 Inches |
Number of items | 1 |
Weight | 1.322773572 Pounds |
Width | 0.86614 Inches |
Your job is not to make them like you. It is to accurately deliver something, and make them hire you. "I don't know, but we can figure it out..." is as close as you can get without being dishonest.
At my company we have 3 solutions to "I don't know" when asked "How Long is this going to take":
We offer to do an estimate of the software at our expense for people doing hourly. It will be rough, a range, and by no means guaranteed, especially if there are any scope or other changes pushed over to us.
If they want a detailed, super through estimate (using a lot of the techniques in this book), we offer to do one, at our normal hourly rate. As many projects where customers care this much would take as much time to estimate as it would to do 40% of the project, then you likely don't REALLY want to spend that amount of time doing it.
If they want a fixed price (and this is the real deal for most of them), or a fixed deadline, then we offer them a price that we develop off of working through a moderately through estimate, timelines of availability, and how much we want any IP we may get out of this agreement. Additionally we tack on a "Changes cost extra, and will be billed hourly, unless prior fixed fee amounts are asked for and agreed upon"
Seems to work out fine.
Best work I've seen on subject:
http://www.amazon.com/dp/0735605351
I've posted this before but I'll repost it here:
Now in terms of the question that you ask in the title - this is what I recommend:
Job Interview Prep
Junior Software Engineer Reading List
Read This First
Fundementals
Understanding Professional Software Environments
Mentality
History
Mid Level Software Engineer Reading List
Read This First
Fundementals
Software Design
Software Engineering Skill Sets
Databases
User Experience
Mentality
History
Specialist Skills
In spite of the fact that many of these won't apply to your specific job I still recommend reading them for the insight, they'll give you into programming language and technology design.
/u/tevert brings up some very good points. I'm going to take a slightly different stance, for the sake of completeness: if estimating is such a pain... why do it? What job are you hiring estimates to do?
The age-old RoI argument is always interesting. Let's take a look it it:
RoI = (Revenue - Cost)/Cost
So in order for an ROI calculation to make sense, Revenue must be expressed in the same unit (yup, dollars will do), and be of the same scale of precision.
So a first interesting question would be: what is the confidence interval and error margin of the revenue estimation? It would be nonsensical to estimate "cost" to a higher precision than revenue: your equation is only as good as the weakest of your measures.
You say you keep track of the time it takes to estimate. This is interesting... is this cost included in your RoI calculations?
Further, what is the impact on team morale and productivity of the estimation process? Is quality preserved in the presence of an imprecise estimation? If not, what is the cost of that?
Ok, I'm done agitating... for an in-depth treatment of these themes, I would point you in the general direction of Vasco Duarte's No Estimates book and Woody Zuill's contributions on #noestimates. Regardless on whether you continue to estimate or not, they bring up excellent points, and their discussion can also make you better at estimating.
Finally, for symmetry's sake, I will point you to one of the definitive books on estimation: Software Estimation: Demystifying the Black Art.
Good luck - it's a tricky, and highly environment-dependent issue. My personal experience favours the "break everything down to 1-pointers, measure flow, project (but don't estimate) based on that"... but this may, or may not, be applicable to your situation and environment.
For more foundational stuff, I'd look at:
Getting familiar with these branching models will also expose you to many commonly-used Git features like branching, squash merging, rebasing, tagging, and history rewriting.
No one's really gonna ask you about this, but you should develop a habit of writing great, clear, and concise commit messages.
All the rage right now - having real/near-real time building/unit-testing/packaging/deployment of your software once you've made a code commit. Read the articles I linked, play with services like CircleCI or Travis-CI or CodeShip and integrate them with your projects in GitLab.
Probably the two most commonly used overarching test-based software development processes. I'm a strong proponent of TDD (when done right), and many teams you work on will probably employ TDD or BDD.
Beyond those links, some books that cover a lot of general material are:
The problem is in using expert judgement in the first place. Thats the last place you look if you have no other data available, or you're estimating something on the scale of < 3 weeks.
There has been a whole lot of work done on analytical approaches to SW estimation, and they generally work really well. Use company historical data, use team historical data. Find something close to what you're planning, and base your estimate off that. As the linked article states, people are just generally bad as estimation, so rely on data instead.
This book is a pretty decent primer. http://www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351#
The rule of 3 really affects estimates for things you are unfamiliar with. Most people are very good at estimating the tasks that they know and omit or poorly estimate all the other related and supporting tasks. For example... if you were to estimate a piece of work to require 400 man hours... that may be a good estimate...but when you project that across a team of 5 people how long will that take? Are you considering hourly efficiency (i.e most 8 hours workdays will normally only have 5-6 good working hours)? what about illnesses or time off? Ramp up time for new tool/methodology adoption...etc
&#x200B;
I would highly recommend the Steven McConnell book on estimation. The first 5 chapters are a must read for anyone dealing with estimation. It was written for software developers but is very relevant to ALL technical fields.
&#x200B;
Quick look through
https://ptgmedia.pearsoncmg.com/images/9780735605350/samplepages/9780735605350.pdf
Amazon
https://www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351
One of my favorite essays is How To Be A Programmer by Robert Read.
The first two skills of the 'team' section for beginners are: Why Estimation is Important and How to Estimate Programming Time
On this topic, Software Estimation: Demystifying the Black Art by Steve McConnell is the go to book. If nothing else, get it and read it - you'll be much further along when you get another job in being able to communicate well.
Note that you're WAY early in the cone of uncertainty. You need to figure out what this is going to be and giving a range that is 8x at this stage is completely acceptable. "It may take me a month, it may take me 8 months - I need to do some more research into this to be able to narrow it down."
They are going for a fixed cost contract. If its a 1 month one, that could be a nice pay day... if its an 8 month one, that's going to be way under what it should be worth in terms of time you spent on it.
I would encourage you to watch Fuck you, pay me. If this is something sufficiently large, have a lawyer look over it.
Recomendado totalmente es Software Estimation: Demystifying the Black Art (Developer Best Practices) de Steve McConnell
I agree with all of the advice here, but to add some more practical help: look into using the Google Translate plug in made by Prisna. It lazy translates the page for you and works reasonably well. And you can definitely get it installed and working by Monday.
Also, add the book Software Estimation: Demystifying the Black Art (Developer Best Practices) https://www.amazon.com/dp/0735605351/ref=cm_sw_r_cp_apa_51bPAbTNQZGXM to your learning library. It really breaks down the whole process of estimation and its a must-read for all of my developers.
Thanks for the recommendation!
What do you think about his books on Rapid Development and Software Estimation?
There's a good book about this, written by the guy who wrote "Code Complete".
Have you read Software Estimation: Demystifying the Black Art?
Management shouldn't be making the estimates in the first place.
Have you looked into studies on programmer productivity? There's plenty of literature. They used benchmarked tasks.