Things You Can Learn from 101 Things I Learned in Architecture School

•

3 likes•2,195 views

Presented at NDC 2011 in Oslo (8th June 2011) Video available at http://www.everytalk.tv/talks/666-NDC-Things-You-Can-Learn-from-101-Things-I-Learned-in-Architecture-School The book 101 Things I Learned in Architecture School, by Matthew Frederick, is a great little book on the skills and practices needed by architects of the built environment. It is not a book about software architecture, but it turns out to have a lot to offer software architects and other software development roles. Rooted in a different creative and design–centred discipline, it offers alternative and fresh perspectives on familiar concepts, reinforcing practices and providing inspiration.

Software Education News & Politics

“Architecture
is the thoughtful
making of space.”
Louis Kahn

Design an architectural
space to accommodate
a specific program,
experience, or intent.

True architectural style
does not come from a
conscious effort to create
a particular look. It
results obliquely — even
accidentally — out of a
holistic process.

Properly gaining control
of the design process
tends to feel like one is
losing control of the
design process.

A good designer isn't
afraid to throw away a
good idea.

“Less is more.”
Ludwig Mies van der Rohe

No design system is or
should be perfect.

The more specific a
design idea is, the
greater its appeal is
likely to be.

“Always design a thing
by considering it in its
next larger context.”
Eliel Saarinen

The most effective, most
creative problem solvers
engage in a process of
meta-thinking, or
“thinking about thinking.”

Three levels of knowing
SIMPLICITY is the world view of the child or
uninformed adult [...].
COMPLEXITY characterizes the ordinary
adult world view. [....]
INFORMED SIMPLICITY is an enlightened
view of reality. It is founded upon an
ability to discern or create clarifying
patterns within complex mixtures. [....]

Create architectural
richness through
informed simplicity or an
interaction of simples
rather than through
unnecessarily busy
agglomerations.

Beauty is due more to
harmonious relationships
among the elements of a
composition than to the
elements themselves.

Any design decision
should be justified in at
least two ways.

Two points of view on
architecture
ARCHITECTURE IS AN EXERCISE IN TRUTH.
A proper [system] is responsible to universal
knowledge and is wholly honest in the
expression of its functions and materials.
ARCHITECTURE IS AN EXERCISE IN NARRATIVE.
Architecture is a vehicle for the telling of
stories, a canvas for relaying societal myths,
a stage for the theater of everyday life.

Things You Can Learn from 101 Things I Learned in Architecture School

More from Kevlin Henney

Presented at Foo Café (2019-03-21) Video at https://www.youtube.com/watch?v=tLSKLLxrZyY Programmers use coding katas to kick the tyres of their programming languages, paradigms and practices. Typically anchored in a TDD cycle, katas are simple problems that give programmers the opportunity to exercise deliberate practice and explore different approaches, whether programming style, pair programming or test-first programming. But the simplicity can be deceptive, with many programmers tiring of these katas too soon, missing out on some of the more mind-bending and paradigm-expanding opportunities on offer. This session will pick on a couple of katas and dig deeper into TDD, lambdas, language(s), (dys)functional programming and Alcubierre drive. It will present code in a variety of languages, highlight the weaknesses of some common mantras, play around with ideas — and blend code, humour and general nerdiness to be both an enjoyable and educational session.

Get Kata

Kevlin Henney

Presented at ACCU Conference 2018 (2018-04-12) Video at https://www.youtube.com/watch?v=mrY6xrWp3Gs When programmers describe code as 'procedural', it’s generally not meant as a compliment. There is a belief that we have collectively moved pass such thinking and onto better paradigms. But a paradigm is no more than a pattern language, a family of solutions fit for a context. Change the kind of problem you are solving and you may find a different solution makes sense — even, in these days where pure functions battle it out with classy objects, procedural programming. This talk takes a look at some of the past, present and future of procedural programming, looking at how there’s more to it than many first assume, how it has informed and continues to influence language design and how it relates to other paradigms, such as functional and OO.

Procedural Programming: It’s Back? It Never Went Away

Kevlin Henney

