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
- ââApps Getting Worseââ
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.
- ââSteve Jobsââ
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.
- ââDear Microsoftââ
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.
- ââA Brief Rantââ
Steve Jobs: The Lost Interview
- ââOn Valueââ
- ââOn Businessââ
- ââOn Programmingââ
- ââOn Successââ
- ââOn Processââ
On Value
It was clear that [Hewlett-Packard] recognized that its true value was in its employees.
On Business
How do you learn to run a company at 21 with no business experience?
Throughout the years in business I found something, which is, Iâd always ask why you do things, and the answers you invariably get are âoh thatâs just the way itâs done.â Nobody knows why they do what they do, nobody thinks about things very deeply in business. Thatâs what I found.
Iâll give you an example. When we were building our Apple Is in the garage we knew exactly what they cost. When we got into a factory in the Apple II days, accounting had this notion of a âstandard cost.â Where youâd kind of set a standard cost and then at the end of the quarter youâd adjust it with a variance. And I kept asking, âwhy do we do this?â And the answer was just âwell thatâs the way itâs done.â And after about 6 months of digging into this what I realized was the reason you do it is because you donât really have good enough controls to know how much it costs, so you guess, and then you fix your guess at the end of the quarter. And the reason you donât know how much it costs is because your information systems arenât good enough.
But nobody said it that way. And so later on when we designed this automated factory for Macintosh we were able to get rid of a lot of these antiquated concepts, and know exactly what something costs, to the cent. And so in business a lot of things are what I would call âfolklore.â Theyâre done that way because they were done that way yesterday. And so if youâre willing to ask a lot of questions about things and work hard you can learn business pretty fast. Itâs not the hardest thing in the world. Itâs not rocket science.
On Programming
I think everyone in this country should learn a computer language because it teaches you how to think. Itâs like going to law school â I donât think anyone should be a lawyer, but going to law school could be useful because it teaches you how to think in a certain way. So I view computer science as a liberal art.
On Success
The technology crashed and burned at Xerox.
What happens is, like with John Sculley, John came from PepsiCo, and they at most would change their product maybe once every ten years. To them a new product was like a new size bottle. So if you were a product person you couldnât change the course of that company very much. So who influenced the success of PepsiCo? The sales and marketing people. Therefore they were the ones that got promoted and they were the ones that ran the company.
Well, for PepsiCo that might have been ok, but it turns out the same thing can happen in technology companies that get monopolies, like IBM and Xerox.
If you were a product person at IBM, or Xerox, so you make a better copier or a better computer? So what? When you have a monopoly market share, the company isnât any more successful. So the people that can make the company more successful are sales and marketing people, and they end up running the companies. And the product people end up getting driven out of the decision marking forums. And the companies forget what it means to make great products. The product sensibilities and the product genius that brought them to that monopolistic position gets rotted out by people running these companies who have no conception of a good product vs. a bad product. They have no conception of the craftsmanship thatâs required to take a good idea and turn it into a good product. And they really have no feeling in their hearts, usually, about wanting to really help the customers.
So thatâs what happened at Xerox.
On Process
People get confused, companies get confused. When they start getting bigger, they want to replicate their initial success, and a lot of them think that somehow thereâs some magic in the process that theyâve created. And so they start to institutionalize process across the company. And before very long people get very confused that the process is the content.
In my career Iâve found that the best people are the ones who really understand the content. And theyâre a pain in the butt to manage. But you put up with it because theyâre so great at the content. And thatâs what makes great products. Itâs not process, itâs content.
On Greatness
Whatâs important to you in the development of a product?
One of the things that really hurt Apple was that after I left John Sculley got a very serious disease. And that disease â Iâve seen other people get it too â itâs the disease of thinking that a really great idea is 90% of the work, and if you just tell all these other people âhereâs this great idea,â then of course they can just go off and make it happen.
The problem with that is that thereâs just a tremendous amount of craftsmanship in between a great idea and a great product. And as you evolve that great idea it changes and grows. It never comes out like it starts, because you learn a lot more as you get into the subtleties of it, and you also find there are tremendous tradeoffs you have to make, there are just certain things you canât make electrons do, there are certain things you canât make plastic, or glass, or factories, or robots do. And as you get into all these things, you find that designing a product is keeping 5,000 things in your brain, these concepts, and just fitting them all together and continuing to push to fit them together in new and different ways to get what you want. And every day you discover a new problem or a new opportunity to do it a little differently. And itâs that process that is the magic.
On Teamwork
What Iâve always felt that a team of people doing something they really believe in is like, is like when I was a young kid, there was a widowed man that lived up the street. He was in his 80âs, and a little scary looking, and I got to know him a little bit â I think he paid me to cut his lawn or something â and one day he told me, âcome into my garage, I want to show you something.â
And he pulled out this dusty old rock tumbler. It was a motor and a coffee can and a band between them. And he said âcome out here with me,â so we went out to the back and we got some rocks, just some regular old ugly rocks and we put them in the can with a little bit of liquid and a little bit of grit powder, and he turned the motor on and said âcome back tomorrow,â as the tumbler was turning and making a racket.
So I came back the next day and what we took out were these amazingly beautiful and polished rocks. The same common stones that had gone in â through rubbing against each other, creating a little bit of friction, creating a little bit of noise â had come out as these beautiful polished rocks.
And thatâs always been my metaphor for a team working really hard on something theyâre passionate about. Itâs that through the team, through that group of incredibly talented people bumping up against each other, having arguments, having fights sometimes, making some noise, and working together, they polish each other, and they polish their ideas. And what comes out are these really beautiful stones.
On Criticism
People are being counted on to do specific pieces of the puzzle. And the most important thing I think you can do for somebody whoâs really good and whoâs really being counted on is to point out to them when their work isnât good enough, and to do it very clearly, and to articulate why, and to get them back on track. And you need to do that in a way that does not call into question your confidence in their abilities, but leaves not much room for interpretation.
On Help
Microsoftâs orbit was made possible by a Saturn V booster called IBM.
On Taste
The only problem with Microsoft is they just have no taste. They have absolutely no taste, and what that means is â and I donât mean that in a small way, I mean that in a big way â in the sense that they donât think of original ideas, and they donât bring much culture into their product. And you say âwell why is that important?â Well, you know, proportionally spaced fonts come from typesetting and beautiful books, so thatâs where one gets the idea. And if it werenât for the Mac they would never have that in their products.
And so I guess I am saddened, not by Microsoft's success â I have no problem with their success. They have earned their success â I have a problem with the fact that they just make really third-rate products. Their products have no spirit to them, no spirit of enlightenment about them. They are very pedestrian. And the sad part is that most customers donât have that spirit either. But the way that weâre going to ratchet up our species is to take the best and to spread it around to everybody so that everybody grows up with better things, and starts to understand the subtlety of these better things. And Microsoft is McDonaldâs.
So thatâs what saddens me â not that Microsoft has won, but that Microsoftâs products donât display more insight and more creativity.
On Technology
As we look back 10 years from now, the web is going to be the defining technology, the defining social moment for our generation.
I think itâs going to be huge.
On Tools
I read an article when I was very young in Scientific America. It measured the efficiency of locomotion for various species on the planet â you know, for bears and chimpanzees and raccoons and birds and fish â how many kilocalories per kilometer did they spend to move? And humans were measured too. And the condor won, it was the most efficient. And mankind, the crown of creation, came in with rather an unimpressive showing about a third of the way down the list.
But somebody there had the brilliance to test a human riding a bicycle, and it blew away the condor, all the way off the charts. And I remember this really had an impact on me, I remember thinking that humans are tool builders, and we build tools that can dramatically amplify our innate human abilities.
And to me â we actually ran an ad like this, very early at Apple â the personal computer is the bicycle of the mind. And I believe that with every bone in my body, that of all the inventions of humans, the computer is going to rank near if not at the top as history unfolds and we look back. It is the most awesome tool that we have ever invented, and I feel incredibly lucky to be at exactly the right place in Silicon Valley, at exactly the right time where this invention has taken form.
On Theft
How do we know whatâs the right direction [for computers to take]?
Ultimately it comes down to taste. It comes down to trying to expose yourself to the best things that humans have done, and then trying to bring those things in to what youâre doing.
Picasso had a saying: âGood artists copy, great artists steal.â And we (at Apple) have always been shameless about stealing great ideas. And I think part of what made Macintosh great was that the people working on it were musicians and poets and artists and zoologists and historians who also happened to have been the best computer scientists in the world. But if it hasnât been for computer science, these people would all be doing amazing things in life in other fields. And they brought with them â we all brought to this effort â a very liberal arts air, a very liberal arts attitude, that we wanted to pull in the best we saw in these other fields into ours.
On Expression
There was a germ of something there. And itâs the same thing that causes people to want to be poets instead of bankers. I think thatâs a wonderful thing, and I think that same spirit can be put into products, and those products can be manufactured and given to people and they can sense that spirit. If you talk to people that use the Macintosh, they love it. I mean you donât hear people loving products very often. But you could feel it, there was something really wonderful there.
So I donât think that most of the really best people that Iâve worked with have worked with computers for the sake of working with computers. They work with computers because they are the medium that is best capable of transmitting some feeling that you have that you want to share with other people. And before they invented these things, all these people would have done other things. But computers were invented, and they did come along, and all these people did get interested in them, either in school or before school, and said âHey, this is the medium that I think I can say something in."
On Talent
I observed something fairly early on at Apple, which I didnât know how to explain then, but Iâve thought a lot about it since. Most things in life have a dynamic range in which [the ratio of] âaverageâ to âbestâ is at most 2:1.
For example, if you go to New York City and get an average taxi cab driver, versus the best taxi cab driver, youâll probably get to your destination with the best taxi driver 30% faster. And an automobile; whatâs the difference between the average car and the best? Maybe 20%? The best CD player versus the average CD player? Maybe 20%? So 2:1 is a big dynamic range for most things in life.
Now, in software, and it used to be the case in hardware, the difference between the average software developer and the best is 50:1; maybe even 100:1. Very few things in life are like this, but what I was lucky enough to spend my life doing, which is software, is like this.
So Iâve built a lot of my success on finding these truly gifted people, and not settling for âBâ and âCâ players, but really going for the âAâ players. And I found something⌠I found that when you get enough âAâ players together, when you go through the incredible work to find these âAâ players, they really like working with each other. Because most have never had the chance to do that before. And they donât work with âBâ and âCâ players, so itâs self-policing. They only want to hire âAâ players. So you build these pockets of âAâ players and it just propagates.