Taken from Rich Hickey's day 2 keynote at Clojure Conj 2010.
The notes below were copied from [David's McNeil's notes] (http://david-mcneil.com/post/1398718149/clojure-conj-day-2-notes "David McNeil's Blog") and modified by me.
When was the last time you thought hard about a problem for an hour, day, month, year?
When have you confidently sat down to implement something for the first time?
The point he made by the end of the talk was something like: if you will think hard and well about a problem and write down what you learn then you will position yourself to confidently implement a solution on your first attempt
We commonly talk about the cheapest place to fix bugs is at development time. But, it is cheaper to fix bugs at design time. This idea has become unfashionable since Agile but it's clear that the biggest problems in software are ones of misconception. In other words, if the developer has wrong ideas about the problem or the solution, it is unlikely that good software will be created.
Automated testing is a useful tool in implementation and maintenance but it cannot provide a direct answer for the question of “whether this is a good idea?”
This is not about a return to waterfall, and it's not not about UML or a specific process, not waterfall. It's a recognition that when we create any non-trivial system we still need to do Analysis and Design before we “go do it!”.
- identify and state the problem (verbally or in written form)
- critically assess proposed solutions
- We should be solving problems, not adding features.
- Will the features solve a problem?
- Or will the features create a problem?
- Avoiding a problem is not the same as solving a problem.
Problem solving is a skill which can be learned and practiced.
See "How to Solve It" by George Polya.
Is it better to be good at problem solving or methodology X?
Understand the problem:
-
facts, context, constraints (known and unknown), questions to find unknown unknowns, related problems
-
understand previous attempts to solve the problem
-
goal is to work incrementally ahead of the best known solution to the problem
-
write this down
-
Be discerning:
-
are there problems in your solution? If so, solve these.
-
identify tradeoffs.
- Often stated tradeoffs just identify deficiencies in a solution.
- To properly understand tradeoffs it is necessary to have at least two alternative solutions in hand
-
write this down
- the computer is a distraction
- balls will be dropped while you are focusing deeply on a problem. This is part of the process.
- feed your background mind by thinking a lot about the problem with the waking mind. This will establish an agenda for the background mind to work.
- since the mind can only focus on ~7 items at a time, write down the aspects of a problem.
- This will allow you to quickly swap some of the items in and out of your mind.
- Maybe use pictures for this (not prescribing UML).
- Go over this repeatedly so you internalize it and can think about it long and hard.
- closing your eyes and removing other sensory inputs facilitates thinking well
It is not always practical to wait so you should pipeline.
- Get several problems going at once.
- Switch tasks when you are stuck.
- try it
- code it
This should involve little as little typing as possible since you have thought about it enough this should be confident coding. Feedback (e.g. from test results) is important but don’t lean on it
