how did we end up here
play

How did we end up here? Todd Montgomery Martin Thompson How bad - PowerPoint PPT Presentation

How did we end up here? Todd Montgomery Martin Thompson How bad can things really be? Software Project Success Rates Successful Challenged Failure Ad-hoc 49% 37% 14% Iterative 61% 28% 11% Agile 60% 28% 12% Traditional 47% 36%


  1. How did we end up here? Todd Montgomery Martin Thompson

  2. How bad can things really be?

  3. Software Project Success Rates Successful Challenged Failure Ad-hoc 49% 37% 14% Iterative 61% 28% 11% Agile 60% 28% 12% Traditional 47% 36% 17% - Dr Dobbs 2010

  4. Software Project Success Rates – by Team Size < 10 11 - 25 > 25 Ad-hoc 70% 58% 40% Iterative 88% 68% 55% Agile 83% 70% 55% Traditional 69% 51% 50% - Dr Dobbs 2010

  5. Well that’s the optimistic view!

  6. Software Project Success Rates Successful: 32% Challenged: 44% Failure: 24% – Standish Group Chaos Report 2010

  7. Software Project Failure Rates < $350,000: 20% $350,000 - $1,000,000: 25% > $1,000,000: 28% – Gartner 2012

  8. In a study of over 5400 large scale projects (> $15m) 17% go so badly that they threaten the existence of the company undertaking them – The McInsey Group with Oxford University 2012

  9. Sacred Cows - It’s BBQ Time!!!

  10. Enterprise Software

  11. ent • ter • prise noun \ ˈ en-t ə (r)- ˌ prīz \ : a project or activity that involves many people and that is often difficult : the ability or desire to do dangerous or difficult things or to solve problems in new ways Source: http://www.merriam-webster.com/

  12. Naming Matters !!!

  13. Product Management

  14. Minimum Viable Product ?

  15. Product Owner ?

  16. Technologists ARE part of the business

  17. Take responsibility for ROI

  18. How can I get an answer for the minimum investment?

  19. Agile Methods

  20. Water-scrum-fall

  21. What really matters?

  22. Need to focus on learning, feedback cycles, and outcomes

  23. There is an uncomfortable truth…

  24. “What would have been different if you were not involved?”

  25. Manifestos

  26. Agile NoTCP Reactive

  27. Build on the shoulders of giants

  28. Shared Mutable State

  29. “…Shared Mutable State...” the most feared words in computing

  30. …if not they should be!

  31. Shared Mutable State should only be used for systems programming

  32. Embrace append-only, single writer, and shared nothing designs

  33. If you don’t... math will hunt you down and there is nowhere to hide!

  34. Universal Scalability Law 20 18 16 14 12 Speedup 10 8 6 4 2 0 1 2 4 8 16 32 64 128 256 512 1024 Processors Amdahl USL

  35. Be ruthless in reducing complexity

  36. Text Encoding

  37. But it’s human readable...

  38. Binary is hard to work with...

  39. Big Data

  40. Communications Battery life and bandwidth?

  41. Synchronous Comms

  42. Bad things will happen!!!

  43. Synchronous Communication is the crystal meth of distributed programming

  44. Causes a coupling in location and time

  45. Errors need to be first class messages

  46. Are your micro services on crystal meth?

  47. Abstraction

  48. “All non -trivial abstractions, to some extent, are leaky.” - Joel Spolsky

  49. “The detail of underlying complexity cannot be ignored.”

  50. “the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise” - Dijkstra

  51. We could say the main issue is that people don’t understand abstractions...but...

  52. Sins committed in the name of Abstraction

  53. ORMs !!!

  54. Functional Programming

  55. What is the biggest issue with functional programming?

  56. Functional Programmers

  57. Functional programming is NOT the answer to multi-core

  58. Software Transactional Memory was a failed experiment!

  59. Universal Scalability Law 20 18 16 14 12 Speedup 10 8 6 4 2 0 1 2 4 8 16 32 64 128 256 512 1024 Processors Amdahl USL

  60. No Mechanical Sympathy?

  61. However there is genuine brilliance in functional programming

  62. Collaborate and great things can happen...

  63. Throw hardware at it… development is too expensive

  64. The free lunch is over… we cannot be sloppy anymore…

  65. Loops L0 1534 µops LB 28 µops LB 28 µops

  66. Code must be simple and composable

  67. Cache Sub-System MOB L0(I) – 1.5k µops 128 bits / cycle 16 Bytes / cycle TLB LF/WC Pre-fetchers Buffers L1(D) - 32K L1(I) – 32K 32 Bytes / cycle 32 Bytes / cycle TLB Pre-fetchers L2 - 256K 32 Bytes / cycle Ring Bus QPI Bus QPI PCI-e Memory Controller Controller Memory L3 – 8-20MB System Agent Channels

  68. Patterns of access and locality are key to performance

  69. Memory Sub-System Performance Accumulated Bandwidth Improvement Latency Time

  70. Accumulated Network Improvement Bandwidth CPU Cores Storage Capacity Memory Capacity Response Time Time

  71. What does this mean for software?

  72. Think in terms of transformation and flow of data – not code!

  73. Diversity

  74. Testosterone Driven Development

  75. What did the Carnegie Mellon studies show?

  76. Fake it until you make it…

  77. “As soon as you realise that most people don’t know what they are doing the world makes a lot more sense…” – Farley’s second law

  78. We need to look seriously at training programmers

  79. Coaching and Apprenticeships

  80. “The most important thing I've accomplished, other than building the compiler, is training young people .” - Grace Hopper

  81. “'Do you think we can do this?' I say, ‘Try it .’ And I back 'em up. They need that. I keep track of them as they get older and I stir 'em up at intervals so they don't forget to take chances. - Grace Hopper

Recommend


More recommend