partial README

[threepointone]

This isn't complete, but there should be enough for more people in the org to start reading/using it.

[sebinsua]

I was thinking that we could literally call them 'modules', but that might suggest that they might not contain UI? I think that'd be a mistake.

Another approach might be to rename app to host and rename widgets to apps, perhaps helping people to see 'apps' as React Components.

I like this most myself, but would like to see what other's ideas are?

[sanjayk]

app to host -> 👍
widgets to apps -> 🤔 -> is apps really accurate? modules = (business logic + UI) - runtime

[sebinsua]

Hah. I'm not sure.

The word module has a meaning in Node, so some might consider something a module even without UI.

I was thinking apps because that makes it clear that this is where we want people to put their apps, and it's clear then that these are renderable things.

[sanjayk]

apps really are thought of as only renderable things? Not as a thing that provides a runtime?

That is definitely not how I would define an app. Modules IMO are whole units that can exist without a runtime, like Node Modules, They need a runtime to run.

[sebinsua]

Interesting point. Now that I think about it, I have my own meaning of 'app' that is different from everybody elses. I guess I think about 'app' as more like 'app source code / definition' and not as the actual runtime. Need a new word for this...!

[threepointone]

tracking here #39

[sebinsua]

Nice way of describing things. You gave me the mental image of:

[sebinsua]

Happy to try to start brainstorming some of these things out if you want?

[threepointone]

That idea of a vector is exactly what I had in mind :) In fact I was thinking of it as multiple vectors around an origin.

Yeah totally feel free to add your ideas. I had a rough list that mixes both vectors and costs, copy pasting here, but I wanted to clean it up before adding it. Feel free to either use it or not -

• what is the cost of rolling out applications to more users? what manual/ automated effort does it take? What hardware costs are incurred?
• what is the cost of adding a feature to a codebase?
• what is the cost of adding more developers to a codebase?
• what happens when design is iterated faster?
• what does the codebase look like in 6 months? 1 year?
• what happens when more css is written?
• same, but js?
• can the application be scaled across platforms?
• what is the length of the feedback loop? In terms of time, or people? How is it affected by any of the previous factors? How does it block any of the others?
• how can a change be safely deployed/rolled back? how can we tell if there's anything wrong?

Let's do it in a separate PR so we don't block this one ofc.

[sebinsua]

I dug up this tweet this morning, which made the point that multirepo adds a cost to every team, while a monorepo adds a cost to a single centralised team. Perhaps we don't make this point here, since we are trying to talk about 'scaling SDLC' on its own, but I wanted to bring it up here at least.

I think what we've seen go wrong in many large companies is singular application's being spread out across repositories and falling foul of Conway's Law.

Spreading a single application across multiple repositories is a big mistake when they (a) have shared or singleton dependencies, or (b) communicate with each other using API contracts. If either of these things occur, you have a form of "distributed monolith" where your applications aren't actually independent, and there are certain 'breaking' changes which straddle repositories but yet need to be done in a single stroke. You need "atomic deployments" which you'd have gotten easily if you'd stayed in a single repo, and the organisation is forced into long-winded meetings about what multi-week/month process they can follow in order to do a lock-step upgrade without causing the whole release cycle to stop. Meanwhile your competitors working in a single repo are able to make the change with a codemod and an atomic deploy on the merge of their single PR.

Obviously there are many other ways that 'colocation' benefits the development of applications (and particularly those belonging to a single deployed unit). Like you mentioned previously: you can quickly refactor a property using an IDE and get type-checking or cheap tests to ensure that you've not broken anything, etc. The teams that I know of with applications made from lots of distributed applications that are 'changed' separately need slow and cumbersome integration tests and multiple deployment stages to ensure they've not broken anything, and have to invest in creating complicated tooling to fix a problem they effectively gave themselves.

[sebinsua]

It's good. I wrote some comments that might help you extrapolate more, but you can merge if you want.

[sanjayk]

A section for Recipes?

Not sure if Styling would be a in the concerns section or have it's own section

[matt-d-webb]

maybe remove misguided :-)

"... We want to introduce a well defined approach for scaling both our development tools and processes, where we have explicitly focused on avoiding introducing any additional / unnecessary complexity. Or trying to solve too many 'problems' at once"

[threepointone]

Nice.

[matt-d-webb]

We need more emojis - everyone loves an emoji in a readme! 🎉 💣

[threepointone]

went through every emoji, can't think of which one would fit here 🤔

[matt-d-webb]

I did the same after leaving my comment. Operation get a cool logo! 😄

[threepointone]

A section for Recipes?

Not sure if Styling would be a in the concerns section or have it's own section

I added it as a line item in concerns right now, but happy to revisit. I think the concerns/usecases section will get pulled out of the readme into other pages, it's going to fairly heavy.

[threepointone]

I'm going to land this, let's iterate as and when.