Software architecture failing: tech writing is biased towards what the big ones do, which usually doesn’t fit most other contexts – but, who got fired for choosing IBM, right? Although I feel connected to this rant at an emotional level, I do think it’s necessary to elaborate more and make a positive contribution: help to create and spread that alternate history of software development. How do you do it? Hat tip: Fran.
The best career advice I’ve received, by Nicholas Zakas.
(…) the number-one indicator of a successful team wasn’t tenure, seniority or salary levels, but psychological safety. Think of a team you work with closely. How strongly do you agree with these five statements?
- If I take a chance, and screw up, it will be held against me
- Our team has a strong sense of culture that can be hard for new people to join.
- My team is slow to offer help to people who are struggling.
- Using my unique skills and talents come second to the objectives of the team.
- It’s uncomfortable to have open honest conversations about our team’s sensitive issues.
Teams that score high on questions like these can be deemed to be “unsafe”. Unsafe to innovate, unsafe to resolve conflict, unsafe to admit they need help.
I’ve been reading how Google organizes its codebase: they maintain a hyper-large repository containing everything, since the beginning of the company. I guess you may find Gmail, Photos, or AdWords there. You won’t find Android or Chrome, though – these are open source projects.
The repository is 86Tb of data, 1 billion of files, and 35 billion of commits. To manage this complexity, they needed to build their own tools: a home-grown Version Control System that can work effectively with such a repository at this scale, editor integration, building and automated testing tools, etc.
They develop all the code against trunk/master, meaning that if you are updating a library, you’ll also need to fix all applications that depend on it. Every project will be up-to-date, even abandoned projects.
The main reasons they claim this approach works for them are: it makes easier reusing blocks of knowledge company-wide and reduces the friction to contribute between projects/teams. UI primitives, building tools, etc, all are shared by any project that wants them, it’s just a matter of depending on the master version. It minimizes the costs of versioning/integration and the curse of being left behind when something is updated and you cannot keep up with the changes (the experts will do it for you!).
As a side effect, when working on libraries/frameworks it’s easier to understand the performance/impact/etc of a specific change (you can run tests on real projects) and to put together a task-force to fix issues affecting several applications.
This approach comes with downsides as well: they mention the amount of maintenance this setup requires even with all the tooling they have already built. With a monolithic repo, it’s easy to run into unnecessary dependencies that bloat the binary size of a project (and they do), the costs inherent to updating basic blocks used through the whole company, etc.
Another point is that it makes difficult having external contributors. Although they have a space in the repository for public/open-sourced projects, the article is unclear on how they manage 3rd-party contributions there – external programmers don’t have access to the internal building tools that Google programmers have. High-profile products like Android or Chrome -where outside contributors are expected and encouraged- have walked away from this approach.
I highly recommend reading the paper, it’s a pretty unique approach, and the article does a good job on presenting a balanced perspective.
mapand friends are more precise, sophisticated ways to talk about consistent patterns in data manipulation. Using them over
foris analogous to using the word “cake” instead of “the kind of food that you make by whipping egg whites and maybe adding sugar”.
Interestingly, you can eventually add new layers of category on top of established layers: just like saying that butter cakes constitute a specific family of cakes, one could say that
pluckis a specialization of
— Of vocabulary and contracts, Miguel Fonseca.
Precise words make communication more efficient. Arguably, software development is about managing conceptual complexity. Simple made easy, by Rich Hickey is a talk that tackles those two topics.
Two takeaways from this talk:
- The differences between simple and easy.
- Simplicity is an objective measure, and its units are the level of interleaving (of concepts). Simplicity should not be measured by the cardinality, the number of concepts/units.
- Easiness is a subjective measure, and it is related to how familiar you are with some topic or your past experience.
- We can make things simple with the tools we already have by favoring concepts that make things simpler to reason about, not quicker to write. He recommends:
Most programmers who have only casually used PHP know two things about it: that it is a bad language, which they would never use if given the choice; and that some of the most extraordinarily successful projects in history use it. This is not quite a contradiction, but it should make us curious. Did Facebook, Wikipedia, WordPress, Etsy, Baidu, Box, and more recently Slack all succeed in spite of using PHP? Would they all have been better off expressing their application in Ruby? Erlang? Haskell?
Relacionados: inversión y amortización en la selección tecnológica.
While it might look like an overnight success in hindsight, the story of React is actually a great example of how new ideas often need to go through several rounds of refinement, iteration, and course correction over a long period of time before reaching their full potential.
I want to push the idea that concepts are the real win, and they can be expressed in many different ways.
— Dumb Redux, Tom MacWright.