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?
- 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.
Direct download: 103_Illegal_Argument_Episode_103.mp3
-- posted at: 12:48am FJT