Presented at ACCU Cambridge (2018-10-23) Throw a line of code into many codebases and it's sure to hit one or more testing frameworks. There's no shortage of frameworks for testing, each with their particular spin and set of conventions, but that glut is not always matched by a clear vision of how to structure and use tests — a framework is a vehicle, but you still need to know how to drive. The computer science classic, Structure and Interpretation of Computer Programs, points out that "Programs must be written for people to read, and only incidentally for machines to execute". The same is true of test code. This talk takes a deep dive into unit testing, looking at examples and counterexamples across a number of languages and frameworks, from naming to nesting, exploring the benefits of data-driven testing, the trade-offs between example-based and property-based testing, how to get the most out of the common given–when–then refrain and knowing how far to follow it.

Structure and Interpretation of Test Cases

Kevlin Henney

Keynote present at Agile Tour Vienna (2018-10-06) Velocity. Sprints. More points, more speed. An obsession with speed often overtakes the core values of agile software development. It’s not just development of software; it’s development of working software. Sprints are not about sprinting; they’re about sustainable pace. Time to market is less important than time in market. Full-stack development is normally a statement about technology, but it also applies to individuals and interactions. The full stack touches both the code and the world outside the code, and with that view comes responsibility and pause for thought. Doing the wrong thing smarter is not smart. The point of a team is its group intelligence not its numbers. Is scaling up the challenge, or is scaling down the real challenge? The distraction and misuse of speed, velocity, point-based systems, time, team size, scale, etc. is not the accelerant of agile development. Agility lies in experimentation, responsiveness and team intelligence.

Agility ≠ Speed

Kevlin Henney

Keynote presented at NewCrafts (2018-06-18) Video available at https://vimeo.com/276832516 It has been said that immutability changes everything. But what does that mean in practice? What does it mean for existing code that looks more like the mutant apocalypse than an elegant application of mathematical thinking? Immutability can be an ideal that is hard to reach. Refactoring, on the other hand, is all about the art of the possible. In this talk we'll be clarifying motivation and exploring some approaches to help reducing state mutability in code.

Refactoring to Immutability

Kevlin Henney

Keynote presented at GOTO Chicago (2018-04-26) Video available at https://www.youtube.com/watch?v=AbgsfeGvg3E Everything is changing. Everything is new. Frameworks, platforms and trends are displaced on a weekly basis. Skills are churning. And yet... Beneath this seemingly turbulent flow there is a slow current, strong and steady, changing relatively little over the decades. Concepts with a long history appear in new forms and fads and technologies. Principles are revisited. Ideas once lost to the mainstream are found again. In this keynote we revisit the present through the past, looking at the enduring principles that shape programming languages, architecture, development practice and development process, the ideas that cycle round, each time becoming perhaps a little better defined, a little more mature, and look to see what else might be on the horizon.

Old Is the New New

Kevlin Henney

Presented at SwanseaCon (2017-09-26) We default to considering systems from an insider's perspective; the view from outside can be quite different. Can we apply this inversion to more than just requirements? We may say we want testing, but what do we want from testing? We may say we want logging, but what do we want from logging? We may say we want clean code, but what do we want from clean code? We may say we want an agile process, but what do we want from an agile process? These are harder questions, but their answers can make for better solutions.

Turning Development Outside-In

Kevlin Henney

Presented at .NET South West (2017-07-25) Code is basically made up of three things: names, spacing and punctuation. With these three tools a programmer needs to communicate intent, and not simply instruct. But if we look at most approaches to naming, they are based on the idea that names are merely labels, so that discussion of identifier naming becomes little more than a discussion of good labelling. A good name is more than a label; a good name should change the way the reader thinks. A good name should describe structure with intention, as opposed to the affix-heavy approach common to many naming conventions in current use, where the addition of more prefixes and suffixes becomes homeopathic, diluting the meaning. Good naming is part of good design. This session looks at why and what it takes to get a good name.

Giving Code a Good Name

Kevlin Henney

Presented at code::dive (2016-11-15) Video available at https://www.youtube.com/watch?v=brfqm9k6qzc It is all to easy to dismiss problematic codebases on some nebulous idea of bad practice or bad programmers. Poor code, however, is rarely arbitrary and random in its structure or formulation. Systems of code, well or poorly structured, emerge from systems of practice, whether effective or ineffective. To improve code quality, it makes more sense to pick apart the specific practices and see their interplay — the cause — than to simply focus on the code itself — the effect. This talk looks at how a handful of coding habits, design practices and assumptions can systematically balloon code and compound its accidental complexity.

Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...

