u/gte910h · 6 pointsr/programming

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.

u/mikaelhg · 5 pointsr/programming

Best work I've seen on subject:
http://www.amazon.com/dp/0735605351

u/CSMastermind · 4 pointsr/learnprogramming

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

u/recycledcoder · 3 pointsr/scrum

/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.

u/SofaAssassin · 2 pointsr/cscareerquestions

For more foundational stuff, I'd look at:

GitFlow - a successful Git branching model - This is pretty much the prototypical Git usage model. I have seen it used pretty much everywhere I've worked that used Git, and a lot of software supports the model by default (Atlassian Stash, SmartGit, Git Tower, and more).
- Also take note of alternative Git usage models like GitLab Flow and GitHub Flow. They fit rather different use cases, and GitFlow is typically used for software that follows a more old-school release model where releases happen periodically, or you need to support multiple production releases at any given time. GitLab and GitHub flow are geared more toward software that only sees a single version in production at any given time, and very common release cycles (e.g. daily or even shorter).
  
  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.
How to write a commit message

No one's really gonna ask you about this, but you should develop a habit of writing great, clear, and concise commit messages.
Continuous Delivery and Continuous Integration

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.
Test-Driven Development and Behavior-Driven Development

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.
Stemming from the last point, know how to write good unit tests and how they differ from integration tests or acceptance tests.
Code organization - a lot of this will likely be influenced by the language/toolset you're working in, but you'll be interested in learning about Layered Architecture and software packaging metrics.
Generic software design - all sorts of acronyms to read about and absorb, like YAGNI, KISS, DRY, and SOLID. Also, the Unix philosophy, which guided a lot of development of software for Unix and Linux these days. There will also be patterns that apply to specific languages or types of software, but the stuff above is rather generically applicable.

Beyond those links, some books that cover a lot of general material are:
Clean Code
Pragmatic Programmer
Mythical Man-Month
Software Estimation - Okay, software estimation is really gonna be complex and difficult until you get a lot of experience, and even experienced developers get it wrong. I don't think it's particularly necessary to read this book when you're starting out.
Domain Driven Design - I love this book - it's about breaking down complex software designs.
Release It! - Nygard is a pretty battle-tested developer, so this book is about approaching software design practically rather than in a vacuum separated from real-world application.

u/Alborak · 2 pointsr/programming

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#

u/toadgoader · 2 pointsr/statistics

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

u/shagieIsMe · 2 pointsr/cscareerquestions

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.

u/cescquintero · 1 pointr/devco

u/pocketmnky · 1 pointr/webdev

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.

u/Enigma3613 · 1 pointr/programming

Thanks for the recommendation!

What do you think about his books on Rapid Development and Software Estimation?

u/Poloniculmov · 1 pointr/webdev

There's a good book about this, written by the guy who wrote "Code Complete".

u/Swordsmanus · 0 pointsr/programming

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.

Reddit reviews Software Estimation: Demystifying the Black Art (Developer Best Practices)

13 Reddit comments about Software Estimation: Demystifying the Black Art (Developer Best Practices):

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