RebelCon 2018 - Scaling Technology and Organizations Together
In the lead up to RebelCon 2019, here are my notes from the 'Scaling Technology and Organizations Together' workshop I attended last year. All thoughts, views and opinions are my own.
RebelCon Overview
RebelCon is Ireland’s largest Software Engineering conference, which brings together the Cork software engineering community over 2 days of workshops and talks on the latest technology, culture and development practices in the software industry. For more information, visit http://rebelcon.io/.
2018 Conference Overview
McKesson were a proud sponsor of RebelCon 2018, which took place on Thursday 21st June and Friday 22nd June 2018 at The Clayton Hotel, Cork City. I attended the "Scaling Technology and Organizations Together" Workshop, presented by Randy Shoup, VP Engineering at WeWork, previously eBay and Google. The following are my notes from the workshop.
Scaling an Organisation
Main Notes
- Break large teams into small dedicated teams
- Move from waterfall (idea → develop → quality → operations) to full-stack teams
- Align teams to business problems by creating clear goals and metrics → this will result in teams growing by "cellular mitosis"
- Create small "service" teams. Create a symphony not a factory
- An ownership of software gives incentive to do the job well → this will result in reduced maintenance
- Half-remote teams and also half co-located teams just don't work → aim for full either remote or located teams
Side Notes
- Amdahl's law - https://en.wikipedia.org/wiki/Amdahl%27s_law
- Mel Conway, Extreme Prototyping - https://www.ustream.tv/recorded/114861629
- Jeff Bezos' 2 Pizza Rule - https://blog.bufferapp.com/small-teams-why-startups-often-win-against-google-and-facebook-the-science-behind-why-smaller-teams-get-more-done
- Google has 30,000 engineering people and can still innovate because each team has their own goals, objectives, etc...
Scaling a Development Process
Main Notes
- Deploy small units of work → easier to fix problems, easier to roll-back/roll-forward
- Understand that other business teams may not have the training in the discipline of problem solving, context and implications → try and help people analyse and think about the problem they are trying to solve when they come to you with a solution (e.g. if they ask you to add a UI button, try and understand that the problem is as it could be solved by something simpler)
- "Fewer things, more done" → get smaller features done with extra resources and release earlier (e.g. rather than having 5 iterations with 5 features to finish at last iteration with 1 person per feature, aim for regular feature releases by assigning more people to the features)
- Quality and reliability are priority
- Build one great thing instead of two half-finished things
- Done right does not equal done perfect → aim for the 80/20 rule - https://en.wikipedia.org/wiki/Pareto_principle
Side Notes
- Book recommendation: DevOps Handbook - https://www.amazon.co.uk/Devops-Handbook-World-Class-Reliability-Organizations/dp/1942788002
- Book recommendation: Lean Software Development - https://www.amazon.co.uk/Lean-Software-Development-Toolkit-Managers/dp/0321150783
- Book recommendation: Making Work Visible - https://www.amazon.co.uk/Making-Work-Visible-Exposing-Optimize/dp/1942788150/
- "A problem well stated is a problem half solved" - Charles Kettering
- If there are bottlenecks in your code during collaboration, allow other teams to suggest and make patches to your codebase
- Have a backlog of small items, that you generally wouldn't get a chance to work on and that are not high priority. At times when work is light and people are looking for something to work on, they can pull from this backlog.
Topic: Scaling an Architecture
Main Notes
- Rearchitecting a system is a sign of success not failure
- When attempting to migrate a system, choose a vertical slice (that goes through all the layers from start to finish) to rebuild → don't rebuild horizontally because then the value only comes at the end and it's much harder
Side Notes
- eBay are now on their 5th rewrite/generation of codebase (Monolithic perl → monolithic C++ → java → micro-services). During the eBay C++ monolithic stage, they were hitting limits on the number of maximum methods allowed per class and had approximately 3.4 million lines of code in a DLL
- Twitter are now on their 3rd rewrite/generation of codebase (Monolithic rails → js/rails/scala → micro-services)
- Amazon are now on their Nth rewrite/generation of codebase (Monolithic perl → C# → java/scala → micro-services)
- Book recommendation: Working Effectively with Legacy Code - https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052. This book is supposedly on the Google engineers required listing.
2018 Speakers Comments
The following are some of the speaker’s comments from after the event (RebelCon, 2019).
Figure 1: Melissa Perri, CEO of Produx Labs, Author of Escaping the Build Trap
Figure 2: Randy Shoup, VP Engineering at WeWork
Figure 3: Sam Newman, Author of Building Microservices
References
- RebelCon. (2019). RebelCon. [online] Available at: http://rebelcon.io/
- Figure 1: Melissa Perri, CEO of Produx Labs, Author of Escaping the Build Trap. [online] Available at: https://miro.medium.com/max/2400/1*Mk8z1-qei_8Ta2dJvbQ1Ng.jpeg
- Figure 2: Randy Shoup, VP Engineering at WeWork. [online] Available at: https://miro.medium.com/max/2400/0*knso_FIw9AWuYgYm.jpeg
- Figure 3: Sam Newman, Author of Building Microservices. [online] Available at: https://wizeline-website-assets.s3.amazonaws.com/wp-content/uploads/sites/8/2018/09/27113312/Screen-Shot-2018-09-27-at-1.31.44-PM.png