Kevlin Henney

Presented at code::dive (2016-11-16) Video available at https://www.youtube.com/watch?v=yl25p91flLY Ask programmers what comes to mind when you say concurrency and most are likely to say threads. Ask what comes to mind when you say threads and most are likely to say locks or synchronisation. These assumptions are so deeply held that they define and constrain how programmers are taught and think about concurrency: thread safety is almost synonymous with the avoidance of race conditions and the guarded protection of mutable state. But this is only one quadrant of four possibilities, a quadrant diagram partitioned by mutable–immutable along one axis and shared–unshared along another. Modern C++ supports programmers in all four quadrants, not just the synchronisation quadrant. From immutability to actors, this talk will take a look at patterns and practices that encourage thinking and coding outside the locked box.

Thinking Outside the Synchronisation Quadrant

Kevlin Henney

Presented at GOTO Amsterdam (2017-06-13) Video available at https://www.youtube.com/watch?v=YyhfK-aBo-Y What is risk? Many people aren't sure, but it's not just uncertainty: risk is exposure to uncertainty. Instead of just plastering over the cracks, security should also involve reducing the size and number of cracks, reducing the opportunities for cracks to appear, reducing the class of errors and oversights that can open a system to failure instigated from the outside. We can learn a lot from other kinds of software failure, because every failure unrelated to security can be easily reframed as a security-failure opportunity. This is not a talk about access control models, authentication, encryption standards, firewalls, etc. This is a talk about reducing risk that lives in the code and the assumptions of architecture, reducing the risk in development practices and in the blind spot of development practices.

Code as Risk

Kevlin Henney

Keynote presented at SATURN (2nd May 2017) Video available at https://www.youtube.com/watch?v=MS3c9hz0bRg "It's just a detail." Have you ever said that or been told that? Whether it's about implementation or requirements, we often use the word detail to suggest that something is not important enough to worry about. There are so many things to worry about in software development that we need to prioritize—too much detail, not enough focus. The problem is that in software, the details matter because that is what software is: lots of details brought together in combination. If we don't focus on the details, we get debt, defects, and delays.

Software Is Details

Kevlin Henney

Presented at Agile Bath & Bristol (21st March 2017) If software development is a co-operative game, as Alistair Cockburn observed, then what kind of game is Scrum? Lots of people are playing it — or say they are — but there seems to be some disagreement about what the point of the game is, how to play it and even, in many cases, what the rules are. This talk looks at Scrum and other agile approaches through the lens of nomic games, hypothesis-driven development and fun.

Game of Sprints

Kevlin Henney

Presented at the European Bioinformatics Institute (17th March 2017) We often talk about good code — that we would like to write it, that there isn't enough of it, that it should not be considered an optional attribute of a codebase. We often talk about it but, when it comes to being precise, we don't always agree what constitutes good code, nor do we necessarily share a common view on its value.

Good Code

Kevlin Henney

Keynote presented at European Testing Conference (9th February 2017) What happens when things break? What happens when software fails? We regard it as a normal and personal inconvenience when apps crash or servers become unavailable, but what are the implications beyond the individual user? Is software reliability simply a business decision or does it have economic, social and cultural consequences? What are the moral and practical implications for software developers? And when we talk of ‘systems’, are we part of the ‘system’? What about the bugs on our side of the keyboard? In this talk we will explore examples of failures in software and its application, and how they affect us at different scales, from user to society.

The Error of Our Ways

Kevlin Henney

Presented at DevTernity (1st December 2016) Video available at https://www.youtube.com/watch?v=SUIUZ09mnwM Habits help you manage the complexity of code. You apply existing skill and knowledge automatically to the detail while focusing on the bigger picture. But because you acquire habits largely by imitation, and rarely question them, how do you know your habits are effective? Many of the habits that programmers have for naming, formatting, commenting and unit testing do not stand up as rational and practical on closer inspection. This talk examines seven coding habits that are not as effective as programmers believe, and suggests alternatives.

Seven Ineffective Coding Habits of Many Programmers

Kevlin Henney

