Software & Digital Products
A late change in requirements is a competitive advantage
Make the change easy
Software often feels inevitable
Growing in the correct way
It begins with craft
So insufficiently palimpsestic
Spatial software references
- Nototo
A great painting has to be better than it has to be
This sounds like a paradox, but a great painting has to be better than it has to be. For example, when Leonardo painted the portrait of Ginevra de Benci in the National Gallery, he put a juniper bush behind her head. In it he carefully painted each individual leaf. Many painters might have thought, this is just something to put in the background to frame her head. No one will look that closely at it.
Not Leonardo. How hard he worked on part of a painting didn't depend at all on how closely he expected anyone to look at it. He was like Michael Jordan. Relentless.
Relentlessness wins because, in the aggregate, unseen details become visible. When people walk by the portrait of Ginevra de Benci, their attention is often immediately arrested by it, even before they look at the label and notice that it says Leonardo da Vinci. All those unseen details combine to produce something that's just stunning, like a thousand barely audible voices all singing in tune.
Great software, likewise, requires a fanatical devotion to beauty. If you look inside good software, you find that parts no one is ever supposed to see are beautiful too.
That which requires caring
Today's real world of technology is characterized by the dominance of prescriptive technologies.
The temptation to design more or less everything according to prescriptive and broken-up technologies is so strong that it is even applied to those tasks that should be conducted in a holistic way. Any tasks that require caring, whether for people or nature, any tasks that require immediate feedback and adjustment, are best done holistically. Such tasks cannot be planed, coordinated, and controlled the way prescriptive tasks must be.
Prescriptive technologies eliminate the occasions for decision-making and judgment in general and especially for the making of principled decisions. Any goal of the technology is incorporated a priori in the design and is not negotiable.
Jacked in
In digital design, products and services are frequently imagined and implemented placelessly: as if the consumer were jacked into The Matrix, and considering this product or that product from among an infinite set of choices at an infinitely-provisioned mercantile. The things we make are good, by this way of reasoning, if they fit the market’s demand.
Losing meaning
The people who’ve proven that they can make very good individual products with the radical focus of a spotlight seem to be pushed ever further from making good ecosystems.
Products are being made “consistent” with the application of so-called “design patterns,” and rather than bringing coherence to these various touch-points, the painting-on of interface standards and interaction patterns did something far less valuable.
Rote consistency, in the way many seem to be going about it (Material Design being just one example), is at odds with making things be good. It simplifies what needs to remain complex.
Always, when simplification is underway, meaning is being lost.
Penn Station
In the same way that physical architecture can affect a mind, so too can software. Slower, less reliable software is like Penn Station: Sure, you can catch a transfer from one train to another but the dreary lowness of the place, the lack of sunlight or sensible wayfinding will make you feel like a rat, truculent and worthless, and worse: You’ll acclimate to that feeling and accept it as a norm.
The Design of Design
A Book by Frederick P. Brooks, Jr.Visualizing Algorithms
An Article by Mike BostockManifesto for Agile Software Development
A DefinitionWe are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Stop Drawing Dead Fish
A Talk by Bret VictorThe Future of Programming
A Talk by Bret VictorDesign Links & Learning
A Blog by Nick TrombleyCollections of articles, links, and other material from around the web, relevant to software design and engineering.
Ensuring Excellence
An Article by Marty Cagan…in so many of the best product companies there is an additional dimension that goes beyond individual empowered product teams, and even goes beyond achieving business results.
It has to do with ensuring a level of what I’ll refer to here as “excellence” although that is clearly a very ambiguous term.
Over the years, this concept has been referred to by many different names, always necessarily vague, but all striving to convey the same thing: “desirability,” “aha moments,” “wow factor,” “magic experiences,” or “customer delight,” to list just a few.
The concept is that an effective product that achieves results is critical, but sometimes we want to go even beyond that, to provide something special.
Maybe it’s because we believe this is needed to achieve the necessary value. Maybe it’s because the company has built its brand on inspiring customers.
Often this dimension shows up most clearly in product design, where functional, usable but uninspiring designs can often achieve our business results, but great design can propel us into this realm of the inspiring.
On online collaboration and our obligations as makers of software
An Essay by Baldur BjarnasonIs it the notetaking system that’s helping you think more clearly? Or is it the act of writing that forces you to clarify your thoughts?
Is it the complex interlinked web of notes that helps you get new ideas? Or is it all the reading you’re doing to fill that notetaking app bucket?
Is all of this notetaking work making you smarter? Or is it just indirectly forcing you into deliberate, goalless practice?
In Search of Organic Software
An Article by Pirijan KetheswaranTwo different kinds of farms can grow vegetables. One is a factory farm built for scale, and the other takes the time to grow more expensive but healthier plants without pesticides.
Will everyone appreciate the difference? Of course not, but the latter plants are labelled ‘organic’ to give us the information and the choice, so that those of us who do care can make better decisions.
So maybe we should have ‘organic’ software as well, made by companies that:
- Are not funded in such a way where the primary obligation of the company is to 🎡 chase funding rounds or get acquired (so bootstrapping, crowdfunding, grants, and angel investment are okay)
- Have a clear pricing page
- Disclose their sources of funding and sources of revenue
Reflections on Software Performance
An Article by Nelson Elhage- Performance is a feature
- Performance changes how users use software
- Performance needs effort throughout a project’s lifecycle
- Architecture strongly impacts performance
- Performance isn’t just about hot spots
- Performant foundations simplify architecture
…we underrate performance when designing and building software. We have become accustomed to casually giving up factors of two or ten or more with our choices of tools and libraries, without asking if the benefits are worth it.
Undoing the Toxic Dogmatism of Digital Design
An Essay by Lisa Angela- Design educators and industry leaders have never reached a consensus about what comprises a “good enough” foundational education for digital design.
- We do not properly retire methods (or ways of conducting them) that have been shown to be ineffective.
- Design team seniority levels are meaningless.
- We’ve collectively lost the safety (and subsequently the desire) to explore and fail.
- We afford well-known design leaders too much power to dictate how design is discussed and conducted.
- We have no ethical standards.
- Inclusive design and accessibility are afterthoughts — both in design education and in practice.
The things that you’re meant to do
A Quote by Josh WardleI used to work in Silicon Valley, and I’m aware of the things that, especially with games, you’re meant to do with people’s attention. You’re trying to capture as much of people’s attention as you can. So that involves things like endless play, or sending them push notifications, or asking them for sign-up information.
And philosophically, I enjoy doing the opposite of all those things, doing all the things that you are not meant to do, which I think has bizarrely had this effect where the game feels really human and just enjoyable. And that really resonates with where we’re at right now in the world and with COVID, and then also we’re trying to figure out, what is tech? What has tech become? I think that really resonates with people, and no ads—well, no monetization. People ask me a lot about these things, and it was like, I was literally just making a game for my partner, and I made some decisions that we would like.
I don’t believe in Zoom fatigue
An Article by Matt WebbIt’s not Zoom fatigue, it’s Zoom whiplash.
It’s a hunch. I can’t prove this.
The trick to get around this is to move smoothly up and down the gradient of social interaction intensity, never dropping below a basic floor of presence: the sense that there are other people in the same place as you.
Instead of having two modes, “in a call” and “on my own,” we need to think about multiple ways of being together which, minimally, could be:
- In a video call
- In an anteroom to a video call, hearing the sound of others
- In a doc together
- On my desktop but with the sense that colleagues are around
And the job of the designer is to ensure that their software ensures the existence of these different contexts, instead of having the binary on-a-call/not-on-a-call, and to design the transitions between them.
Spatial Software
An Article by John PalmerScales of cities, scales of software
An Article by Linus the SephistAmerican cities seem like a product of industrial processes where older European cities seem like a product of human processes. This is because most American cities were built after and alongside the car and the industrial revolution – the design of cities took into account what was easily possible, and that guided the shape and scale of everything.
Software has similar analogues. There are software codebases that feel much more industrially generated than hand written, and they’re usually written in automation-rich environments fitting into frameworks and other orchestrating code.
…But despite the availability of cars, I still much prefer the scale and ambiance of European, human-scale cities, because ultimately cities are places humans must inhabit and understand. In the same way, I still much prefer the scale and ambiance of hand-written codebases even in the presence of heavy programming tooling, because ultimately codebases are places humans must inhabit.
Driving engineers to an arbitrary date is a value destroying mistake
An Article by Gandalf HudlowWhat happens when you apply date pressure to software engineers working on high value software projects? The engineers will focus on delivering Something™ by the Date™! This fatal flaw results in delivery of a Something™ full of chaos and features that nobody really wants or needs.
How can we develop transformative tools for thought?
A Research Paper by Andy Matuschak & Michael NielsenConventional tech industry product practice will not produce deep enough subject matter insights to create transformative tools for thought.
...The aspiration is for any team serious about making transformative tools for thought. It’s to create a culture that combines the best parts of modern product practice with the best parts of the (very different) modern research culture. You need the insight-through-making loop to operate, whereby deep, original insights about the subject feed back to change and improve the system, and changes to the system result in deep, original insights about the subject.
Software Engineering as a Craft
An Article by Thomas WilsonThe decreasingly tangible product of code, i.e. that all we have are files on a hard-drive, may make it easy to forget that writing software produces a thing. If you produce a wonky chair or an overly long fork, it’s easy to see the quality of work was not great. By calling for a perception of software as a craft, we fight against that ability to forget or not notice the final quality of the product. You could watch two software engineers with different levels of experience, or in different domains, and it wouldn’t necessarily be so easy to guess which is which, at least from a distance.
So maybe there is something to be said for the value of software as a craft, for sometimes focusing on the practice of making better, or at least different, software just for the sake of it.
Why Scrum is killing your product
An Article by Henry LathamDeadlines are bullshit
An ArticleIn software development deadlines are a necessary evil. It is important to understand when they are necessary, and it is important to understand why they are evil.
- External vs. internal deadlines
- Why are internal deadlines evil?
- Engineers who love their work
Software developers have stopped caring about reliability
An Article by Drew DeVaultOf all the principles of software engineering which has fallen by the wayside in the modern “move fast and break things” mentality of assholes modern software developers, reliability is perhaps the most neglected, along with its cousin, robustness. Almost all software that users encounter in
$CURRENTYEAR
is straight-up broken, and often badly.The Rise Of User-Hostile Software
An Essay by Den DelimarskyWe are truly living in an era of user-hostile software, and when I say “user-hostile” I mean it as “software that doesn’t really care about the needs of the user but rather about the needs of the developer.”
I personally do not know anyone who asked for an online account requirement before they can use a keyboard; however, some product lead somewhere decided that it’s important to better “understand the customer” and “maximize marketing reach” through some weekly “Hey, we have a new keyboard!” newsletter.
Minimum Awesome Product
An Article by Carlos BeneytoUsers are accustomed to a minimum of quality, and they expect that of all new products.
If our product does not [meet basic expectations of quality], people will automatically believe that it is a bad product and they will not take it seriously. It is not what they expect.
Hence my suggestion that the MVP has died and the MAP: Minimum Awesome Product was born.
Traditional companies are losing because they mismanage software engineers
An Article by Emma WattersonInnovation is messy, and frankly Anti-Steve [Jobs] can’t figure out why you wouldn’t just tell people the right thing to build and skip all the trial and error that comes with innovation. Anti-Steve and his board of directors that keep him in place fundamentally believe that they know what needs to be built. Or at least that they can hire the messiah that will come down off the mountain and tell everyone what to build. There is no such messiah.
Research, empathy, simplicity, speed
An Article by Matthew StrömAs Nosrat provides a simple list of essential ingredients for any great meal, can we describe a simple list of essential components for digital products?
Here are four elements that I believe are the foundation of great digital products: Research, Empathy, Simplicity and Speed.
Craft and Material in Digital Design
An ArticleProduct Design Resources
A Reference Work by Brandon DornThings I‘ve read, people I‘ve tried to learn from, and things I‘ve done to become a better designer. This is an idiosyncratic list reflecting what has helped me along the way, rather than an exhaustive list of design classics.
Though the list leans toward theory — principles are more durable than technique — I offer a few ideas further down about how to practice design. It also leans toward information design, because the task of presenting rich, dense information in an accessible way is ultimately the task of any digital product.
Functional Prototyping. A Missed Opportunity in Web Design
An Essay by Chuánqí SunPrototyping allows engineers in various industries to “fail fast, fail cheap”, “select the best from the pool”, and “bring in the reality”.
Apps Getting Worse
An Article by Tim BrayToo often, a popular consumer app unexpectedly gets worse: Some combination of harder to use, missing features, and slower. At a time in history where software is significantly eating the world, this is nonsensical. It’s also damaging to the lives of the people who depend on these products.
...Maybe we ought to start promoting PMs who are willing to stand pat for an occasional release or three. Maybe we ought to fire all the consumer-product PMs. Maybe we ought to start including realistic customer-retraining-cost estimates in our product planning process.
We need to stop breaking the software people use. Everyone deserves better.
Feature parity
An ArticleWhilst Feature Parity often sounds like a reasonable proposition, we have learnt the hard way that people greatly underestimate the effort required, and thus misjudge the choice between this and the other alternatives. For example even just defining the 'as is' scope can be a huge effort, especially for legacy systems that have become core to the business.
Most legacy systems have 'bloated' over time, with many features unused by users (50% according to a 2014 Standish Group report) as new features have been added without the old ones being removed. Workarounds for past bugs and limitations have become 'must have' requirements for current business processes, with the way users work defined as much by the limitations of legacy as anything else. Rebuilding these features is not only waste it also represents a missed opportunity to build what is actually needed today. These systems were often defined 10 or 20 years ago within the constraints of previous generations of technology, it very rarely makes sense to replicate them 'as is'.
The return of fancy tools
An Article by Tom MacWrightTechnology is seeing a little return to complexity. Dreamweaver gave way to hand-coding websites, which is now leading into Webflow, which is a lot like Dreamweaver. Evernote give way to minimal Markdown notes, which are now becoming Notion, Coda, or Craft. Visual Studio was “disrupted” by Sublime Text and TextMate, which are now getting replaced by Visual Studio Code. JIRA was replaced by GitHub issues, which is getting outmoded by Linear. The pendulum swings back and forth, which isn’t a bad thing
On Design Engineering: I think I might be a design engineer...
An Article by Trys MudfordDesign engineering is the name for the discipline that finesses the overlap between design and engineering to speed delivery and idea validation. From prototyping to production-ready code, this function fast-tracks design decisions, mitigates risk, and establishes UI code quality. The design engineer’s work encapsulates the systems, workflows, and technology that empower designers and engineers to collaborate most effectively to optimise product development and innovation.
— Natalya ShelburneWebsites are not living rooms and other lessons for information architecture
An Essay by Sarah R. BarrettWhile there is a lot that IA can learn from actual architecture or city planning, websites aren’t buildings or cities, and they don’t have to work like them. Instead, they should be designed according to the same principles that people’s brains expect from physical experiences.
Software that nobody wants
An Article by Gandalf HudlowFinding value is the result of enabling individual and group-level discovery attempts. It's not the result of everyone following one leader's gut.
What just happened is a new software product/feature was created that no customer wanted. This happens way too often. In fact, most hyper important software projects that must be done by date certain or else, have deep flaws that cause some variation of this phenomenon, flaws that include:
- Not wanted - Company specified a solution to a problem that customers don't actually have
- No Rarity - Company is pursuing an iKnockoff of existing products. The market already has two scaled competitors with working solutions, customers naturally spend budget on products that are already successful to avoid risk
- Incorrect Packaging - Customers need a website, but the company created an iOS app instead
- Incorrect Pricing - Customers need SaaS pricing, but the company created a shrink wrapped, on-premise solution with CapEx and maintenance agreements instead
Guidebook: Graphical User Interface Gallery
A WebsiteGuidebook is a website dedicated to preserving and showcasing Graphical User Interfaces, as well as various materials related to them.
A Mindful Mobile OS
An Article by Clo S.I read and loved Potential's "iOS 15, Humane" proposition. Published earlier in June by co-founders Welf and Oliver, it tackles how iOS could help us better protect our attention.
As a designer who cares about and writes about digital wellness, I'm profoundly aligned with their suggestions.
- Persuasive design
- Disclosure requirement
- From infinite feeds to pages
- Was this time well spent?
- Regret tax
- Conditions of use
Clues for software design in how we sketch maps of cities
An Article by Matt WebbGiven there’s an explosion in software to accrete and organise knowledge, is the page model really the best approach?
Perhaps the building blocks shouldn’t be pages or blocks, but
neighbourhoods
roads
rooms and doors
landmarks.Or rather, as a knowledge base or wiki develops, it should - just like a real city - encourage its users to gravitate towards these different fundamental elements. A page that starts to function a little bit like a road should transform into a slick navigation element, available on all its linked pages. A page which is functioning like a landmark should start being visible from two hops away.
Fast Software, the Best Software
An Essay by Craig ModI love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness.
Software that’s speedy usually means it’s focused. Like a good tool, it often means that it’s simple, but that’s not necessarily true. Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book — makes you smile without necessarily knowing why.
A Plea for Lean Software
An Essay by Niklaus WirthSoftware's girth has surpassed its functionality, largely because hardware advances make this possible. The way to streamline software lies in disciplined methodologies and a return to the essentials.
Speed is a feature
An Article by Nikita ProkopovMillions of programs have that unfulfilled potential of becoming your second nature, something you don’t even think about when interacting with. They’re waiting to be enabled to “click”. Speed is a feature.
The Great Divide
An Article by Chris CoyierOn one side, an army of developers whose interests, responsibilities, and skill sets are heavily revolved around JavaScript.
On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.
The care and feeding of software engineers (or, why engineers are grumpy)
An Article by Nicholas ZakasWe do say “no” very quickly, not just to designs, but to everything. That led me into thinking about the psychology of software engineers and what makes us the way we are.
Web Brutalism, seamfulness, and notion
An Essay by Brandon DornHow a tool for sensemaking reconciles two distinct software design ideologies.
- Seamful vs. seamless
- Reveling in infrastructure
- The brilliance of notion
- How our understanding is working
Dear Microsoft
An EssayWe realized a few years ago that the value of switching to Slack was so obvious and the advantages so overwhelming that every business would be using Slack, or “something just like it,” within the decade. It’s validating to see you’ve come around to the same way of thinking. And even though — being honest here — it’s a little scary, we know it will bring a better future forward faster.
However, all this is harder than it looks. So, as you set out to build “something just like it,” we want to give you some friendly advice.
How Microsoft crushed Slack
An Article...and why the era of worker-centered work tools may be over.
Technical debt as a lack of understanding
An Article by Dave Rupert"If you develop a program for a long period of time by only adding features but never reorganizing it to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer.” — Ward Cunningham
People expect technology to suck because it actually sucks
An Article by Nikita ProkopovI decided to record every broken interaction I had during one day.
If I decided to invest time into thinning this list down, I could theoretically...reduce this list from 27 down to 24. At least 24 annoyances per day I have to live with. That’s the world WE ALL are living in now. Welcome.
Why Software is Slow and Shitty
An Article by Pirijan KetheswaranPlanning doesn't make for better software
A Fragment by Robin RendleMy own time in a Silicon Valley startup has proved this much to be true; planning doesn’t make for better software. In fact today our design systems team doesn’t have sprints, we don’t have tickets or a daily standup. Each day we come to work, figure out what’s the most important thing that we could be doing, and then we—gasp!—actually do it.
Watching so many other teams slowly flail about whilst they plan for quarter 3.2 of subplan A, whilst our team produces more work in a week than they all do combined in a quarter has been shocking to me.
After four years of working in a large startup, I know what I always assumed was true: you don’t need a plan to make a beautiful thing. You really don’t. In fact, there’s a point where overplanning can be a signal of inexperience and fear and bullshit. The scrum board and the sprints and the inane meetings each and every day are not how you build another Super Mario 64.
Instead all you have to do is hire smart people, trust them to do their best work, and then get the hell out of their way.
Figma's Engineering Values: Craftsmanship
An ArticleCraftsmanship is about thoughtfulness and care in the work we do. It means being deliberate about what we build and how possible it will be to maintain and extend in the future. A solution that will require revisiting in a month — because it’s not scaling, because it has a ton of bugs, because it doesn’t support all the use cases it needs to — is not useful to us and ultimately will generate pain for our users.
What we trade off by living this value is (sometimes) day-to-day speed. It’s easy to imagine an engineering team that emphasizes moving fast over keeping things stable and bug-free -- like a team building a product that isn’t responsible for important user data and doesn’t support anyone’s livelihood. But given the role the Figma product plays in the lives of our users, we feel it’s worth it to ensure we hold a high quality bar for them. And in the long run, being thoughtful about how we build often reduces the complexity of ongoing development and new features regardless.
On the "Building" of Software and Websites
An Essay by Dorian TaylorI’m beginning to suspect that software, and more conspicuously the Web, is fundamentally the wrong shape for the archetype of the construction project.
Yagni
A Definition by Martin FowlerYagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from Extreme Programming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".
The State of Agile Software in 2018
A Talk by Martin FowlerOn the surface, the world of agile software development is bright, since it is now mainstream. But the reality is troubling, because much of what is done is faux-agile, disregarding agile's values and principles. The three main challenges we should focus on are: fighting the Agile Industrial Complex and its habit of imposing process upon teams, raising the importance of technical excellence, and organizing our teams around products (rather than projects).
Product vs. Feature Teams
An Article by Marty CaganThis article is certain to upset many people.
Silicon Valley Product Group
A Website by Marty CaganThe best companies go about building great products differently. Silicon Valley Product Group (SVPG) was created to share lessons learned and best practices about how to build innovative products customers love
Like, just a post complaining that screens should be better
An Article by Matt WebbIt’s been 19 years since Pixar released Monsters, Inc. with all that CGI hair. Where are my hairy icons? Ones that get all long and knotted as the notifications number goes up.
Why can’t I feel my phone? I found that paper from 2010 (when I was complaining about keyboards) about using precision electrostatics to make artificial textures on touchscreens.
I should be able to run my thumb over my phone while it’s in my pocket and feel bumps for apps that want my attention. Touching an active element should feel rough. A scrollbar should *slip. Imagine the accessibility gains. But honestly I don’t even care if it’s useful: 1.5 billion smartphone screens are manufactured every year. For that number, I expect bells. I expect whistles.
The Battle for the Life and Beauty of the Earth
- Two generating systems
- Two types of building production
- System A
- System B
- This has harmed modern society greatly
Two generating systems
Imagine a town of type "A" — a neighborhood, if you like, and allow yourself to consider that it has the quality of birds, moss-grown stones, waves breaking on a small shore, pools in which crabs and shells present themselves. Because of the depth and scope of its structure, this world is almost infinite in its richness.
Compare this imagined town with a more usual neighborhood of type "B", typical of modern property development, where there is a stale and ugly air of repetition. Even when variation is attempted, this variation does not flow from the reality of living. Rather it is manufactured variety — an attempt to create something interesting. But what we feel instead is something flat, without excitement, without the urgent joy of life.
These two kinds of places, then, A and B, are typically generated in two different ways. We may therefore call these two different generating systems A and B.
Two types of building production
There are, loosely speaking, two types of building production. Type A is a type of production which relies on feedback and correction, so that every step allows the elements to be perfected while they are being made. This is not unlike the way a good cook tastes a soup while cooking it, checking it, modifying it, until it tastes just right. Type B is a type of production that is organized by a fixed system of rigidly prefabricated elements, and the sequence of assembly is much more rigidly preprogrammed. This type became commonplace in the 20th century, and is still widely used.
System A
System A is concerned with the well-being of the land, its integrity, the well-being of the people and plants and animals who inhabit the land. This has very much to do with the integral nature of plants, animals, and water resources, and with the tailoring of each part of every part to its immediate context, with the result that the larger wholes, also, become harmonious and integral in their nature.
System B
System B is concerned with efficiency, with money, with power and control. Although these qualities are less attractive, and less noble than the concerns of System A, they are nevertheless important. They cannot be ignored. If we are traveling in an airplane, or a high-speed train, we shall often be very glad that this system is constructed under the guidance of some version of system B.
This has harmed modern society greatly
System A places emphasis on subtleties, finesse, on the structure of adaptation that makes each tiny part fit into the larger context. System B places emphasis on more gross aspects of size, speed, profit, efficiency, and numerical productivity.
However, during the last hundred and fifty years, because of choices that nations and states have made in modern times, System B has become the dominant production system for the environment (for land and towns and regions), largely to the exclusion of System A. This has harmed modern society greatly.
Arcade
Here is an interior street on the Eishin campus, with an arcade opening from the back of the classroom buildings. The arcade steps up as the street goes along the slope. Because the natural contours of the land are preserved, the arcade jumps up, in small increments, as it goes along. Steps are inserted where needed; and in plan, too, the arcade follows a gentle series of curves and bends, following the natural character of the land.
This aspect of a street is not usually present in large construction projects, which typically destroy the natural character of the land, and tend to start with a blank "page" that has been created by perfect grading and flattening.
Transmitted through drawings
Architecture is now only transmitted through drawings. The typical architect does not personally know how to make anything — not buildings, not windows, not floors or ceilings. He or she draws drawings. Some other organization then produces buildings from these drawings. We are, by now, so deeply enmeshed in this way of thinking, that it doesn't sound like idiocy.
The life-giving continuum
In System A, creation and production are organic in character, and are governed by human judgments that emanate from the underlying wholeness of situations, conditions, and surroundings.
In System B, the production process is thought of as mechanical. What matters are regulations, procedures, categories, money, efficiency, and profit: all the machinery designed to make society run smoothly, as if society was working as a great machine. The production process is rarely context-sensitive. Wholeness is left out.
Identifying these two categories helps us sharpen and clarify the range of differences among ways of creating the environment that exist in different societies. And the two categories serve to identify a dimension of great importance: the dimension that runs from more life-giving to less life-giving.
Blueprints
Blueprints lead to the making of things that are abstract, not always based on reality. Once something becomes abstract, it breeds disconnectedness — separation and the inability to connect with our surroundings. People buy houses from blueprints, but then don't like the actual house: "What on earth is this? I had no idea it was going to be like this...etc."
Hopes and dreams
The very first thing we did was spend two weeks just talking to different teachers and students, to get a feeling for their hopes and dreams. These talks were one-on-one and often lasted about an hour, for any one interview, during which we asked questions, talked, probed, explored dreams of an ideal campus, and tried to understand each person's deepest visions as a teacher, or as a student. We asked people about their longings, and their practical needs. We asked them to close their eyes and imagine themselves walking about in the most wonderful campus they could imagine.
Mixed use
Pattern 5.5 – Every sports field is always attached to some building which has nothing to do with the particular sports function. Thus, for instance, the tennis courts may be next to the art studio, and placed so that people entering the art studio are just at that place where the tennis court is most enjoyable to watch.
Secret garden
Pattern 7.7 – There is also one garden, so secret, that it does not appear on any map. The importance of the pattern is that it must never be publicly announced, and must not be in site plan. Except for a few, nobody should be able to find it.
In the mind's eye
In System A, it is always the wholeness of the place that matters. To intensify the wholeness of any place — whether it consists of existing buildings in a town, or of virgin land that is largely unbuilt — proposed construction and buildings must be decided, and that means "felt" and thought through on the site itself. It is really not possible to do it any other way, since the relationships which exist between the buildings and the world around them are complex and subtle.
On a drawing or a plan, one simply does not see enough. The drawn plan does not give enough information. So trying to make decisions by drawing on a plan is doomed to failure. To produce a plan that has reality, and to bring the actual place itself to life, decisions are made gradually, on the site itself, under circumstances where one visualizes the situation as the whole it really is. Step by step, this brings building positions to life in the mind's eye — and so, in imagination, one conceives the buildings literally, in their full size and volume as they are really going to be.
Simulacra and simulation
The situation of contemporary construction is more likely to be that a building still gets its character first as an image, drawn on paper, by an architect's fantasy, a simulacrum which is then physically built in cheap and flimsy studs and sheetrock, concrete panels, cardboard — or in whatever conventional system of construction the contractor has on hand.
Sadly, this is where the dull, lifeless, and stereotyped character of buildings in the 20th century mainly came from. It is also, at the same time, where the wild and fantastic egotistical shapes of the present era come from. They are conceived and carried out as images, or part-images, not as built, solid, made works. These papery, System B things are not conceived and made for the sake of their material reality. The feeling one gets in the presence of these buildings does not fill the onlooker with the beauty or the presence of the material substance.
Power law
Buildings which most profoundly communicate subtle harmony are composed of a complex mixture of materials, with the overall amounts of different materials jumping in a calibrated cascade — typically according to a power law. The relative proportions — the statistical distribution of materials by quantity of total visible area — is critical. It is this specific distribution, not just the mixture, which creates depth of feeling.
Elements of Eishin
Each of the elements in the following list were essential to the creation of every space and every building at Eishin:
- The way each building relates to its surroundings, as well as the ground on which it stands.
- The geometry directed by its position in the whole and its function.
- Working with people who will inhabit the spaces.
- The immensely detailed use of models and experiments.
- The search for beautiful materials and ways of making the buildings that should stand there.
- The careful use of money in a manner that reflects the values of the endeavor.
- Creation of positive space, at every turn, and every scale.
- Placing materials between other nearby materials that are similar, and wedging harmonious materials in-between.
- Interlocking spatial links forming a two-dimensional sheet of courtyards, buildings, and openings.
Our responsibility
As makers of buildings, we architects must start now,
with a fundamental change of direction.
For the last hundred years or so, we have understood
building to be an art in which an architect draws a building,
and a contractor then builds that building from the
architect's plans.
But a living environment cannot be built
successfully this way.To achieve a successful building — one that has life — we
must focus our attention on all the crafts and processes,
and then, as architects, ourselves take direct charge
of the making.
We must take full responsibility
for the entire building process, ourselves.
Unfolding
In short, the architect is responsible for building construction, is watching the building unfold continuously, and is making ongoing modifications as it becomes clear from each given stage, what modifications and changes should be made at each moment. And this is all to be done within a management framework that controls budget and cost very tightly.
Direct management
Direct Management does not include or permit the concept of profit to occur. The management is fee-based, or based as a fixed salary, and all construction costs are fixed ahead of time, and the building design is modified during construction, to make up any over-runs. The manager is not able to move money around at will, or put it in their pocket. At the same time, the design is approximately fixed, but with the understanding that it may be changed, during the evolution of the building, so that subtle adaptations can be included in the emerging building. In the Direct Management method it is the architect themselves and the direct manager who together manage the building works and all on-site construction for the owner.
The problem of schedule
We have emphasized, from the beginning, that in order to achieve really profound quality in this project, it is necessary to be able to modify it continuously, during the process of construction. This in turn requires that the Manager is alive to the fact that important decisions are being faced at every stage, and is aware that one of the most important things that is happening, is the evolution of the building designs, while they are being built.
We have a strong intuition that a general contractor will interfere with this process, no matter what is said in advance. The reason is this: All the large general contractors we have interviewed are strongly oriented to the problem of schedule. Of course, this is one of their strengths. However, we are convinced that they are so strongly oriented to this problem, that they will ultimately kill the life of the project, in order to achieve enough management control to be able to guarantee schedule.
We must get our hands dirty!
We must get our hands dirty!In every work of architecture, the construction details are the heart of the project, and the true makers of the project are the ones who make the details, who make the materials directly, and who are not afraid to get dirt
under their fingernails.
We feel it in our fingers
In System A, there is no architect separate from the contractor. We are builders, simply. As builders, we have a direct feeling about construction. We feel it in our fingers, so it is down to earth. One result of this down-to-earth quality is that everything is somewhat experimental. We make experiments all the time. Sometimes we place a piece of wood this way. Another time, we may like to try it that way. Any time something new comes up in the design of a building, we are very likely to try and invent the best way of building it. This is not a great big invention. Just a simple invention, the way we might invent a way of tying a piece of string, to hold a broken toy together. It is just practical.
Four principles
The essential purpose of Direct Management, as we understand the term, is to create buildings which are whole. This means that each part of the building is right in relation to the other parts, and to the part of the land that makes the buildings and the land more beautiful.
I will try to summarize the real meaning of Direct Management.
- The design evolves during construction. This means that the form of control over designs does not stop when drawings are finished, but goes on, continuously, before, during, and after construction. This cannot be done if architect and contractor are separate, or consider their jobs separately. It will only happen if the person who controls the design at the beginning actually controls the construction, too.
- Flexible cost control. Cost control requires continuous changing of ideas about what is built, in relation to money that is available, and in relation to what has been done already.
- Experience with one's hands. It is also impossible for an architect to have enough knowledge to control the process successfully, unless they have experienced almost every phase of construction with their own hands.
- Love of craft and the joy in the physical process of making. In the old days, making a building was clearly understood as a work of making. In this word, designing and physically building are inseparable. However, in the modern world, design has become separated from construction. Architects think of their work as designing, on paper, with the idea that the building process is a separate process. This is not what I call making at all. A good building can only be created, when it is deeply understood as something which is made, by a direct connection of the act of making, and the act of feeling, with your hands.
Guided by image
In our minds, the drawings we had originally made for the columns and capitals were no more than first approximations of the final shapes. We assumed that we would work out the real shapes during construction, and left the inaccurate approximations on our drawings, just for the sake of the building permit. Fujita, used to working with architects in System B, assumed that whatever was on our drawings must be what we wanted, and must be implemented as drawn.
Anybody who was making those column capitals, if they had seen this "double" capital, and had been free to make something harmonious, would have done it differently. But Fujita's people, in System B, did not know how to be guided by reality. They were guided by "image".
So Fujita, in this situation, was not free to respond in a natural way to what they saw. They were trapped by the image-making process they were used to. But because of this, they doomed their own carpenters to a pretentious kind of slavery, producing whatever silly images they were told to do, without being able to ask themselves whether they were beautiful, and unable to use their own sense of reality to make them better.
Invisible substance
We wanted wood, not only in many visible places, but also in the roof trusses of the homeroom buildings, where they are invisible. Fujita wanted to replace the invisible trusses with steel trusses. They could not understand the idea that it was the actual substance — even though not visible — which would control the feeling of the thing.
A practical and sacred act
The emotional energy of a building can be achieved, only if the artists who make and shape the building are genuinely responsible for the way the building gets its shape. To put this another way around, it means that if we fail to take the practical responsibility for the acts of shaping, the emotional energy of the building will almost certainly be false. If the emotional quality of the building is to be alive, and is to be seen, understood, and felt by the people who live there or work there, then this task must not be handed on to someone else. The life and magnificence of the buildings will come to fruition only if we architects, or master builders, or artists — or for that matter, lay people — any of us — take on the task of shaping as a practical and sacred act.
In the walls and mosses
If we reach such a very ordinary state of daily life, and then back it up with building and construction that comes from the depths in us, then that gradually accumulates our value in the world, all of us together as a whole. Later, then, perhaps hundreds of years later, people will look back at our stones and say to themselves, "My word, those people way back then — they certainly knew how to live," and they would say this because they could see the lingering whispers in the walls and mosses, and could read them, and could treasure them, and would learn from these traces how to live like that again.
Melt
In many late 20th century buildings, the architect focused attention on a few strongly defined elements. Usually, the way the building stood out in its surroundings was very sharp, and intentionally separated from the buildings that surround it.
Real architecture comes about in a different way. If the architecture is real, there will be thousands of living centers; many of them modest, all of them having direct impact on human beings. In this condition, there is an overall wholeness in the building and the zones nearby, but this quality is not aggressive nor too sharp. It rather creates a condition where the building melts into the town, or street, or garden where it is placed.
Umbrella
From the curator's visit to a place that captures all the beauty, depth, and wholeness it attempts.