Talking Architecture With Kevlin Henney

Systems get bigger, technologies reach further, practices mature, advice changes... or at least some of it does. Some guidance remains unaffected by the passing of paradigms, the evolution of technology or the scaling of development: break your software into small, cohesive parts defined by clear interfaces and sound implementations, all the while striving for simplicity. The excuses for not doing so are as predictable as they are problematic. But if you want to create legacy code, make sure code is arbitrarily partitioned into large, incoherent parts characterised by unwieldy interfaces and incomprehensible implementations.
While there are many definitions of what a legacy system is, common to almost all perceptions of a legacy system is the concept of size - specifically, lots of it. The phrase 'small legacy system' can be considered an oxymoron. This talk sets out to re-assess and reassert the importance of thinking and implementing small as an essential property of software systems - yes, even the large ones.
About Kevlin:
Kevlin is an independent consultant and trainer based in the UK.
His development interests are in patterns, programming, practice
and process. He has been a columnist for various magazines and websites, including Better Software, The Register, Java Report and the C/C++ Users Journal. Kevlin is co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series.
He is also editor of 97 Things Every Programmer Should Know
For more engineering updates and insights:
* Follow us on Twitter → / wixeng
* Subscribe our monthly newsletter → www.wix.engine...
* Visit our blog → www.wix.engine...
* Follow our Medium publication → / wix

[@Wix-Engineering]

For more engineering updates and insights: * Visit our blog: www.wix.engineering/blog * Follow us on: Twitter: twitter.com/WixEng * Visit us on GitHub: github.com/wix * Subscribe to our monthly newsletter: www.wix.engineering/subscribe * Follow our Medium publication: medium.com/wix-engineering * Listen to our podcast: www.wix.engineering/podcast * LinkedIn: www.linkedin.com/showcase/wix-engineering/

[@saicollections4762]

Jkk

[@phillipkalusek9561]

This is an unbelievable, spectacular presentation and I'm really jealous about.... 1.) ...his skill to present his presentations 2.) ...the way he builds his presentations 3.) ...the knowledge he has about the world and programming

[@charleygrossman8368]

Also his ability to provide apt analogies to complex subjects which we can easily take with us to apply and look for in our work!

[@l-cornelius-dol]

It is so nice to see someone promoting austerity in code and systems in today's day of waste. I owned a ZX81, and with my 16K expander pack I had so much memory. Then I got my ZX-Spectrum with 48K RAM!!

[@rushnbh]

The main takeaways after this presentation are 1) use the right tools where needed 2) try to refrain from overcomplicating or oversimplifying. Nometheless it is better to have a too simple solution than a fairly complicated one 3) the programmer's mind (as in cognitive capacity) is the reference scale of software development 4) Conway's law is unavoidable 5) trust your fellow programmers 6) don't feel attached to the code. You don't use it, don't keep it 7) they used to write pretty amazing software back in the days And the most important: Business limits and user requirements ultimately dictate the architecture, so know what are you doing and what is it's purpose if you want to design timeless software.

[@peterixxx]

The one thing about throwing away large systems or parts of them is that you can actually learn a lot about the system in the process of throwing it away. What I do with things I don't understand is tear them apart, piece by piece and see what stops working and why. That way, you expose the hidden dependencies within.

[@danielmilyutin9914]

I wish I could study Kevlin's production code.

[@ViktorEngelmann]

I'm working on a quite large (meaning: it has many features) software. The thing is that - since I'm working on it alone, I'm forced to cut back every time I'm about to lose oversight. And I have always managed to do that so far. Find the fat, find common ideas in them, abstract it out, replace the fat with simple usage of the more abstract thing. BOOM.

[@MrNorthCat]

Great talk, great person, a lot of things to think about. Thank you! And thanks for sharing!!

[@MidnightSt]

this henney guy has a great talk. a single great talk. what i dislike is how he goes around conferences and each time he's giving that single talk he renames it and pretends it's a new one.

