Staying Grounded in Large Software Systems

A guest lecture I prepared for University of Toronto on staying grounded while building large software systems.

Transcript

1. STAYING GROUNDED in Large Software Systems Thursday, 28 February, 13
2. GEOFFREY WISEMAN geoffrey.wiseman@codiform.com http://geoffreywiseman.ca/ Thursday, 28 February, 13 My name is Geoffrey Wiseman.
3. SOFTWARE CONSULTANT http://codiform.com Thursday, 28 February, 13 I’m a software consultant.
4. WWW Thursday, 28 February, 13 I started my career roughly at the same time as the Web started. I’ve spent most of that time building web applications in a variety of technologies.
5. WEB + MOBILE Thursday, 28 February, 13 That means HTML, CSS, Javascript. I’ve worked on lots of platforms, but my focus is on Java, Ruby, Android and iOS, Postgres and MySQL.
6. ENTERPRISE Thursday, 28 February, 13 I’ve done a lot of work with enterprises of different shapes and sizes.
7. ENTERPRISE + WEB Thursday, 28 February, 13
8. LARGE SOFTWARE SYSTEMS Thursday, 28 February, 13 Lots of moving parts. Multiple client types. Servers working together. Networking and firewalls. Datastore replication and analytics. Cloud servers for spiky demand. External APIs and Integration.
9. STAYING GROUNDED Thursday, 28 February, 13 I’d like to talk about Staying Grounded in Large Software Systems.
10. WHY IT’S HARD • Technical Complexity • Organizational Complexity • Longevity Thursday, 28 February, 13 Notice two things here mention complexity.
11. COMPLEXITY Thursday, 28 February, 13
12. STRIVE FOR SIMPLICITY Not all complexity is necessary. Thursday, 28 February, 13 Large systems are often complex systems. Some of that may be necessary. Some of it is not. Make large systems as simple as possible.
13. “Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.” - Blaise Pascal Thursday, 28 February, 13
14. - Blaise Pascal I have made this longer than usual because I have not had time to make it shorter.” Thursday, 28 February, 13 It’s easier to address a subject with a lot of words than a smaller number of better-chosen ones. It’s easier to address a business/user need with a larger, more complicated system than a simpler, better-designed one.
15. SIMPLER IS easier for users to understand Thursday, 28 February, 13
16. SIMPLER IS easier for developers to understand Thursday, 28 February, 13
17. SIMPLER IS easier to maintain Thursday, 28 February, 13
18. SIMPLER IS easier to enhance Thursday, 28 February, 13
19. SIMPLER IS better for everyone Thursday, 28 February, 13
20. SIMPLER IS more important for Large Software Systems Thursday, 28 February, 13 Large Software Systems usually solve larger, more complicated problems. They have intrinsic complexity. They may require more complicated solutions. This makes it even more important to simplify wherever possible.
21. SIMPLER IS not easy Thursday, 28 February, 13 It’s hard to make things simple. Making things easy is not making them simple.
22. TECHNICAL COMPLEXITY Thursday, 28 February, 13 Very common in large software. There are many legitimate reasons for that.
23. SCALING Thursday, 28 February, 13 Most large software systems need to scale. Small software systems that need to scale usually become large software systems. Scaling can introduce a lot of complexity: distributed computing, caching, robustness.
24. CACHING Thursday, 28 February, 13 Caching is often necessary for scale. Which layers are caching what? Cache invalidation. Caches might also be distributed.
25. DISTRIBUTED COMPUTING Thursday, 28 February, 13 Distributed computing introduces lots of complexity: - concurrency issues - communication between distributed elements - harder to monitor, to automate deployment
26. THEN One CPU One Machine Thursday, 28 February, 13 Once, we could program a single chain of execution that ran on a single cpu inside a single machine.
27. NOW Multiple Threads in Multiple Processes in Multiple Virtual Servers on Multiple, Hyperthreaded Cores in Multiple Machines on Multiple Networks in Parallel all Communicating Thursday, 28 February, 13 Now we have: - multiple threads - in multiple processes - in multiple virtual servers - running on multiple hyperthreaded cores - in multiple machines on - multiple networks - all communicating - all running in parallel
28. CONCURRENCY Thursday, 28 February, 13 Race conditions. Locking; pessimistic and optimistic; Deadlocks. Shared state contention; semaphores, monitors.
29. COMMUNICATION Thursday, 28 February, 13 Between: threads, processes, machines, networks Over: firewalls, protocols Using: actors, channels, messages, queues
30. ROBUSTNESS Thursday, 28 February, 13 Systems get bigger, more complicated, more distributed. More things that can fail. Need to make overall system reliable. Throttling; circuit breakers; chaos monkeys.
31. BIG DATA Thursday, 28 February, 13 Vast quantities of data, or when caches or databases are very widely spread. Keeping consistency across all instances and all datastores can be too much trouble. Non-traditional datastores; eventual consistency; map-reduce; hadoop.
32. INTEGRATION Thursday, 28 February, 13 Integrating: - pre-existing systems - external apis and services - core systems with client systems - different technologies - different communication apis - REST; WS-*; Messaging; Database; Exchanging Data Files over FTP. - shared models, anti-corruption layer
33. MULTI-TENANCY Thursday, 28 February, 13 Before the web, multi-tenancy was a rarity. Different customers = different installs. Rise of SaaS makes this a bigger deal. Not only is separation important, can be in contracts.
34. MULTI-PLATFORM Thursday, 28 February, 13 Delivering your software to multiple platforms: - Windows, Mac, Linux - Android, iOS - Web and Native - Multiple Target Browsers - Bleeding edge makes this worse (e.g. offline)
35. ORGANIZATIONAL COMPLEXITY Thursday, 28 February, 13
36. “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” Conway’s Law Thursday, 28 February, 13 The environment in which you build software has a big impact on the software you build.
37. COMMUNICATIONS Thursday, 28 February, 13 Meetings. Conference calls. Politics.
38. PROCESS Thursday, 28 February, 13 Decision-Making Approvals. (incl. Clients?) Yearly reviews. Architecture review boards.
39. RECRUITING Thursday, 28 February, 13 Takes a lot of time.
40. “INNOVATION” Thursday, 28 February, 13 Patents. SR&ED.
41. DISTRIBUTED WORK Thursday, 28 February, 13 Can affect small companies too, when distributed. Harder to do well, but can have benefits. cf. Yahoo, GitHub, Automatic
42. LONGEVITY ⏲ Thursday, 28 February, 13
43. TECHNICAL DEBT Thursday, 28 February, 13 Technical bankruptcy - when a project is abandoned because it has accrued so much debt?
44. LEGACY CODE Thursday, 28 February, 13 Technical debt you aren’t responsible for. Strangler vines. Test then refactor. “Working effectively with legacy code.”
45. DEPENDENCIES CHANGE Thursday, 28 February, 13 Unless you write everything yourself.
46. DEPENDENCIES DON’T CHANGE Thursday, 28 February, 13 When you need them to, of course.
47. VERSIONING Thursday, 28 February, 13 Backward compatibility. Supporting older versions deployed to customers. Supporting older customizations made by customers. API Versioning.
48. RED FLAGS ⚑ Thursday, 28 February, 13 Things to watch for. These don’t prove problems, they’re just cues; indicators.
49. MISSED FOCUS Thursday, 28 February, 13
50. ARCHITECTURE ASTRONAUTS Thursday, 28 February, 13 Over-abstraction. Not directly connected to what you’re trying to solve. Focused on the architecture instead of the problem. “Wouldn’t you want?”
51. TECHNOPHILIA Thursday, 28 February, 13 New technology can be fun. New development technology can be fun for developers. I’m not saying you can’t use node.js, but do you know why you’re using it? JWZ: “Some people, when confronted with a problem, think ‘I know, I’ll use regular expressions.’ Now they have two problems.” Technophilia can help/hinder recruiting if you’re using a technology that people want to use, it will be easier to hire. If you’re using a technology people don’t want to use, it will be harder.
52. MASSIVE FORMALITY Thursday, 28 February, 13 Architecture review boards. Architecture frameworks. Governance.
53. PROCESS FOR PROCESS’ SAKE Thursday, 28 February, 13 Process is a means, not an end. What is the problem? How does this process solve it? Adopting a process wholesale. How people work is the implicit process; does it need to be explicit?
54. GRANDIOSE CLAIMS Thursday, 28 February, 13 Reality distortion field. “exponential leap” “as easy as”
55. VENDOR / ANALYST HYPE Thursday, 28 February, 13 Specialized version of grandiose claims. Gartner mentions. Appeal to authority.
56. PREDATORY VENDORS Thursday, 28 February, 13 No pricing model. “What are you using for?” Percentage-based pricing. Limited documentation or extensive configurability - consulting fees.
57. POOR COMMUNICATION Thursday, 28 February, 13 Can’t understand what they do - vendor, consultant, coworker. If they can’t explain, that’s their fault, not yours. Are they unable, or unwilling to explain? Or maybe it’s really, really complex. Does it have to be?
58. VAGUE DIAGRAMS Thursday, 28 February, 13 AML.
59. BUZZWORDS Thursday, 28 February, 13 Specialized version of poor communication. These can sometimes be acronyms or references to complex technology names gone overboard: WS Splat. Other times, they’re increasingly vague and meaningless: Web 2.0, AJAX, Cloud.
60. BEST PRACTICES Thursday, 28 February, 13 What problem is this supposed to solve? Do we have that problem? Will this solve it? Everything is a tradeoff. Don’t just think about benefits, think about costs, downsides. Almost no guideline is true for all situations. “Wouldn’t you want” Reasonable-sounding bad idea.
61. HYPER-CONFIGURABILITY Thursday, 28 February, 13 Use configuration to avoid decisions. Have an opinion. The opposite of “one thing well”
62. YAK-SHAVING Thursday, 28 February, 13 Very easy to get distracted by yak shaving; this is one of the problems with adopting a new technology.
63. OVER-DEPENDENT Thursday, 28 February, 13 Too many dependencies. Where to draw the line? Do you know what the dependencies are? What they’re used for? Does your project depend on multiple versions of the same dependency? Due diligence.
64. MORE TIME Thursday, 28 February, 13 We’ll go back to that when we have more time. When we have a chance. Temporary measure. Make sure you can live with it.
65. STAYING GROUNDED Thursday, 28 February, 13 Back to Staying Grounded.
66. NO SILVER BULLETS Thursday, 28 February, 13
67. THINK Thursday, 28 February, 13
68. EXPLICIT DECISIONS Thursday, 28 February, 13 Product design is about making tradeoffs, choices, elimination. Don’t “let things happen”. Make explicit choices. Slow down to hurry up.
69. USE YOUR JUDGEMENT Thursday, 28 February, 13 Even simple is a judgement call. Marco Arment, The Magazine, No Settings.
70. FOCUS ON NOW Thursday, 28 February, 13 Current needs. What’s the problem we need to solve right now.
71. YAGNI Thursday, 28 February, 13 Unable to predict the future. Even when flexibility is needed, the points of flex are unknown. Leather glove analogy.
72. CONSIDER TRADEOFFS Thursday, 28 February, 13 Not just pros, also cons. What is the impact of this choice to the project? What is the cost of it?
73. DEFER COMMITMENT (a little) Thursday, 28 February, 13 Lean. Last responsible moment.
74. SIMPLE TECHNOLOGY Thursday, 28 February, 13 Choose the primary tools in your toolbox carefully. Is this the right technology? What are its dependencies? Is it mature? Abandoned? What is its license? Why this?
75. SMALL TEAMS Thursday, 28 February, 13 Choose your team carefully. Prefer a small great team over dilution. This is hard. It’s easier if you only hire the people who you can’t afford not to hire.
76. SUSTAINABLE PACE Thursday, 28 February, 13 Massive growth is a problem everyone wants, but a sustainable pace will make it a lot easier to stay grounded.
77. SLOW DOWN Thursday, 28 February, 13 Don’t rush into things.
78. JUST ENOUGH Thursday, 28 February, 13 No more dependencies or processes than you need. That’s your call. But think about it.
79. 0 - 1 - ∞ Thursday, 28 February, 13 Zero-One-Infinity Rule Don’t bother with arbitary N values If you need more than one, support infinity.
80. THERE IS NO MORE TIME Thursday, 28 February, 13 If you can’t commit to getting back to it soon, you won’t come back to it later.
81. Q&A Thursday, 28 February, 13 Have any of you been involved in large software systems yet? What kind of projects and organizations are you interested in?
82. SEE ALSO • Rich Hickey’s talks on simplicity: • Simplicity Matters, Railsconf, 2012 or • Simple Made Easy, Strange Loop, 2011 Thursday, 28 February, 13
83. SEE ALSO • Architecture Astronauts: • Don’t Be Afraid of Architecture Astronauts, Joel Spolsky • Architecture Astronauts Take Over, Joel Spolsky • It Came from Planet Architecture, Jeff Atwood Thursday, 28 February, 13
84. SEE ALSO • Defer Commitment, Kelly Waters • Last Responsible Moment, Jeff Atwood • Last Responsible Moment Reconsidered, Alistair Cockburn Thursday, 28 February, 13
85. CC ATTRIBUTION • samurai by Gustavo Peres • electronic brain by Aranya Sen • data centre photo by Steven Kreuzer • complexity by Domenica Nardone • watch movement photo by Guy Sie • silver bullet by Ed Schipul Thursday, 28 February, 13
86. THANK YOU Geoffrey Wiseman geoffrey.wiseman@codiform.com http://www.codiform.com/ http://www.geoffreywiseman.ca/ Thursday, 28 February, 13