Design Process


begin by assuming that you know nothing about the solution


assume that you need 3 iterations before understanding the problem


assume that you need to understand the problem before you can design a production-ready solution for it


Q: what is the best data structure?

A: I don’t know, it will take 3 iterations before I do know better


Q: should I use Functions or Objects or a Declarative or a Relational Solution, etc.?

A: I don’t know, it will take 3 iterations before I do know better


write the first 2 iterations in code that you can throw away

write fast


destroy code


don’t refactor


don’t worry about DRY

There are technologies that already handle the DRY problem – CSE (see the Dragon Book)


read The Mythical Man Month

Brooks talks about 3 iterations


“second system effect” is the act of re-architecting a solution with all of the bells and whistles


3rd system effect => re-architect system using knowledge gained in 1st and 2nd systems, throwing away YAGNI stuff from 2nd system stuf


solving a software problem always involves unknowns

If you think you know the answer, you are following the Waterfall method of design


definition: you don’t know the answer to the problem


pick worst unknown, solve it first

worst unknown => problem that will cost the most to fix later, use best guesses, you can only know better after 3 iterations


next: pick the new worst unknown and solve it next


if you already know how to solve the problem, then someone has iterated the design more than once

“No-code” solutions cannot exist until the 3rd iteration


e.g. accounting systems


e.g. websites


you can design a system faster by throwing code away

don’t re-work tired old designs, throw them away


refactoring is only a band-aid that fools you into thinking that you are making progress


code is cheap, thinking is hard

use languages that encourage you not to worship code


code is worshipped when it contains design decisions (that can’t be easily separated from the code)


needed: languages that capture DI (Design Intent)


not needed: languages that encourage you to embed design decisions


not needed: languages that make code more efficient

compilers do that, humans shouldn’t be bothered with that


not needed: languages (package managers, etc.) that offer simplicity by adding complexity


Solutions 1 & 2

use systems that allow you to use any language, multiple languages, and any design paradigm


Draft solution for solution 3

use technologies that allow you to describe your DI to coder(s), e.g. whiteboards, diagram compilers, DSLs, etc.


send draft to various Engineering teams


Code solution 3 & put it into production

don’t make any design decisions during coding


coding should proceed at the rate of touch-typing


if new design decisions are recognized during coding – send them back to Engineering (don’t make design decisions during coding)


“mousing is for kids” – use languages / development environments that permit all 10 fingers to be used (coders who can’t use 10 fingers should be re-trained)


Post-release measurement

I don’t have much to say about this – see other literature


Post-release repair


goal: no failures in the field (it is possible)


Post-release feature upgrading