Presented at GOTO Nights (20th September 2016) The SOLID principles are often presented as being core to good code design practice. Each of S, O, L, I and D do not, however, necessarily mean what programmers expect they mean or are taught. By understanding this range of beliefs we can learn more about practices for objects, components and interfaces than just S, O, L, I and D. This talk reviews the SOLID principles and reveals contradictions and different interpretations. It is through paradoxes and surprises we often gain insights. We will leave SOLID somewhat more fluid, but having learnt from them more than expected.

SOLID Deconstruction

Kevlin Henney

Presented at 8th Light University London (13th May 2016) Do this, do that. Coding from assembler to shell scripting, from the mainstream languages of the last century to the mainstream languages now, is dominated by an imperative style. From how we teach variables — they vary, right? — to how we talk about databases, we are constantly looking at state as a thing to be changed and programming languages are structured in terms of the mechanics of change — assignment, loops and how code can be threaded (cautiously) with concurrency. Functional programming, mark-up languages, schemas, persistent data structures and more are all based around a more declarative approach to code, where instead of reasoning in terms of who does what to whom and what the consequences are, relationships and uses are described, and the flow of execution follows from how functions, data and other structures are composed. This talk will look at the differences between imperative and declarative approaches, offering lessons, habits and techniques that are applicable from requirements through to code and tests in mainstream languages.

Declarative Thinking, Declarative Practice

Kevlin Henney

Presented at Dynabyte (13th April 2016) I do not think it means what you think it means. What object means to many programmers is managers, views, controllers, getters and setters, megalithic frameworks, spaghetti inheritance, lots of mocks and large classes. But is this what object-oriented development is really about? The original vision of objects was focused more on the problem domain than the solution domain. Objects were supposed to be small, properly encapsulated abstractions composed from other objects. Classes were a mechanism for expressing objects, not the editing black hole of the development process. Think you know objects? This talk strips back the layers of habits, frameworks and legacy to cast objects in a new but old light.

Object? You Keep Using that Word

Kevlin Henney

Driven to Tests

Kevlin Henney

More from Kevlin Henney (20)

Get Kata

Procedural Programming: It’s Back? It Never Went Away

Structure and Interpretation of Test Cases

Agility ≠ Speed

Refactoring to Immutability

Old Is the New New

Turning Development Outside-In

Giving Code a Good Name

Clean Coders Hate What Happens To Your Code When You Use These Enterprise Pro...

Thinking Outside the Synchronisation Quadrant

Code as Risk

Software Is Details

Game of Sprints

Good Code

The Error of Our Ways

Seven Ineffective Coding Habits of Many Programmers

SOLID Deconstruction

Declarative Thinking, Declarative Practice

Object? You Keep Using that Word

Driven to Tests

Recently uploaded

APVP,apvp apvp High quality supplier safe spot transport, 98% purity

amy56318795

Facemoji Keyboard released its 2023 State of Emoji report, outlining the most...

rajkumar669520

JustNaik Solution Deck (stage bus sector)

Max Lee

How to pick right visual testing tool.pdf

Testgrid.io

The Impact of PLM Software on Fashion Production

Wave PLM

5 Reasons Driving Warehouse Management Systems Demand

Canary7-Warehouse Management System

COMPUTER AND ITS COMPONENTS PPT.by naitik sharma Class 9th A mittal internati...

naitiksharma1124

AI/ML Infra Meetup May. 23, 2024 Organized by Alluxio For more Alluxio Events: https://www.alluxio.io/events/ Speaker: - Eric Wang (Software Engineer, @Uber) Uber has numerous deep learning models, most of which are highly complex with many layers and a vast number of features. Understanding how these models work is challenging and demands significant resources to experiment with various training algorithms and feature sets. With ML explainability, the ML team aims to bring transparency to these models, helping to clarify their predictions and behavior. This transparency also assists the operations and legal teams in explaining the reasons behind specific prediction outcomes. In this talk, Eric Wang will discuss the methods Uber used for explaining deep learning models and how we integrated these methods into the Uber AI Michelangelo ecosystem to support offline explaining.

AI/ML Infra Meetup | ML explainability in Michelangelo

Alluxio, Inc.

How to download files safely from the internet ? Source: <a href="https://www.downloadsafely.com/">Download Safely</a> -Welcome to Secure Downloading&Surfing. Learn how to safely download files and protect your data while browsing the web. Let's dive into the world of secure surfing! Understanding the Risks Discover the potential threats associated with downloading files from the internet and the impact of malicious software on your device.

