1. ⁘  ⁘  ⁘
  2. ⁘  ⁘  ⁘
  3. Abo, Akinori 9
  4. aesthetics 19
  5. agile 30
  6. Albers, Josef 17
  7. Alexander, Christopher 135
  8. Alexander, Scott 5
  9. Allsopp, John 4
  10. Ammer, Ralph 6
  11. Anderson, Gretchen 7
  12. anxiety 9
  13. Appleton, Maggie 5
  14. Aptekar-Cassels, Wesley 5
  15. Arango, Jorge 4
  16. architecture 110
  17. art 86
  18. Asimov, Isaac 5
  19. attention 17
  20. Auping, Michael 6
  21. Aurelius, Marcus 14
  22. Bachelard, Gaston 12
  23. Baker, Nicholson 10
  24. beauty 58
  25. Behrensmeyer, Anna K. 7
  26. Bjarnason, Baldur 8
  27. Blake, William 5
  28. blogging 22
  29. body 11
  30. Boeing, Geoff 7
  31. boredom 9
  32. Botton, Alain de 38
  33. Brand, Stewart 4
  34. Bringhurst, Robert 16
  35. Brooks, Frederick P. 22
  36. Broskoski, Charles 6
  37. brutalism 7
  38. building 16
  39. bureaucracy 12
  40. Burnham, Bo 9
  41. business 15
  42. Byron, Lord 14
  43. Cagan, Marty 8
  44. Calvino, Italo 21
  45. Camus, Albert 13
  46. care 6
  47. Carruth, Shane 15
  48. Cegłowski, Maciej 6
  49. Cervantes, Miguel de 7
  50. chance 11
  51. change 16
  52. Chiang, Ted 4
  53. childhood 6
  54. Chimero, Frank 17
  55. choice 8
  56. cities 51
  57. Clark, Robin 3
  58. Cleary, Thomas 8
  59. Cleary, J.C. 8
  60. code 20
  61. collaboration 18
  62. collections 31
  63. color 23
  64. commonplace 11
  65. communication 31
  66. community 7
  67. complexity 11
  68. connection 24
  69. constraints 25
  70. construction 9
  71. content 9
  72. Corbusier, Le 13
  73. Coyier, Chris 4
  74. craft 66
  75. creativity 59
  76. crime 9
  77. Critchlow, Tom 5
  78. critique 10
  79. Cross, Nigel 12
  80. Cross, Anita Clayburn 10
  81. css 11
  82. culture 13
  83. curiosity 11
  84. cycles 7
  85. Danielewski, Mark Z. 4
  86. darkness 28
  87. Darwin, Will 10
  88. data 8
  89. death 38
  90. Debord, Guy 6
  91. decisions 10
  92. design 131
  93. details 31
  94. Dickinson, Emily 9
  95. Dieste, Eladio 4
  96. discovery 9
  97. doors 7
  98. Dorn, Brandon 11
  99. drawing 23
  100. Drucker, Peter F. 15
  101. Duany, Andres 18
  102. Eatock, Daniel 4
  103. economics 13
  104. efficiency 7
  105. Eisenman, Peter 8
  106. Eliot, T.S. 14
  107. emotion 8
  108. ending 14
  109. engineering 11
  110. Eno, Brian 4
  111. ethics 14
  112. euphony 38
  113. Evans, Benedict 4
  114. evolution 9
  115. experience 14
  116. farming 8
  117. fashion 11
  118. features 25
  119. feedback 6
  120. flaws 10
  121. Flexner, Abraham 8
  122. food 16
  123. form 19
  124. Fowler, Martin 4
  125. Franklin, Ursula M. 30
  126. friendship 6
  127. fun 7
  128. function 31
  129. games 13
  130. gardens 26
  131. Garfield, Emily 4
  132. Garfunkel, Art 6
  133. geography 8
  134. geometry 18
  135. goals 9
  136. Gombrich, E. H. 4
  137. goodness 12
  138. Graham, Paul 37
  139. graphics 13
  140. Greene, Erick 6
  141. Hamming, Richard 45
  142. happiness 17
  143. Harford, Tim 4
  144. Harper, Thomas J. 15
  145. Hayes, Brian 28
  146. heat 7
  147. Heinrich, Bernd 7
  148. Herbert, Frank 4
  149. Heschong, Lisa 27
  150. Hesse, Herman 6
  151. history 13
  152. Hoffman, Yoel 10
  153. Hofstadter, Douglas 6
  154. home 15
  155. Hoy, Amy 4
  156. Hoyt, Ben 5
  157. html 11
  158. Hudlow, Gandalf 4
  159. humanity 16
  160. humor 6
  161. Huxley, Aldous 7
  162. hypermedia 22
  163. i 18
  164. ideas 21
  165. identity 33
  166. images 10
  167. industry 9
  168. information 42
  169. infrastructure 17
  170. innovation 15
  171. interaction 10
  172. interest 10
  173. interfaces 37
  174. intuition 8
  175. invention 10
  176. Irwin, Robert 65
  177. Isaacson, Walter 28
  178. Ishikawa, Sara 33
  179. iteration 13
  180. Ive, Jonathan 6
  181. Jackson, Steven J. 14
  182. Jacobs, Jane 54
  183. Jacobs, Alan 5
  184. Jobs, Steve 20
  185. Jones, Nick 5
  186. Kahn, Louis 4
  187. Kakuzō, Okakura 23
  188. Kaufman, Kenn 4
  189. Keith, Jeremy 6
  190. Keller, Jenny 10
  191. Keqin, Yuanwu 8
  192. Ketheswaran, Pirijan 6
  193. Kingdon, Jonathan 5
  194. Kitching, Roger 7
  195. Klein, Laura 4
  196. Kleon, Austin 13
  197. Klinkenborg, Verlyn 24
  198. Klyn, Dan 20
  199. knowledge 29
  200. Kohlstedt, Kurt 12
  201. Kramer, Karen L. 10
  202. Krishna, Golden 10
  203. Kuma, Kengo 18
  204. language 20
  205. learning 30
  206. life 59
  207. light 31
  208. loneliness 12
  209. love 26
  210. Lovell, Sophie 16
  211. Lupton, Ellen 11
  212. Luu, Dan 8
  213. Lynch, Kevin 12
  214. MacIver, David R. 8
  215. MacWright, Tom 5
  216. Magnus, Margaret 12
  217. making 77
  218. management 14
  219. Manaugh, Geoff 27
  220. Markson, David 16
  221. Mars, Roman 13
  222. material 39
  223. math 16
  224. McCarter, Robert 21
  225. meaning 33
  226. media 16
  227. melancholy 52
  228. memory 29
  229. metaphor 10
  230. metrics 19
  231. microsites 49
  232. Miller, J. Abbott 10
  233. Mills, C. Wright 9
  234. minimalism 10
  235. Miyazaki, Hayao 30
  236. Mod, Craig 15
  237. modularity 6
  238. Mollison, Bill 31
  239. morality 8
  240. Murakami, Haruki 21
  241. music 16
  242. Müller, Boris 7
  243. Naka, Toshiharu 8
  244. names 11
  245. Naskrecki, Piotr 5
  246. nature 51
  247. networks 15
  248. Neustadter, Scott 3
  249. Noessel, Christopher 7
  250. notetaking 35
  251. novelty 11
  252. objects 16
  253. order 10
  254. ornament 9
  255. Orwell, George 7
  256. Ott, Matthias 4
  257. ownership 6
  258. Pallasmaa, Juhani 41
  259. Palmer, John 8
  260. patterns 11
  261. Patton, James L. 9
  262. Pawson, John 21
  263. perception 22
  264. perfection 7
  265. performance 17
  266. Perrine, John D. 9
  267. Petroski, Henry 24
  268. philosophy 6
  269. photography 20
  270. physics 6
  271. Pinker, Steven 8
  272. place 14
  273. planning 15
  274. Plater-Zyberk, Elizabeth 18
  275. poetry 13
  276. politics 9
  277. Pollan, Michael 6
  278. practice 10
  279. problems 31
  280. process 22
  281. production 7
  282. productivity 12
  283. products 21
  284. programming 9
  285. progress 16
  286. Pye, David 42
  287. quality 26
  288. questions 8
  289. Radić, Smiljan 20
  290. Rams, Dieter 16
  291. Rao, Venkatesh 14
  292. reading 16
  293. reality 13
  294. Reichenstein, Oliver 5
  295. religion 11
  296. Rendle, Robin 12
  297. repair 28
  298. research 17
  299. Reveal, James L. 4
  300. Richards, Melanie 3
  301. Richie, Donald 10
  302. Rougeux, Nicholas 4
  303. Rowe, Peter G. 10
  304. Rupert, Dave 4
  305. Ruskin, John 5
  306. Satyal, Parimal 9
  307. Saval, Nikil 13
  308. Sayers, Dorothy 32
  309. Schaller, George B. 7
  310. Schwulst, Laurel 5
  311. science 17
  312. seeing 36
  313. Sennett, Richard 45
  314. senses 11
  315. Seuss, Dr. 14
  316. Shakespeare, William 4
  317. Shorin, Toby 8
  318. silence 9
  319. Silverstein, Murray 33
  320. Simms, Matthew 19
  321. Simon, Paul 6
  322. simplicity 14
  323. Singer, Ryan 12
  324. skill 17
  325. Sloan, Robin 5
  326. Smith, Cyril Stanley 29
  327. Smith, Justin E. H. 6
  328. Smith, Rach 4
  329. socializing 7
  330. society 23
  331. software 68
  332. solitude 12
  333. Somers, James 8
  334. Sorkin, Michael 56
  335. sound 14
  336. space 20
  337. Speck, Jeff 18
  338. spirit 10
  339. streets 10
  340. structure 13
  341. Strunk, William 15
  342. Ström, Matthew 13
  343. style 30
  344. Sun, Chuánqí 15
  345. symbols 12
  346. systems 18
  347. Sōetsu, Yanagi 34
  348. Sōseki, Natsume 8
  349. Tanaka, Tomoyuki 9
  350. Tanizaki, Jun'ichirō 15
  351. taste 10
  352. Taylor, Dorian 16
  353. teaching 21
  354. teamwork 17
  355. technology 41
  356. texture 7
  357. thinking 31
  358. Thoreau, Henry David 8
  359. time 54
  360. Tolkien, J.R.R. 6
  361. tools 32
  362. touch 8
  363. transportation 16
  364. Trombley, Nick 44
  365. truth 15
  366. Tufte, Edward 31
  367. Turrell, James 6
  368. typography 25
  369. understanding 32
  370. urbanism 68
  371. ux 100
  372. Victor, Bret 9
  373. Viollet-le-Duc, Eugène 4
  374. vision 7
  375. visualization 34
  376. Voltaire 4
  377. wabi-sabi 8
  378. walking 23
  379. Wallace, David Foster 33
  380. Wang, Shawn 6
  381. war 7
  382. waste 12
  383. Watterson, Bill 4
  384. Webb, Matt 14
  385. Webb, Marc 3
  386. Weber, Michael H. 3
  387. Wechler, Lawrence 37
  388. whimsy 11
  389. White, E.B. 15
  390. Wirth, Niklaus 6
  391. wisdom 20
  392. Wittgenstein, Ludwig 7
  393. Woolf, Virginia 11
  394. words 35
  395. work 81
  396. writing 55
  397. Wurman, Richard Saul 18
  398. www 88
  399. Yamada, Kōun 5
  400. Yamashita, Yuhki 4
  401. Yudkowsky, Eliezer 17
  402. zen 38
  403. ⁘  ⁘  ⁘
  404. About
  405. RSS Feed
  406. Source

