I've a theory about that too. If you take a software development project, 80% of the stuff takes 20% of the time and 20% of stuff takes 80% of the time. Let's call the former noise and the latter the bottlenecks.<p>A beginner estimates everything like the noise. So he's dramatically wrong. The novice though, estimates everything like bottlenecks. So he's dramatically wrong too.<p>This is actually why, in the industry, those agile methods works quite well. They handle that without people realizing.<p>The next key is to understand that estimates never determines the deadlines. What you can tell the stakeholders does.<p>So, the only way to succeed is to get the best dates you can from the stakeholders, then build the scope of the app accordingly. Then start treating everything like noise. Find the bottlenecks, focus on them, solve them, repeat.<p>Lastly, my manager setup a meeting with engineers to estimates the tasks in order to determine the launch date of our app. Before the meeting, he was saying that currently, the date was 15th of may. Then we've made the meeting, the novice estimates 750 days of work. 2 days after, we learn that the launch date is for 15th of may.
The problem with software estimates is making an estimate based off of the unknown for the first time.<p>Somebody asks you to walk a certain route through a city and give them an estimate of how long it's going to take. This is the first time you've ever been asked to do this. The route has stop lights, paved walkways, thick forest where you have to trample your own path, crowded areas, construction, and all sorts of other characteristics.<p>Think you're going to estimate that perfectly the first time? Nope. But guess what, you'll estimate it pretty well the next time you're asked to do the same route.<p>Therein lies the problem with software and estimates. Many times what engineers are asked to estimate is an unknown or has portions of unknowns. Without having solved the problem prior to being asked it's going to be real tough to estimate it properly. Second time around, your estimate is going to be much much better.<p>Most software is _not_ being asked to do something you've done once, twice or thirty times before. It's solving problems for the first time, estimates will be wrong.
Please, please, stop adding background music to these sorts of videos. It adds nothing but noise, and makes it hard to hear what the person is saying.<p>If for some inexplicable reason you feel compelled to add music to an informational video, turn the volume way down and pan it left or right so those of us without perfect hearing can have some idea what's being said. Better yet, add subtitles.
I'd like to give this a try, if only because I am not sure I believe anyone can accurately estimate non-trivial programming tasks. However, there doesn't appear to be a way to get any information without connecting your app to my github account. Seems like that process ought to go the other way around.
The thing that helped me the most personally with my estimate accuracy is estimating times beforehand, and then tracking the actual time and evaluating the accuracy of my own estimates. This is partly to get out of the mindset of trying to explain why past estimates were over/under and focus on being more accurate in the future.
This classic is still relevant today:<p>"Evidence Based Scheduling" by Joel Spolsky<p><a href="http://www.joelonsoftware.com/items/2007/10/26.html" rel="nofollow">http://www.joelonsoftware.com/items/2007/10/26.html</a>
I spent a lot of time messing around with doing something similar and not succeeding[1].<p>I wanted to do full-on decomposed 3-point estimates. Which means representing something that is not quite a tree and not quite a table. Turned out to be harder than I was smart. I got the underlying calculation code to work fine, but never worked out how to get HTML to play along.<p>I <i>did</i> find reading about estimation to be quite enlightening though. My suspicion is that most of the improvement seen in 3-point estimates comes from decomposing the elements, <i>not</i> from the PERT formula.<p>[1] <a href="http://confidest.com" rel="nofollow">http://confidest.com</a>
Please, please, please remove the background music -- it's annoying and overly loud.<p>The product looks very interesting, and it's nice that you offer a free tier. I'd hate to see your pitch hampered by the music.
I appreciate more attention being given to software estimates, but it seems like there's a lack of looking at the research in this area of software engineering. Most people have a single hocus-pocus equation that generates numbers they find convincing. Furthermore, it's often the case that these numbers are never changed over the life of the project.<p>That would be like predicting the weather with a single model, once, for the next three months. Of course that isn't going to work.<p>There are a few key points I think are often overlooked:<p>* Estimating is less about understanding time, and more about sizing a project and effort -- a study in software economics.<p>* Bottom-up estimates need to be based on historical performance. They should always be ranges and should include a notion of confidence. They should be democratically created if you're estimating for a team. You can do something simple (like Estimatr) or use a tool with a lot of data behind it (like Personal Software Process) - I do both.<p>* Top-down estimates should also be used. I often use COCOMO and COSYSMO, with monte carlo risk calculations (<a href="http://csse.usc.edu/tools/COCOMOII.php" rel="nofollow">http://csse.usc.edu/tools/COCOMOII.php</a>).<p>* The two approaches will give you two answers (both in ranges), with confidence intervals, which provides you a better sense of the size of the effort.<p>* Generating and publishing an estimate has a psychological effect on the team - consider that wisely (read Peopleware).<p>* Estimates are good for about two weeks, after that, they've become stale.<p>* You're not done with a project until you've recorded your performance data (for future bottom-up estimates).<p>* If a project is going to last three months or less, the research shows that nothing matters at all -- estimates, process, etc. -- do whatever keeps you/the team motivated.
Love the idea.<p>But, please, if you do a demo video please include an alternative way to learn about your product. I recommend either a list of features and/or screenshots.<p>I can't always watch video:<p>1. Sometimes I don't have the time<p>2. Sometimes I don't have audio<p>2a. My headphones are packed away<p>2b. I'm using my cell phone in a public place<p>3. You have 30 seconds to sell me or at least get me to learn more. If your video is 2 minutes make sure you don't burry the lead. I have no idea if this is the case here because I couldn't watch the video (see: 2a) :(<p>I'm using "I" and "my" here but I'm sure I'm not alone. Same goes for the trend in news sites now to only have a video on their website and no summary.
Thanks for making this, it's definitely useful and the UI is very clean.<p>Bug Report: If you enter a non-int value for one of the values it returns NaN. I.e. I entered 1.5 for a worst case estimate and it did that.
Reminds me somewhat of this[1] article.<p>[1] <a href="http://xkcd.com/1658/" rel="nofollow">http://xkcd.com/1658/</a>
Cool idea and this is probably the first time I've seen Vue.js be used in production (that I'm aware of). I'm in the US so I think changing the currency symbol (as a profile setting) would be a nice feature. Very clean design!