how-to-download-files-safely-from-the-internet.pdf

Mehmet Akar

How to install and activate eGrabber JobGrabber

eGrabber

This is a classic migration case study (the past, current and the future) at scale from a world-wide company transitioning from Confluent Platform and Confluent Cloud to self-managed Apache Kafka on Kubernetes using Strimzi. At Maersk, we have been architecting, designing and implementing our 3rd generation Event Streaming Platform. This platform is based on Kubernetes in Azure and using Strimzi to operate Apache Kafka at large scale, highly reliable, segregating data based on isolated use cases. Our 2nd generation was based on OnPrem Confluent Platform and Confluent Cloud and this presentation is the story of this migration and reasoning behind it. Furthermore, we would get into details on how we monitor (Grafana, Prometheus), alert (GoAlert and alert as code), operate and provide self-service solutions on top of Strimzi to enable business critical application in Maersk, implemented in GoLang using the GitOps deployment model with Flux and Kustomization among others. Finally, if time allows we will end with a demo of an open-source self service tool to monitor and explore the cluster with most wanted features such as topic message browsing and configuring and restarting connectors.

StrimziCon 2024 - Transition to Apache Kafka on Kubernetes with Strimzi.pdf

steffenkarlsson2

Migrating your customer service data from Zendesk to Re:amaze can significantly enhance your support operations, but it requires careful planning and execution. "A Guideline to Zendesk to Re:amaze Data Migration" is designed to assist businesses in managing this transition smoothly and efficiently. This comprehensive guide covers all aspects of the data migration process, ensuring that your data is transferred accurately and effectively.

A Guideline to Zendesk to Re:amaze Data Migration

Help Desk Migration

Secure Software Ecosystem Teqnation 2024

Soroosh Khodami

Scenarios are the central artifact of the Behaviour Driven Development (BDD) process. Although many teams use scenarios and tools like Cucumber or SpecFlow to automate them, in many cases their scenarios contain a lot of details, particularly test data, and therefore they become too complicated to support collaboration with the business. The "essential" principle of scenario writing (scenario formulation) states that only those details should be included in the scenario that are relevant for the outcome. This talk provides help for those who struggle implementing this principle or would be interested to learn how you can create brief and maintainable scenarios.

Tree in the Forest - Managing Details in BDD Scenarios (live2test 2024)

Gáspár Nagy

AI/ML Infra Meetup May. 23, 2024 Organized by Alluxio For more Alluxio Events: https://www.alluxio.io/events/ Speaker: - Junchen Jiang (Assistant Professor of Computer Science, @University of Chicago) Prefill in LLM inference is known to be resource-intensive, especially for long LLM inputs. While better scheduling can mitigate prefill’s impact, it would be fundamentally better to avoid (most of) prefill. This talk introduces our preliminary effort towards drastically minimizing prefill delay for LLM inputs that naturally reuse text chunks, such as in retrieval-augmented generation. While keeping the KV cache of all text chunks in memory is difficult, we show that it is possible to store them on cheaper yet slower storage. By improving the loading process of the reused KV caches, we can still significantly speed up prefill delay while maintaining the same generation quality.

AI/ML Infra Meetup | Reducing Prefill for LLM Serving in RAG

Alluxio, Inc.

INGKA DIGITAL: Linked Metadata by Design

Neo4j

AI/ML Infra Meetup May. 23, 2024 Organized by Alluxio For more Alluxio Events: https://www.alluxio.io/events/ Speaker: - Lu Qiu (Data & AI Platform Tech Lead, @Alluxio) - Siyuan Sheng (Senior Software Engineer, @Alluxio) Speed and efficiency are two requirements for the underlying infrastructure for machine learning model development. Data access can bottleneck end-to-end machine learning pipelines as training data volume grows and when large model files are more commonly used for serving. For instance, data loading can constitute nearly 80% of the total model training time, resulting in less than 30% GPU utilization. Also, loading large model files for deployment to production can be slow because of slow network or storage read operations. These challenges are prevalent when using popular frameworks like PyTorch, Ray, or HuggingFace, paired with cloud object storage solutions like S3 or GCS, or downloading models from the HuggingFace model hub. In this presentation, Lu and Siyuan will offer comprehensive insights into improving speed and GPU utilization for model training and serving. You will learn: - The data loading challenges hindering GPU utilization - The reference architecture for running PyTorch and Ray jobs while reading data from S3, with benchmark results of training ResNet50 and BERT - Real-world examples of boosting model performance and GPU utilization through optimized data access

