ADRs are similar, yet the important point is not the format of the design log entry, but it's usage with AI.
with design log, we ask the AI to create the ADR or log entry, but unlike ADR we
1. require the AI to ask question and we answer.
2. require the AI to update the design log after implementation with any drift from the original design.
Both of the above help to make the AI more precise and prevent context drift.
Having taken part in building the Wix microservices architecture, I have to say that I understand and accept the critique of the article. Microservices is not a magic architecture, it solves some problems with the price of others.
When we stared Wix, we stared as a monolith - at 2006. In 2008 we split this monolith into two services due to different SLA - building websites and serving websites.
In 2011 we stared splitting the monoliths into micro services to solve software delivery pipeline - ability to move fast and scale with number of developers. Today we have about 20,000 deployments of new software every year, with over 1000 developers.
At Wix we are constantly investing a lot to maintain the microservices architecture and make it productive for our developers. We are making tools and utilities to return DRY into microservices architecture (think CDC support, GDPR support, Monitoring support, Scaling, Access Control, etc.).
My takeaways -
* Microservices do not come for free. You have to invest in making it work for you
* When building a startup - build a monolith. Break it down later when you understand what you need.
* We as an industry do not understand how to build micro services. There are a lot of fundamental aspects of microservices that are not commonly known / understood or ready as of the shelf solutions.
VB and Delphi reference architecture was 2 tier - client and database. With this reference architecture, you are right about the security and distribution problems. You just reminded me of the shareware market and the hacked shareware markets...
However, early on, around 1998, people started talking on 3 tier architecture of client - server - database on both platforms. There where even attempts to build web pages using both platforms (and later on .Net), which failed because of a lot of reasons, one big reason was not understanding the advantages of CSS.
Having worked for 10 years on both Delphi and VS, I understand the experience you are talking about. Having the ability to draw UI is amazing, and super productive. For business applications, it is amazing.
However, I still remember at around 2002 that we where asked to build specific custom user experiences, I think it was around reports, and using VB or Delphi was a lot of programming using draw commands... while using HTML and CSS it was fairly easy, even with the browser differences of CSS.
Any custom component in VS or Delphi (I am talking atomic components, not composite) requires using basic draw commands, and a lot of them.
The end result was that both platforms are not as expressive in terms of UI as the web, you cannot compare basic draw commands to structured CSS.
How? when you need to build any application with custom graphics or UX, in VB you are gonna writes tons of lines of code, while using CSS you just write 2-3 declarations.
I do not think the problem with VB was the language.
I think it was the graphic / UI expressive power, a simple way to add and create custom components.
At the same time that both VB and Delphi reached peak usage, the web started to show how easy it is to express graphically and UI using CSS. When you have to write tons of lines of code in VB to get to the same as 3 lines of CSS...
VS, and Delphi, are the masters of creating desktop applications.
However, both failed to port to the web, and them to mobile.
There are a lot of reasons why they failed -
* missing graphical expression capabilities for customer facing websites
* using languages that are not native JS, preventing them from utilizing the JS eco-system
* Vendors (Google, Apple) who for their own reasons kept mobile development native on their language and tools.
And many more reasons.
Last, both have paved the way for low code application builders for enterprises, which are mostly aimed at internal systems (not customer facing).
Worth noting that we, at Wix, have built the Wix dev platform learning from VB and Delphi, creating a website builder platform with similar concepts (I am the creator of Velo by Wix, the Wix dev platform, and having 10 years experience programming VB and Delphi).
I agree. Web Designers and Developers will always be needed for the more unique look and feel, more unique animations and specific functionality.
I think the role of AI generated site is to help getting a better result fast, both for non professionals, but also for professionals as a starting point.
website personalization is a huge evolving market, which at the moment only works for super large ecomm sites with large and well trained marketing teams.
It makes a lot of sense that we will see disruption in this area using some AI powered stuff.
with design log, we ask the AI to create the ADR or log entry, but unlike ADR we 1. require the AI to ask question and we answer. 2. require the AI to update the design log after implementation with any drift from the original design.
Both of the above help to make the AI more precise and prevent context drift.