Episode 103 - Productivity and Estimation

Join Mark, Greg, and new co-host Peter as we discuss Language Productivity and Estimation.

• Using Scala will make you less productive - Is Productivity King? There are many more things in “development” which will lower your productivity than the language you eventually implement the solution in. I (Mark) think I made the comment I've never seen scala as being "a more productive language", but a more flexible, adaptable, etc. language which may lead to more productivity, but productivity is WAY more the sum of intangible parts of development
• How do you measure productivity in a language, and when should you expect to get results, e.g. 6 months, 1 year, 2 years - 5 years?
• Is there a correlation between small, modular, artifacts and static typing? does having a contract get better with smaller service ( even if generic type contracts )
• Is static typing a fractal cost on your code base. The better you write your code the more cost you incur?
• Static typing suits large method and class as you pay the tax less times?
• How do you determine the productivity of a new language?
• Statically typed javascript (typescript)

• How does switching languages affect how you handle time estimates?
• How do you handle time estimates in general? (Mark) I’ve often seen it said rather than just estimate how long it will take, estimate how long it will take Person X to do it ( if they’re doing the work, taking into account things you know about their productivity/skill level/work load etc.) - you may know Clojure/Scala well, but with DevY is to do the work and not yet fully up to skill with the toolset.....
• Development estimates are only accurate if you are maintaining velocity. What error margin and corrective multiplier is reasonable?
• What methods of estimate generation are good? Planning poker can be slow, but can be a great method of generating estimates.
• Function Point Calculations as a confirmation guideline
• How far out do you estimate, and how does YAGNI play into this.