AI/ML Infra Meetup | Improve Speed and GPU Utilization for Model Training & S...

Alluxio, Inc.

AI/ML Infra Meetup | Perspective on Deep Learning Framework

Alluxio, Inc.

Top Mobile App Development Companies 2024

XongoLab Technologies LLP

What need to be mastered as AI-Powered Java Developers

EmilyJiang23

Recently uploaded (20)

APVP,apvp apvp High quality supplier safe spot transport, 98% purity

Facemoji Keyboard released its 2023 State of Emoji report, outlining the most...

JustNaik Solution Deck (stage bus sector)

How to pick right visual testing tool.pdf

The Impact of PLM Software on Fashion Production

5 Reasons Driving Warehouse Management Systems Demand

COMPUTER AND ITS COMPONENTS PPT.by naitik sharma Class 9th A mittal internati...

AI/ML Infra Meetup | ML explainability in Michelangelo

how-to-download-files-safely-from-the-internet.pdf

How to install and activate eGrabber JobGrabber

StrimziCon 2024 - Transition to Apache Kafka on Kubernetes with Strimzi.pdf

A Guideline to Zendesk to Re:amaze Data Migration

Secure Software Ecosystem Teqnation 2024

Tree in the Forest - Managing Details in BDD Scenarios (live2test 2024)

AI/ML Infra Meetup | Reducing Prefill for LLM Serving in RAG

INGKA DIGITAL: Linked Metadata by Design

AI/ML Infra Meetup | Improve Speed and GPU Utilization for Model Training & S...

AI/ML Infra Meetup | Perspective on Deep Learning Framework

Top Mobile App Development Companies 2024

What need to be mastered as AI-Powered Java Developers

Things You Can Learn from 101 Things I Learned in Architecture School

1. Things You Can Learn from

2. @KevlinHenney

4. “Architecture is the thoughtful making of space.” Louis Kahn

5. Design an architectural space to accommodate a specific program, experience, or intent.

6. True architectural style does not come from a conscious effort to create a particular look. It results obliquely — even accidentally — out of a holistic process.

7. Properly gaining control of the design process tends to feel like one is losing control of the design process.

8. A good designer isn't afraid to throw away a good idea.

9. “Less is more.” Ludwig Mies van der Rohe

10. “Less is a bore.” Robert Venturi

11. No design system is or should be perfect.

12. The more specific a design idea is, the greater its appeal is likely to be.

13. “Always design a thing by considering it in its next larger context.” Eliel Saarinen

14. Limitations encourage creativity.

15. Good designers are fast on their feet.

16. Manage your ego.

17. The most effective, most creative problem solvers engage in a process of meta-thinking, or “thinking about thinking.”

18. Three levels of knowing SIMPLICITY is the world view of the child or uninformed adult [...]. COMPLEXITY characterizes the ordinary adult world view. [....] INFORMED SIMPLICITY is an enlightened view of reality. It is founded upon an ability to discern or create clarifying patterns within complex mixtures. [....]

19. Create architectural richness through informed simplicity or an interaction of simples rather than through unnecessarily busy agglomerations.

20. Beauty is due more to harmonious relationships among the elements of a composition than to the elements themselves.

21. Any design decision should be justified in at least two ways.

22. Two points of view on architecture ARCHITECTURE IS AN EXERCISE IN TRUTH. A proper [system] is responsible to universal knowledge and is wholly honest in the expression of its functions and materials. ARCHITECTURE IS AN EXERCISE IN NARRATIVE. Architecture is a vehicle for the telling of stories, a canvas for relaying societal myths, a stage for the theater of everyday life.

23. Design with models!

24. Give it a name.

25. Architecture begins with an idea.

26. Just do something.

Things You Can Learn from 101 Things I Learned in Architecture School

Recommended

Recommended

More Related Content

More from Kevlin Henney

More from Kevlin Henney (20)

Recently uploaded

Recently uploaded (20)

Things You Can Learn from 101 Things I Learned in Architecture School