- Posts tagged productivity
- Explore productivity on posterous
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:
- https://twitter.com/#!/richhickey
- http://www.infoq.com/presentations/Simple-Made-Easy
- http://blip.tv/clojure/hammock-driven-development-4475586
- http://www.cs.indiana.edu/~jsobel/c455-c511.updated.txt
- http://joelhughes.co.uk/code-life-cycle-every-line-is-technical-debt
In Favour of Test Driven Development
"It sounds very mechanical, but the effect is the exact opposite. What it does is free you to write. It liberates you to write."
John McPhee on having a system to write to.
"Art is freedom; and in art, as in life, there is no freedom without law."
Martin Amis on the importance of having rules and a code of conduct.
While referring to literature, these quotes resonate strongly with my feelings on writing software (JavaScript in particular) Imposing constraints on the process leads to greater clarity of thought. In writing: correct grammar, consistent style and brevity; in code: strict lint rules, clear design and, again, brevity.
Test Driven Development (TDD) is another self-imposed constraint. The following relates to a recent StackExchange Podcast, who's hosts are not enthusiastic about its supposed benefits and have evidence to back up their assertions.
"[...] a survey of all of the studies that have been done on TDD have shown that the better the study done, the weaker the signal as to its benefit."
A small concession is made that, for the majority of projects, TDD is poorly understood and executed. In which case I agree; used for its own sake or inappropriately: TDD has little value. For example, retrofitting unit tests misses the point entirely.
Used on functional, self-contained, code (JavaScript, perhapse) TDD provides constraining benefits that free the developer to solve their problem. Thinking about and exploring a solution is never a waste of effort, writing a test is a chance to frame a problem with greater clarity. Each test further tightens focus on the task. Each test is a tangible step forward, a possible break point and a starting point for the next push.
TDD has little benefit when interacting with existing APIs (DOM interactions, UI or web services). Only code, over which the developer has complete control (new, independent functions), can be discovered creatively. Otherwise the tests are simply a collection of roll-played guesses. The do not clarify the author's thoughts and intentions, instead they can easily reinforce her misconceptions.
"The fact is that everything I've written is very soon going to be absolutely nothing - and I mean nothing."
John McPhee, again, on leaving a legacy.
If it isn't providing satisfaction or feels like a drain on progress then TDD is counterproductive. In the hands of a developer who enjoys the process it becomes valuable aid.
