https://dev.to/rly

Who is Jilles?

www.jillesvangurp.com, and @jillesvangurp on *

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).

Inbot app - available for Android & IOS

Trends/contextFreelance 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

The modern workplaceCubicles, open spaces, …. really?!

Home office

Shared desks

Coffee shops

Couch surfing

Beach

Anywhere with internet access & suitable "work-context"

Industrial RevolutionEconomies 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"?

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

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?

Rest of this presentation ...Software Engineering is & "True-isms" about SE

Distributed Software Teams

First SE conferences organized by NATO in 1968 to solve the "Software Crisis"

http://homepages.cs.ncl.ac.uk/brian.randell/NATO/NATOReports/https://www.nasa.gov/50th/50th_magazine/scientists.html

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.

"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.

"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)

Seniority: Listen to uncle BobI 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.

http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html

SE Reality CheckEngineering 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)

The point about small teams:keep communication links down

Observation: Communication gets harder when you distribute ….

SE at scale: Big Software Projects/ProductsMultiple 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.

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.

Distributed Teams ...

https://www.youtube.com/watch?v=m_MaJDK3VNE

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

Distributed teams - challengesPracticalities: 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!

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.

The OSS communityDistributed 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 ...

Working with thousands of people looks like this ...

The Amazon FormulaWrite out new ideasIncentivize team members for the long term: make them ownersFollow the “two pizza rule.”Dedicate time to think about the futureRoutinely “check in” on long-term goalsWork backwards

Jeff Bezos

http://99u.com/articles/7255/the-jeff-bezos-school-of-long-term-thinking

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.

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.

Go Asynchronous - avoid bottlenecksExample 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.

Oh, the irony ….

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.

Q&A

@jillesvangurp, @inbotapp