Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Distributed cat herding


Published on

Presentation about managing distributed software teams.

Published in: Software
  • Real people just like you are kissing the idea of punching the clock for someone else goodbye, and embracing a new way of living. The internet economy is exploding, and there are literally THOUSANDS of great earnings opportunities available right now, all just one click away. ●●●
    Are you sure you want to  Yes  No
    Your message goes here
  • Earn Up To $316/day! Easy Writing Jobs from the comfort of home! ♥♥♥
    Are you sure you want to  Yes  No
    Your message goes here
  • hangout with me talking along with the slides
    Are you sure you want to  Yes  No
    Your message goes here

Distributed cat herding

  1. 1.
  2. 2. Who is Jilles?, and @jillesvangurpon * Java (J)Ruby Python Javascript/node.js Servers reluctant Devops guy Software Architecture Universities of Utrecht (NL), Blekinge (SE), and Groningen (NL) GX (NL),Nokia Research (FI), Nokia/Here (DE),Localstream (DE), Inbot(DE).
  3. 3. Inbot app - available for Android & IOS
  4. 4. Trends/context Freelance jobs & short term contracts are common Job security is a bit of a myth Internet tools mean it is easier than ever to work remote Most programmers don't actually live in San Francisco; how to use them? Building software requires a lot of different specialists Robots are eating our jobs
  5. 5. The modern workplace Cubicles, open spaces, …. really?! Home office Shared desks Coffee shops Couch surfing Beach Anywhere with internet access & suitable "work-context"
  6. 6. Industrial Revolution Economies of scale through - colocating resources - minimizing transport - scale by sharing resources - minimize space used - cheap, plentiful labor available locally Is all this still relevant if all you really need is specialists with a laptop + internet? Creative work doesn't happen in factories. Are you a "resource"?
  7. 7. Renovating your house analogy - Talk to an architect - Hire a foreman - Foreman gets brick layers, carpenters, electricians, painters, etc. to show up at the right time - Typically self-employed - You find a person that knows a few others and they work together to do the thing Very pre-industrial revolution, trust & relationship based. You don't get economies of scale by putting programmers in cubicles You don't get any benefit from only hiring local talent in crowded market It's a global village now, this is the post industrial revolution
  8. 8. How local are you really? Do you talk to people on different floors of your office building? Or down the street? Outside your team? How often? And about work? How many people do you interact with professionally on a day to day basis?
  9. 9. Rest of this presentation ... Software Engineering is & "True-isms" about SE Distributed Software Teams
  10. 10. First SE conferences organized by NATO in 1968 to solve the "Software Crisis" Water-fall: apply engineering principles to big SE projects Royce, Winston (1970), "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON, 26 (August): 1–9 Waterfall -> Spiral Development -> Rational Unified & 4+1 model -> Extreme Programming -> Scrum -> Kanban -> ... Sofware Engineering, a brief history At the start of the Apollo program, the onboard flight software needed to land on the moon didn’t exist. Computer science wasn’t in any college curriculum. NASA turned to mathematician Margaret Hamilton, of the Massachusetts Institute of Technology, to pioneer and direct the effort. With her colleagues, she developed the building blocks for modern “software engineering,” a term Hamilton coined.
  11. 11. "Laws" of Software Engineering (1) Conway's Law, "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations" Parkinson’s Law (1), "work expands so as to fill the time available for its completion" Parkinson's Law (2), "people in groups tend to give disproportionate weight to pointless discussions." Law of Demeter, principle of least knowledge. Each unit should have only limited knowledge about other units: only units "closely" related to the current unit. Each unit should only talk to its friends; don't talk to strangers. Only talk to your immediate friends.
  12. 12. "Laws" of Software Engineering (2) Peter Principle, "managers rise to the level of their incompetence." Brooke's Law, "adding manpower to a late software project makes it later" Two Pizza Rule (There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors)
  13. 13. Seniority: Listen to uncle Bob I estimate that the world, today, has twenty-two million programmers[2]. One of of every 300 people is a programmer. In the US it’s closer to 1%. But in 1974 the number of programmers worldwide was vastly smaller, and probably numbered less than 100,000[3]. That implies that in 40 years our ranks have increased by a factor of 220. That’s a growth rate of 14.5% per year, or a doubling rate of five years. If the ranks of programmers has doubled every five years, then it stands to reason that most programmers were hired within the last five years, and so about half the programmers would be under 28. Half of those over 28 would be less than 33. Half of those over 33 would be less than 38, and so on. Less than 0.5% of programmers would be 60 or over. So most of us old programmers are still around writing code. It’s just that there never were very many of us. What does this imply for our industry? Maybe it’s not as bad as Lord of the Flies, but the fact that juniors exponentially outnumbers seniors is concerning. As long as that growth curve continues[4] there will not be enough teachers, role models, and leaders. It means that most software teams will remain relatively unguided, unsupervised, and inexperienced. It means that most software organizations will have to endlessly relearn the lessons they learned the five years before. It means that the industry as a whole will remain dominated by novices, and exist in a state of perpetual immaturity.
  14. 14. SE Reality Check Engineering metaphor is a fallacy, there's more to it than blueprints & math Big heavy processes tend to not work as advertised Agile the good: adapting to changing reality; less upfront planning, building stuff fast that is actually useful Agile the bad: new bureaucracy (story points, retrospectives, velocity charts, ...), dogmatic application of unscientific ideas, waterfall in disguise, technical debt, .. Small teams are easier to manage, need less process (more Agile)
  15. 15. The point about small teams: keep communication links down Observation: Communication gets harder when you distribute ….
  16. 16. SE at scale: Big Software Projects/Products Multiple MLOC, tens of thousands of developers, reusing and depending on even more software, life span of decades, R&D value measured in billions. How do you 'engineer' such a thing? Simple Answer: don't. It just 'happens' organically. Software development happens in communities of practitioners. More Complex Answer: throw engineers at it, thousands of them, and hope for the best but start small and fail fast.
  17. 17. How to Engineer a 1 MLOC software system? ~constant: productivity of engineers is 10 LOC / day (controversial) 1 engineer, 100K days, or about 273 years, full time ;-) 10 engineers 10K days, about 27 years 100 engineers 1K days, about 2.7 years, starting to get doable 1 MLOC is comparatively small scale software Mythical Man Month: planning doesn't quite work like that.
  18. 18. Distributed Teams ...
  19. 19. Why? You want to build X, you need people with skills You know suitable people but they live in a different places Why not work together & why move to one place? It's easy to get started with people that you know, even when they are not local
  20. 20. Distributed teams - challenges Practicalities: Timezones, cultural differences, language barriers, tools, processes Formalities: who reports to who? who pays the bills? how do you hire/fire? Conflicts: stress + communication challenged people = cat fight Realities: people have different motives, goals, incentives, opinions Same challenges as non distributed but magnified by the fact that communication is harder: it's still software engineering! What didn't work before, now doesn't work even better!
  21. 21. OSS development …. they can do it. How? - Distributed by default - Many small projects - Some bigger projects - Reuse & depend on each other - Basis for 99% of most commercially shipping software and projects - Primarily funded by for profit software companies - this is NOT charity - Driven by people/companies deciding to do things that need doing from their point of view. - Work on a need to have basis.
  22. 22. The OSS community Distributed network of professionals, companies, and other stakeholders. Extremely well financed Work together out of necessity Collectively get more work done than any software company out there Formula for distributed: Look at the stuff they are NOT doing. So, it scales up. It also scales down ...
  23. 23. Working with thousands of people looks like this ...
  24. 24. The Amazon Formula Write out new ideas Incentivize team members for the long term: make them owners Follow the “two pizza rule.” Dedicate time to think about the future Routinely “check in” on long-term goals Work backwards Jeff Bezos
  25. 25. Stuff that doesn't work (aka. corporate shit I don't miss in my life) Standups and any process that requires them. This is where Scrum falls short. Forget about doing retrospectives, estimation sessions, and other BS bingo that comes with scrum. IT DOES NOT WORK. (Opinion: this is not specific to distributed teams, it just becomes even more obvious) Having long meetings over a phone with a large group. Just results in the wrong people claiming all the talking time while the rest mute and try to get some work done. Twitter is 1 alt+tab away... Trying to impose complicated processes, new ways of working, while at the same time you are onboarding new team members. Email, just don't.
  26. 26. Stuff that works (for us) Weekly short status calls. Agree times that fit everyone, e.g. 11 am instead of 9 AM. Everybody provides brief update. 20-30 minutes max. Weekly planning meeting: discuss business, blockers + KANBAN: done, in progress, next. Shared slides for each meeting on google docs: update before & during meeting. 1 on 1's are a great way to smooth out issues, avoid doing this in planning calls. Work backwards from business needs. What is blocking the business? What is blocking the technical solutions to the business blockers? How can we move forward? Most of us are "elsewhere", this forces us to be distributed.
  27. 27. Go Asynchronous - avoid bottlenecks Example bottlenecks: handovers, meetings, people availability, office hours, slow builds, complicated processes, anything that causes you to wait for something or someone. Don't wait for a meeting to announce that X is now ready when a simple @all message in Slack can do the job. Grab somebody's attention with a @<name> instead of waiting for the next scheduled meeting. Git is asynchronous if used properly: Send a pull request when you need somebody to look at something. Merge 'done' work to master branch (auto rolls out to server), keep master usable at all times. Automate as much as you can. CI, Deploys, etc. Chatops is a thing. Automated updates via slack are great to keep track of what is happening. Coordinate outcomes, not tasks. Outcomes have stakeholders and ownership.
  28. 28. Oh, the irony ….
  29. 29. Inter team communication = dependency mgmnt! People dependencies. Communicate daily with people that depend on you and with people that you depend on. Your org chart is a graph, not a tree. Team = cluster of people that need each other; this changes over time. Avoid tight coupling. Limit the number of people you depend on to progress. Avoid being a bottleneck for too many others. Delegate, prioritize, do 1 thing at the time. Learn to say no. Team cohesiveness. Make sure you have the right people, make sure everyone is working towards the same goals. Check this regularly. Small teams. Big teams have poor cohesiveness and large degree of coupling, lose a lot of time talking instead of getting stuff done. Demeter's law is relevant too: don't talk via intermediaries. Avoid Conway's law and restructure if needed.
  30. 30. Q&A @jillesvangurp, @inbotapp