Paul Hammant, a software consultant, writes about trunk-based development, source control, dependency injection, legacy app replacement, and Smalltalk.
Commenters link it as a reference for trunk-based development, branch by abstraction, and his older posts on Angular, jQuery, and Smalltalk Envy.
> Incremental rewrites
You keep using this term and I don't think you know what it means. The Strangler pattern IS an incremental rewrite. You've suggested that it's possible to introduce incremental rewrites to old code and all I was clarifying is that by refactoring code written in an old framework (e.g. PHP 5.6) does nothing to eliminate technical debt (adds to it, in fact). The Strangler pattern is most often used when you want to switch languages (e.g. Java -> Rails) or when an older paradigm doesn't have a straight migration path (e.g. WebForms -> .NET MVC). The new code using the new framework essentially strangles the old code.
For the record, I've advised over 100+ software companies, which I would say about 60%+/- of them are experiencing some type of major rewrite and of those, 9/10 are because they simply can't upgrade an outdated/unsupported/poorly architecture software framework. Trying to refactor an unsupported framework is simply not an option. You (1) either migrate it to the latest (if possible) and refactor over time, (2) strangle it with the new framework, or (3) rewrite it. That's it. Every other topic discussed is simply just one of those but semantically wrapped in some engineering jargon or nuance.
This is all consistent with the examples here: https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/
- C++ -> Java Spring
- Powerbuilder/Sybase -> Swing
- VB6 -> .NET
- Java -> Rails
- Java/Swing -> Rails
The real world…
I have been slowly (last 4 or so years) moving away from microservices towards the "cookie cutter" (http://paulhammant.com/2011/11/29/cookie-cutter-scaling/) model (we didn't use that term of art) and been very delighted with the change. I had completely drank the koolaid on microservices, but after having to maintain them in production for a few years, changed my tune.
In my experience that "iterate and change the system easily and quickly" simply doesn't end up being true. That is the bait, but then comes the switch. Once you have a real system, heavily interdependent, the cost of changing things starts to go up greatly, and your ability to cleanly describe a working system becomes challenging. Answering simple management questions like "OK, so if we change X, what could break?"... "We should send out an email to all the teams to ask!" (ugh)
The problem is that for most significant changes to a component -- there are changes to the interface to that component. So you have 'the choice' -- (1) Maintain this interface forever or (2) Ensure all the teams transition off it by X date, via a deprecation system. Both work, and most companies seem to use a mix of both, they strive for (1) until it gets insane, then they do (2) and force everyone to upgrade to X version by Y date.. rinse and repeat.
We are currently doing the "fat binary" cookie cutter system. Our deploy is a single binary that does "all the things". There is a lot to like about this system. Easy to…
Fun fact ... "VisualAge for Java was implemented in Smalltalk and the Team facility used ENVY/Developer under the hood" [1]. Of course eventually that product and team morphed into Eclipse.
I was lucky enough to play as small part as a college-age intern working at an Object Technology International [2] Lab in Sydney.
I soaked in the pair programming, watching the screen flash by. I read every book they gave me (e.g. The Toyota Way, this was before XP / Agile books existed). I was amazed they actually paid me to work on these problems. I was so proud to make contributions and still remember fondly the hand-drawn diagram of the architecture passed down like a relic through the team. I am still inspired by their passion and commitment to delivery.
I definitely would not be the person I am today without the career defining experience working for Adrian Cho [3] and Dave Thomas [4] during that time. Periods like that are rare in a career - grab them if you can!
1 - https://paulhammant.com/2017/09/01/smalltalk-envy/
2 - https://en.wikipedia.org/wiki/Object_Technology_International
3 - https://www.adriancho.com/
4 - https://www.davethomas.net/
This looks very similar to Paul Hammant's "cookie cutter scaling" pattern (http://paulhammant.com/2011/11/29/cookie-cutter-scaling/), which I find equally baffling. Perhaps I've just never encountered the conditions which are favorable to it, but what I like about microservices is how they decouple every services' rate of change, and going back to lock-step deploys throws that all away.
> In addition, with a monolith, the work of monitoring, alerting, configuration, and a local development is paid once. But with a microservice design, that cost must be paid for every service.
The second sentence is only true if _every service_ actually rolls its own monitoring, alerting, etc. I cannot imagine a situation like that in practice. The standardization of those things (and more, such as build and deployment pipelines) is necessary to enable microservices in the first place. It's true that plenty of organizations committed to their microservice framework will also run some things outside of it, but I've never seen the ratio of things in the framework closer to 0 than 1.
I think emphasizing Servo is the wrong goal.
Ideally, when rewriting a large legacy app you want to take the StranglerApplication[1] approach. Netscape tried rewriting its software from scratch and we all know how that ended for Netscape[2] - Netscape is no more. Luckily, Firefox came from that whole mess. But I assume a lot of effort was lost, going from Netscape to Firefox.
In idealized scenario, Servo slowly starts taking replacing parts of Firefox. First URL parser and media player, then slowly DOM, CSS, Renderer, and finally takes over and rewrites JS VM.
The takeover is silent and gradual and user doesn't notices anything outside speed improvements. It's like some kind of silent Borg infection.
[1] http://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/
[2] http://www.joelonsoftware.com/articles/fog0000000027.html
That book is new to me. I wrote https://paulhammant.com/2013/05/07/android-and-the-art-of-war on Google vs MSFT and phones before the book. Mine's a perspective that doesn't mention Nokia or its leadership.
I did own a Treo and loved it up to the OG iPhone - I repaired the eff out of it in the hope that something worthy would come along. I kidded myself I would write apps for it. I'd previously played with Simbian tech (and met a very bitter Simbian team dev in London one "eXtreme Tuesday Club" meetup in 2003). I had a Psion Organizer way back and Palm pilot. I thought Palm's WebOS stood a chance. I still own a Ubuntu Phone that I don't use - single script QML apps would have been the killer, but all that's passed now.