planning

Close
  • Welcome changing requirements

    Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

    Manifesto for Agile Software Development
    1. ​​A late change in requirements is a competitive advantage​​
    • planning
  • The Thing-deadline calculus

    Now, I understand deadlines. I understand that the plane will take off whether or not I’m on it, or the importance of beating the holiday retail rush, or that "the show must go on". It is perfectly clear to me how people use timekeeping technology to coordinate social activity. It’s actually quite remarkable when you step back and look at it. But, over the years, I have observed that there is a difference between those examples and the ones around the delivery of Things, which tend to be completely arbitrary. When you wrap an arbitrarily complex endeavor up in a neat launch date, the goal seems to be more about coercing the people beneath you to absorb the overhead of all the details you left out—that or sweating it yourself. As a tool for coordinating human activity, I have come to believe that the Thing-deadline calculus is, considering more sophisticated alternatives, unnecessarily crude.

    Dorian Taylor, On the "Building" of Software and Websites
    1. ​​Deadlines are bullshit​​
    2. ​​Never enough time​​
    3. ​​Driving engineers to an arbitrary date is a value destroying mistake ​​
    • planning
    • products
  • The best-laid plans

    It is rarely possible – or even particularly fruitful – to look too far ahead. A plan can usually cover no more than 18 months and still be reasonably clear and specific. So the question is most cases should be, Where and how can I achieve results that will make a difference within the next year and a half?

    Peter F. Drucker, Managing Oneself
    • planning

    The answer must balance several things. First, the results should be hard to achieve...but also, they should be within reach. Second, the results should be meaningful. Finally, results should be visible and, if at all possible, measurable.

  • But bulldozers move mountains

    A planner may find that his beautiful plans fail because he does not follow through on them. Like so many brilliant people, he believes that ideas move mountains. But bulldozers move mountains; ideas show where the bulldozers should go to work.

    Peter F. Drucker, Managing Oneself
    • planning
    • ideas
  • Good design is redesign

    Good design is redesign. It's rare to get things right the first time. Experts expect to throw away some early work. They plan for plans to change.

    It helps to have a medium that makes change easy. When oil paint replaced tempera in the fifteenth century, it helped painters to deal with difficult subjects like the human figure because, unlike tempera, oil can be blended and overpainted.

    Paul Graham, Taste for Makers
    • mistakes
    • planning
    • agile
  • Obsessed with absolute numbers

    Modernist planning was obsessed with absolute numbers, including the minimum dimensions of rooms, open space per capita, and the one-size-fits-all head counts of neighborhood units. This was often pegged at five to seven thousand and was used as a formula for determining the distribution of schools, shops, sports fields, and other facilities. The failure of such planning is not in its effort to be comprehensive or to equalize access to necessary facilities. It is, rather, the attempt to rationalize choice on the basis of a homogeneous set of subjects, a fixed grammar of opportunities, a remorseless segregation of uses, and a scientistic faith in technical analysis and organization that simply excludes diversity, eccentricity, nonconforming beauty, and choice. The utopian nightmare.

    Michael Sorkin, 20 Minutes in Manhattan
    1. ​​Desired qualities of light​​
    2. ​​Predicted Mean Vote​​
    • planning
    • metrics
    • diversity
  • A warning against the limitations of my own prescriptions

    It is always necessary to check tactics against the specific needs that become evident in specific places. We should always be asking, “Does this device do the job needed here? And if not, what would?” Deliberate, periodic changes in tactics of subsidy would afford opportunity to meet new needs that become apparent over time, but that nobody can foresee in advance. This observation is, obliquely, a warning against the limitations of my own prescriptions in this book. I think they make sense for things as they are, which is the only place ever possible to begin. But that does not mean that they would make the best sense, or even good sense, after our cities had undergone substantial improvement and great increase in vitality.

    Jane Jacobs, The Death and Life of Great American Cities
    • planning
  • The plan must anticipate all that is needed

    Ebenezer Howard set spinning powerful and city-destroying ideas: He conceived that the way to deal with the city’s functions was to sort and sift out of the whole certain simple uses, and to arrange each of these in relative self-containment.

    And he conceived of good planning as a series of static acts; in each case the plan must anticipate all that is needed and be protected, after it is built, against any but the most minor subsequent changes.

    Jane Jacobs, The Death and Life of Great American Cities
    1. ​​Same name in the same basket​​
    • planning
    • function
  • Many a corner office

    I want you to consider instead the possibility that Waterfall came to exist, and continues to exist, for the convenience of managers: people whose methods are inherited from military and civil engineering, and who, more than anything else, need you to promise them something specific, and then deliver exactly what you promised them, when you promised you’d deliver it. There exists many a corner office whose occupant, if forced to choose, will take an absence of surprises over a substantive outcome.

    Dorian Taylor, Agile as Trauma
    • surprise
    • planning
  • Individuals matter

    An Article by Dan Luu
    danluu.com

    One of the most common mistakes I see people make when looking at data is incorrectly using an overly simplified model. A specific variant of this that has derailed the majority of work roadmaps I've looked at is treating people as interchangeable, as if it doesn't matter who is doing what, as if individuals don't matter.

    Individuals matter.

    1. ​​On Talent​​
    • teamwork
    • planning
    • work
  • Driving engineers to an arbitrary date is a value destroying mistake

    An Article by Gandalf Hudlow
    iism.org
    Image from iism.org on 2021-11-17 at 6.15.52 PM.jpeg

    What 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.

    1. ​​The Thing-deadline calculus​​
    2. ​​The value-destroying effect of arbitrary date pressure on code​​
    3. ​​Deadlines are bullshit​​
    • planning
    • agile
    • software

    "Whether it takes 2 rounds or 10 rounds of estimate squashing, most teams eventually capitulate and figure out what date is politically acceptable. They do this so they can go back to work and stop trying to predict the future with insufficient information."

  • The value-destroying effect of arbitrary date pressure on code

    An Article by Gandalf Hudlow
    iism.org
    Image from iism.org on 2021-08-10 at 9.31.59 PM.jpeg

    The mandate from above is clear, just get it done! Avoid everything that's in the way: all advice, all expertise, all discovery efforts that detract from hitting the Date™!

    What these organizations don't realize is that all software change can be modeled as three components: Value, Filler and Chaos. Chaos destroys Value and Filler is just functionality that nobody wants. When date pressure is applied to software projects, the work needed to remove Chaos is subtly placed on the chopping block. Work like error handling, clear logging, chaos & load testing and other quality work is quietly deferred in favor of hitting the Date™.

    1. ​​Driving engineers to an arbitrary date is a value destroying mistake ​​
    • agile
    • planning
    • quality
    • discovery
  • Hofstadter's Law

    An Idea by Douglas Hofstadter
    en.wikipedia.org

    It always takes longer than you expect, even when you take into account Hofstadter's Law.

    1. ​​On the "Building" of Software and Websites​​
    2. ​​Deadlines are bullshit​​
    3. ​​Parkinson's Law​​
    • recursion
    • self-reference
    • planning
    • time
  • Planning doesn't make for better software

    A Fragment by Robin Rendle
    www.robinrendle.com

    My 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.

    1. ​​Why Software is Slow and Shitty​​
    • planning
    • software
    • agile

    This article is a direct response to pketh's.

  • Yagni

    A Definition by Martin Fowler
    martinfowler.com

    Yagni 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".

    1. ​​A late change in requirements is a competitive advantage​​
    2. ​​Requirements proliferation​​
    • software
    • agile
    • features
    • planning

See also:
  1. agile
  2. software
  3. features
  4. surprise
  5. products
  6. recursion
  7. self-reference
  8. time
  9. function
  10. metrics
  11. diversity
  12. mistakes
  13. ideas
  14. quality
  15. discovery
  16. teamwork
  17. work
  1. Dorian Taylor
  2. Jane Jacobs
  3. Peter F. Drucker
  4. Gandalf Hudlow
  5. Martin Fowler
  6. Douglas Hofstadter
  7. Robin Rendle
  8. Michael Sorkin
  9. Paul Graham
  10. Dan Luu