I really like listening to Software Engineering Radio episodes, especially when cleaning up the carnage once the kids are asleep. Over time I have gotten quite a lot of useful insights from the interviews. Kudos to the team!
273: How to get software estimation right
What I really like about this episode is how the interviewee first acknowledges, that estimates are a) often misused/misunderstood by Business as commitments and b) engineers often use bad methods (e.g. expert opinion) to make estimates, so that there is a reason they have a bad reputation.
His general opinion on estimates is that they should be like a suite case: you should get one that is big enough to handle the stuff, but not too big. It needs to be close enough, but need not be the perfect size. Maybe you will have to sit on the suitcase to get it closed, but that is OK. Main Takeaways:
- Another way to put it, is that: Estimates are an assessment of capabilities to deliver something
- Use historical data for estimates before projects start. On Day 0, compare the new one to previous projects and use as a base to say “it will probably take not longer than 2x this”
- The best data for estimation is actual project data, so that should be used as soon as possible
- Cone of uncertainty is what happems on a good Project
- There is no sense in estimating in detail at beginning of a project
- The intrinsic risks of a project usually dwarf the extrinsic risks by far, which is one of the reasons why estiamtes are so often wrong. The biggest intrinsic risk is that Requirements are misunderstood
- Scrum is an estimation Nirvana - you esimate before the Start, keep estimating right after the beginning and changes that come in are also estimated. The biggest value is probably how accurate project data can be obtained very early, after just a few sprints (as opposed to months)
- McConnell recommends a “Waterfall for requirements, development as Scrum” approach, to be able to give accurate estimates
- One of the advantages of story points is that they scale with actual velocity - once velocity increases, you do not have to update all your estimates
- Planning Poker is an instance of something called Structuted Group decision activities - planning poker
263: Why does everyone want to build Distributed Systems?
I really like how Camille Fournier starts the episode with the classic definition of a Distributed System, that is even more true in the age of cloud providers: Your Maschine does not work because some Computer you did Not know about failed.
Main takeaways from the episode: * Building a distributed system is now very easy thanks to cloud provisioning. Sometimes it seems as if we let Engineering build distributed Systems simply because it is fashionable and Fun. However the above caveat still holds: Building a DS always means introducing werid errors (Network, downstream errors…) you would not have without. * If you decide to build a DS think about which the Level of consistency every Level of Data requires. Then decide what software to use (e.g.Mongo for Data that can be recobstructed) * There are two real reasons for building a DS: Scalability and fault tolerance. Unfortunately the two work against each other