[@HessianISR]

The art of giving talks my dude

[@Achrononmaster]

@1:17:00 The "Big Ball of Mud" paper by Foote and Yoder, starts out by noting code bases that look like a big ball of mud are out-competing more refined architectures. Now that's interesting. If you think about the human brain do you think of elegant pristine architecture, or a mess of tangled neurons. It's a mess! My guess is that instead of avoiding big balls of mud, maybe for some problem highly complex domains like general purpose AI you actually want to build in robustness against things that make big mud balls of code unusable, and actually find ways to use them. Think of your giant mud balls of code as small parts of a giant competitive & cooperative agent system, i.e., deliberately explore going in the opposite direction to overall simplicity, but do so in a smart way so that each little modular bit of code within the giant mud ball retains unix-lore elegance and simplicity.

[@nyanray]

This guy's been eating his Alan Kay vegetables, I think. Great talk!

[@BryonLape]

My parents must have had the same thoughts as Kevlin's when they named me.

[@morthim]

"all code is technical debt, some just has a higher interest rate" all code is technical debt and side effects.

[@sergi0YT]

He actually uses the word 'samizdat'!

[@purpinkn]

48:30 I guess wix uses a camera builder too bc they can't be bother to move it up

[@bra5081]

Interesting how business English uses words borrowed from French/Latin as opposed to the words of Germanic origin people usually use. I am curious to know if that comes from French words considered as more upper class or from globalisation of business. It is also interesting that English words are being more and more used in Business French and IT French and any other languages I would bet.

[@MartinChaov]

But I love one letter variable names :)

[@ZhengCheng]

second time hearing the "name his son tory." just couple minue ago first time saw this guys video. hmm.. and people in comment section say it's waste of time? not sure if i should keep watching. the top comment say it's awesome but i am not sure

[@effsixteenblock50]

The irony in Wix sponsoring the talk...

[@bartvanderwal6730]

Hmm... interesting talk. But @15 min around there, I disagree it's not turtles all the way down in software. It's a nice image, but the analogy does not fit. I think you CAN make an analogy to buildings. In software there ARE some atomic blocks, microprocessor instructions, and bytes/words (adressable memory locations) that kind of a thing. And it's not even turtles all the way down to that level. In higher order languages, I'll assume OO languages it builds up with all kind of structures from keywords/variables, loop construction with some scope, up to functions and start/end blocks, up to classes/structs, then to packages/namespaces, then to projects/jars but also things like threads/processes, then to intercommunicating processes and networked stuff, load balanced processes, client/server architecture, caching in the middle or at both end points. Perhaps you could throw containers, virtual machines somewhere in there too. All these are not even different kinds of turtles, but very different kind of animals.

[@bartvanderwal6730]

PS And you also very much need all these different way of modularisation at scale levels. The Java community found out the encapsulation mechanism provided by private and public properties (and protected and other stuff in between) was not sufficient to scale all the way up, as the new module system of Java (or OSGi before that) showed (to fix 'package hell'). Microservices is yet another form that's now an alternative for these modules. And I haven't even mentioned the (conceptual) layers in a layered architecture common in applications, or bounded contexts from DDD, which don't necessarily correlate with packages/projects/namespaces or these microservices. Perhaps they should, I'm not enough of a software architect yet to have that clear, but I estimate a real architect would also say that depends on the context. So thats even more animals... :)

[@happie88]

I'm start intrigue on how he designs he's applications and the architecture, frameworks he's done. ha ha ha ha ha

[@PaulSebastianM]

I will name my next kid after an UUID. 😂

[@taklamakanprime]

What was this talk so long?!

[@lefteriseleftheriades7381]

Save yourself 1.3 hours and watch some video that actually says something

[@rja421]

Down voted as he started complaining about Brexit. So bitter lol.

[@ComradeSmirnov]

I had a ZX Spectrum :)