Engineering Ideas #7
Automatic programming, two tenets of complex systems, monolith first, pair programming, core software development values, entrepreneurial culture
John Feser, Swarat Chaudhuri, Isil Dillig have created a program synthesizer capable of recreating pretty advanced functional algorithms:
We have used λ2 to synthesize a program originally invented by Barron and Strachey. Danvy and Spivey call this program “arrestingly beautiful” and believe it to be “the world’s first functional pearl”.
The program is required to produce the Cartesian product of a set of lists.
Barron and Strachey’s pearl to implement this transformation looks like this:
cprod xss = foldr f [] xss
where f xs yss = foldr g  xs
where g x zss = foldr h zss yss
where h ys qss = cons(cons(x, ys), qss)
Give the examples below, synthesises exactly this program in ~84 seconds.
 -> []
[] -> 
[, ] -> 
[[1,2,3], [5,6]] -> [[1,5],[1,6],[2,5],[2,6],[3,5],[3,6]]
You may say that this is very far from generating useful real-world programs. But think how long would it take you to write the algorithm above yourself? Is it less than 84 seconds? I think the machine power to apply brute force shouldn’t be discounted. And it’s easy to imagine the above synthesizer could be used to generate small utility functions in real projects.
By Lorin Hochstein
In his 2018 paper titled The theory of graceful extensibility: basic rules that govern adaptive systems, Woods describes the two assumptions of the adaptive universe:
Resources are always finite.
Change is ongoing.
At first glance, the assumptions sound banal. Nobody believes in infinite resources! Nobody believes that things will stop changing! Yet, when we design our systems, it’s remarkable how often we don’t take these into account.
A refreshing perspective from Martin Fowler:
I've noticed a common pattern.
Almost all the successful microservice stories have started with a monolith that got too big and was broken up
Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.
This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile.
However, he himself acknowledged back in 2015 that this a very nuanced question and the opposite approach, as to start building a brand new system of microservices, might sometimes be a better alternative. At least, we shouldn’t choose it blindly.
The counter-argument says that starting with microservices allows you to get used to the rhythm of developing in a microservice environment. It takes a lot, perhaps too much, discipline to build a monolith in a sufficiently modular way that it can be broken down into microservices easily. By starting with microservices you get everyone used to developing in separate small teams from the beginning, and having teams separated by service boundaries makes it much easier to scale up the development effort when you need to. This is especially viable for system replacements where you have a better chance of coming up with stable-enough boundaries early.
This is a practical overview of pair programming setup, benefits, and challenges by Birgitta Böckeler and Nina Siessegger. What I found most evocative though in this article is the conclusion, which echoes some of the ideas from Daniel Coyle’s The Culture Code:
We talked a lot about the benefits of pair programming, but even more about its challenges. Pairing requires a lot of different skills to get it right, and might even influence other processes in the team. So why bother? Is it really worth the hassle?
For a team to be comfortable with and successful at pair programming, they will have to work on all the skills helpful to overcome its challenges: Concentration and focus, task organisation, time management, communication, giving and receiving feedback, empathy, vulnerability - and these are actually all skills that help immensely to become a well-functioning, collaborative and effective team. Pairing gives everybody on the team a chance to work on these skills together.
Consider this headline from Harvard Business Review: "Diverse Teams Feel Less Comfortable - and That's Why They Perform Better". The authors are making the point that "Homogeneous teams feel easier - but easy is bad for performance. (...) this idea goes against many people's intuitions".
In this talk, Pia Nilsson describes measures her team at Spotify took to get over the uncomfortable friction initially caused by introducing practices like pair programming. Among other things, she mentions feedback culture, non-violent communication, psychological safety, humility, and having a sense of purpose.
Evan Bottcher distils the software design and development strategy to four core values:
Fast feedback: unit tests, CI, pair programming
Repeatability: automation, infra as code, containers, data immutability
Simplicity: software design, TDD
Clean code: design, refactoring, collective code ownership
These principles apply to mobile and web development, backend development, data engineering, and Cloud and Dev Ops alike.
A simple answer to whether to practice TDD or not (or any other XP/Agile practice):
So what if you don’t use TDD? Then, I’d be asking what you have in place to ensure your design is simple and you have good, fast feedback. If you can convince me that the thing you’ve replaced TDD with is working (or that you’ll know when it’s not), then I’ll be happy. Same with pair programming, or any others of our core practices.
Brian Chesky (CEO of Airbnb) explains what culture is, in essence:
Culture is simply a shared way of doing something with passion.
And why it is important:
Why is culture so important to a business? Here is a simple way to frame it. The stronger the culture, the less corporate process a company needs. When the culture is strong, you can trust everyone to do the right thing. People can be independent and autonomous. They can be entrepreneurial. And if we have a company that is entrepreneurial in spirit, we will be able to take our next “(wo)man on the moon” leap.