Synthesizing data structure transformations from input-output examples
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.
There is no escape from the adaptive universe
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.
Monolith First
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.
On Pair Programming
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.
The core values and practices for building software at ThoughtWorks
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.
Don’t Fuck Up the Culture
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.
I see parallels here with the idea from Ron Davison’s The Fourth Economy (see summary by Taylor Pearson) that one of the drivers of growth in the 21st century will be entrepreneurship.
You can subscribe to new Engineering Ideas via RSS (e. g. using Feedly) or e-mail.
Top comments (0)