of abstraction • Abstractions allow us to build software systems that do sophisticated things; they are the shoulders we stand upon – and provide to others • Abstractions are qualitative; good ones allow us to hide gory implementation details – to build castles atop them and tunnels beneath • Bad ones, however, leak: instead of sealing implementation details, they seep them – yielding systems that are unwieldy and brittle • In the 1980s, one particular aspect of abstraction was top of mind… OXIDE
became unnecessarily entangled with one another, we have complexity • Fred Brooks famously called this accidental complexity, differentiating it from the essential complexity endemic to a particular problem • Complexity doesn’t merely accrue, however – it can explode… • Uncontained accidental complexity in one component can become essential complexity in something that must interact with it! OXIDE
synonymous with one another – and joined to form a single (suffocating!) dogma • Java was shoved everywhere: web applets, desktop applications, office suites, network computers (!), operating systems (!!), microprocessors (!!!) • These broadly died under their own weight – but Java saw real traction in the commercial, server-side applications of the enterprise… OXIDE
Cambrian explosion of abstraction: EJB, JSP, JDBC, JNDI, RMI, RMI-IIOP, JMX, JAXP, JAX-RPC, SAAJ • However revolutionary Java had been at birth, through the late 1990s J2EE was clearly constructed – and by the early 2000s, accreted • Java had rebellions with it, e.g. Spring (“a fresh start after the ‘winter’ of J2EE”) – but the hegemony of Java was cracking under the sheer weight of the complexity • The time was right for a larger rebellion… OXIDE
successful technology… • …but its efficacy was ultimately limited by its dogma and its complexity • These are not unrelated! • Ultimately, the elimination of the Java monoculture was healthy – and the 2010s saw several different revolutions in software systems OXIDE
been drifting around in software since the late 1960s, its use ebbing and flowing with broader trends • With the rise of LLMs to assist in software development – and then especially the rise of agentic coding workflows in late 2024 – the temptation to anthropomorphize LLMs as labor became too great… • The metaphor of a software factory is being seized upon with little knowledge or appreciation of manufacturing! • A software factory is effectively all engineering change orders! OXIDE
compose systems drives us towards developing simple, powerful abstractions • This is our drive to cognitive efficiency in a system – what Larry Wall famously called the programmer virtue of laziness • LLMs lack the virtue of laziness – they are biased to the complex • Moreover, their limited context makes them tautologically emergent… OXIDE
always been the enemy of systems – and it is simple to make the system complicated! • LLMs are extraordinarily powerful – but they are a tool • If we leave LLMs to their own devices, we risk systems that collapse under the weight of their accreted complexity • To make effective use of LLMs, our (human!) abstractions are more important than ever – and the code very much still matters! OXIDE
Simple Made Easy • Fred Brooks’s timeless 1986 essay, No Silver Bullet – Essence and Accident in Software Engineering • Michi Henning’s outstanding retrospective, The Rise and Fall of CORBA • Oxide and Friends, No Silver Bullet and Engineering Rigor in the LLM Age • RFD 576 Using LLMs at Oxide OXIDE
bcantrill
siromi
sansantech
leveragestech
dada4386
satokan
ryotarai
shreyas1009
tomokusaba
taiki45
kitagawaz
k_adachi_01
konippi
inesmontani
michielstock
seathinner
reverentgeek
addyosmani
kimpetersen
nikkihalliwell
samtorres
andyhume
geoffreycrofte
davetheseo
axbom
