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 | --ditto-- | goal: no failures in the field (it is possible) | |
Post-release feature upgrading | --ditto-- | ||