The bmannconsulting.com website
bmann.ca
1---
2link: https://gist.github.com/adamwiggins/5687294
3author:
4 - Adam Wiggins
5tags:
6 - heroku
7 - startup
8 - devtools
9 - article
10published: 2013-05-31
11---
12[[Adam Wiggins]] [[Heroku]] Values:
13
14## Make it real
15
16Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
17
18## Ship it
19
20Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
21
22## Do it with style
23
24Just because we're building bad-ass infrastructure and tools doesn't mean it can't be cool, stylish, and fun. Aesthetic matters. See [The Substance of Style](http://books.google.com/books?id=MqdydvbWZgEC)
25
26Slick and fun meets powerful and serious.
27
28Before Heroku (and a few others, like Github and Atlassian), developer-facing products were almost always stodgy, ugly, and completely lacking in style or fun.
29
30We're part of the [consumerization of IT](http://www.infoworld.com/t/consumerization-of-it/consumerization-of-it-190132).
31
32## Intuition-driven balances data-driven
33
34Hunches guide you to places to create new value in the product. Users don't really know what they want. Creating products people loves requires treating product development as an art, not a science; but products have to solve real user problems. Understanding impact of product changes to existing product is best done by mining the data. When you have a mature product and many users you have lots of data on how they are using it. Use that data to make evidence-based decisions.
35
36See: [Inspired: Created Products People Love](http://books.google.com/books?id=nE7NMQAACAA)
37
38## Divide and conquer
39
40Big, hard problems become easy if you cut them into small pieces. How do you eat the elephant? One bite at a time. If a problems seems hard, think about how you can cut it into two smaller, easier problems. If one of those problems is still too hard, cut it in half again.
41
42Wiggins' Law: If it's hard, cut scope.
43
44## Timing matters
45
46If you're building something and just can't seem to get it right, maybe now isn't the right time. You learned something in the attempt, set it down for a while. Maybe in a few weeks or a few months you (or someone else) will pick it up again and find that the world has changed in a way that makes it the right time to build the thing.
47
48## Throw things away
49
50It's not the code that is valuable, it's the understanding you've gained from building it. See [James' startup school talk](http://www.youtube.com/watch?v=3BhDLm9jo5Y).
51
52Never be afraid to throw something away and do it again, it will almost always be faster to build and much better the second (or third, or Nth) time around.
53
54## Machete design
55
56Create a single, general-purpose tool which is simple to understand but can be applied to many problems. It's like the product version of occam's razor.
57
58The value of a product is the number of problems it can solve divided by the amount of complexity the user needs to keep in their head to use it. Consider an iPhone vs a standard TV remove: an iPhone touchscreen can be used for countless different functions, but there's very little to remember about how it works (tap, drag, swipe, pinch). With a TV remote you have to remember what every button does; the more things you can use the remote for, the more buttons it has. We want to create iPhones, not TV remotes.
59
60## Small sharp tools
61
62Composability. Simple tools which do one thing well and can be composed with other tools to create a nearly infinite number of results. For example, the unix methodology (stdin/stdout and pipes), see [The Art of Unix Programming](http://books.google.com/books?id=H4q1t-jAcBIC). Heroku examples include the add-ons API, logging/logplex, and procfile/the process model.
63
64Small is beautiful. This isn't just tools, it's also teams. Several small, autonomous, focused teams working in concert almost always beat a single monolithic team.
65
66## Put it in the cloud
67
68I don't want to run software, ever. Given a choice between a great app that runs locally and a mediocre app that runs in the cloud, i'll always take the latter. (e.g. excel vs google spreadsheet, 1password vs lastpass, Things vs a textfile todo list on Dropbox) Services, not software.
69
70## Results, not politics
71
72You "get ahead" in your heroku career by delivering real value to customers and to the company, not by impressing your boss or with big talk.
73
74## Decision-making via ownership, not consensus or authority
75
76Every product, feature, software component, web page, business deal, blog post, and so on should have a single owner. Many people may collaborate on it, but the owner is "the buck stops here" and makes the final call on what happens with the owned thing.
77
78The owner can and should collect feedback from others, but feedback is just that: input that the owner might or might not choose to incorporate into their work. If something doesn't have an owner, no one should be working on it or trying to make decisions about it. Before those things can happen, it has to be owned.
79
80Ownership can't be given, only taken. Ownership can't be declared, only demonstrated. Ownership begins with whoever creates the thing first. Later the owner may hand it off to someone else. If an item gets dropped for some reason (for example, the current owner switching teams or leaving the company), it's fair game for anyone else to pick up.
81
82Apple's term for an owner is ["directly responsible individual," or DRI](http://www.quora.com/Apple-Inc-2/How-well-does-Apples-Directly-Responsible-Individual-DRI-model-work-in-practice).
83
84## Do-ocracy / intrapreneurship
85
86Ask forgiveness, not permission.
87
88- [Do-ocracy](https://adam.herokuapp.com/past/2009/7/28/doocracy/)
89- [Intrapreneur](https://adam.herokuapp.com/past/2008/8/10/intrapreneur/)
90
91## Everything is an experiment
92
93Anything we do -- a product, a feature, a standing meeting, an email campaign -- is always subject to change. That includes discontinuing or shutting down whatever the thing is. Ending an experiment isn't a failure, since we often learn the most from experiments that don't produce the results we wanted.
94
95## Own up to failure
96
97Did you make a mistake by posting to the blog at the wrong time? By failing to document the feature before you shipped it? By screwing up a customer's app? By not respecting someone's ownership, or hurting someone's feelings?
98
99Own it. Admit your mistake, say you're sorry (when applicable), and feel the failure to make sure you learned from it. Then, get back to work.
100
101## Gradual rollouts
102
103Ease into everything. Use feature flags to activate people slowly into changes, then let it bake for a bit. Test out the message for a public launch by first sending it around internally, and later writing the private beta announcement. Collect feedback and adjust. By the time you're ready to take it public to a wide audience, you'll be fairly certain to have worked out all the kinks.
104
105See: [Crossing the Chasm](http://books.google.com/books?id=yJXHUDSaJgsC)
106
107## Design everything
108
109Be intentional.
110
111See:
112
113- [Less is More](http://books.google.com/books?id=TL1aywAACAAJ)
114- [The Design of Everyday Things](http://books.google.com/books?id=w8pM72p_dpoC)
115
116## Do less
117
118Do we really need that feature? Can we delete that code? Do we really need that command? Can we outsource to or partner with another company so that we don't have the build and maintain something?
119
120See: [Ephemeralization](https://adam.herokuapp.com/past/2011/4/7/ephemeralization/)
121
122## Question everything
123
124The status quo is never good enough.
125
126See:
127
128- [The Innovator's Dilema](http://books.google.com/books?id=SIexi_qgq2gC)
129- [Blue Ocean Strategy](http://books.google.com/books?id=BmPPAjGaDuQC)
130
131## Interfaces matter
132
133Everything has an interface. A platform has an API. A computer has a keyboard, a mouse, and a GUI operating system.
134
135Teams have interfaces too. How do you file a bug or make a request? Where and when does the team collaborate with any other team?
136
137The two critical components of a good interface are that it be narrow and well-defined.
138
139For example, the add-ons API is extremely narrow. Add-on providers only need implement two calls: [one to provision a resource, and one to consume it](https://addons.heroku.com/provider/resources/technical/how/overview).
140
141The add-ons API is also well-defined, with [an API spec](https://addons.heroku.com/provider/resources/technical/reference/index) and the kensa tool which runs a live test to verify the correctness of your implementation.
142
143A poor interface is one that is wide and poorly-defined. For example, the way that apps interact with the operating system in traditional server-based hosting is poor. The number of ways the app can interact with the operating system -- system calls, libc, the entire filesystem, executing binaries in subshells -- is essentially infinite and impossible to specify.
144
145See: [Explicit Contracts](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/)
146
147## Names matter
148
149Think careful about how something is named. Pick exactly one name for each concept the user needs to track, and use it consistently. For example, add-on providers are always called providers, never "vendor" or "partner" or anything else. Writing a glossary can be a good way to design the vocabulary around something.
150
151## Maniacal focus on simplicity
152
153There is no step 1.
154
155## CLI 4 LIFE
156
157Web UIs are great for many things, but command-line interfaces are the heart of developer workflows.
158
159## Ignore the competition (except to borrow good ideas)
160
161[Tim O'Reilly said it best.](https://adam.herokuapp.com/past/2009/1/30/oreilly_wisdom/)
162
163## Write well
164
165Good writing is a powerful tool for communication. Clear writing is clear thinking.
166
167See:
168
169- [The Elements of Style](http://books.google.com/books?id=sj5_wr6zIEcC)
170- [On Writing Well](http://books.google.com/books?id=tPkZ3WU1BM8C)
171- [The Book on Writing](http://www.goodreads.com/review/show/239524186)
172
173## Strong opinions, weakly held
174
175Have a strong opinion and argue passionately for it. But when you encounter new information, be willing to change your mind.
176
177See: [Strong Opinions, Weakly Held](http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinions.html)
178
179## Candor
180
181Be blunt, honest, and truthful. Constructive criticism is the best kind. Avoid keeping quiet with your criticism about someone or something for the sake of politeness. Don't say something about someone to a third party that you wouldn't say to their face.
182
183See: [Winning](http://books.google.com/books?id=g7PG7vwBNYoC)
184
185## Programming literacy for all
186
187Software is eating the world. Everyone can and should be able to write software in order to have a stake in the future.
188
189See: [End-user computing](https://medium.com/the-truant-haruspex/5367171478b7)
190
191
192