Simple

Rich Hickey's [1] approach to developing software (or just thinking about and building tools) really chimes with me. His recent talk Simple Made Easy [2] really beautifully sums up how "easy" is a relative term, simple on the other hand is quantifiable and not necessarily "easy".

Following on from his previous talk on Hammock Driven Development [3] his approach is to solve the right problem. And, to really think about how to solve the right problem well. Being able to hold a problem in your mind is dependent on simplicity; if the problem is complex, the more thinking power it requires. Being able to keep problems encapsulated/modular allows them to be evaluated fully, simply.

This ties in with themes from previous posts [5] about reducing complexity and technical debt by keeping code small and well tended. Solving the right problem and not adding more than is necessary. To repeat a favorite quote:

"Real efficiency comes from elegant solutions, not optimized programs." Jonathan Sobel [4]

Efficiency, in this case, applies equally to the execution of the code and to the ability of the team to work with and improve it over a long period. While procedure and testing (agile, XP, CI, TDD and acceptance testing) are tools that I find helpful they do not truly assist with the act of problem solving. Complex code can be well tested and deploy flawlessly.

Hopefully these references help clarify some of the points I try to make about keeping code small, simple and disposable [5]. Problem solving is an intellectual activity, solving the right problem is key and doesn't require more code. More code requires more mental effort to understand, and in many cases it is easier to solve the next problem by building on top, and the cycle continues.

Solve the right problem and only the right problem; write less code that does more; solve problems with your brain and constantly ask "do we need this?".

Links:

  1. https://twitter.com/#!/richhickey
  2. http://www.infoq.com/presentations/Simple-Made-Easy
  3. http://blip.tv/clojure/hammock-driven-development-4475586
  4. http://www.cs.indiana.edu/~jsobel/c455-c511.updated.txt
  5. http://joelhughes.co.uk/code-life-cycle-every-line-is-technical-debt

 

Tagged productivity technical debt
Meta
​