Part II: Kevlin Henney – With Economy and Elegance
Wednesday morning, Kevlin Henney opened the track on “Professional Developer”.
He really is a pleasant speaker. After the success of this first session, his following session “Performance Art” was full.
These are the main points of his speech:
Definitions
“Our job is to turn a general purpose machine into a specific one”
A nice quote: the client: “I would like something… general. (J). Be able to… do lots of different things…” – “Ok. Take a compiler!”
It is natural for any discipline to define itself by analogy with others (metaphors), however the notion of is like is not the same as is (need for breaking the metaphor).
The mistake has not been in treating software development as a kind of engineering but…
- But in assuming that is was a form of physical engineering (it is a kind of informational engineering)
- But in assuming that engineering was synonymous with plan driven (i.e. imposition of rigid plans)
- But in assuming a caricature of other engineering disciplines to compare against and mimic
- But in assuming that there was no art, craft or sense of aesthetics in engineering
An Emerging Discipline
Problem: Software has been unreasonably successful! There was money, no time for consolidation.
But after a period of expansion and experimentation, we are in a period of consolidation…
With a stable base to build on:
- Classic topics of computer science
- Commoditized tools and libraries
- Patterns for capturing and communicating software architecture and development experience
With clearer thinking about how people work
An Emerging Professionalism
A clearer sense of responsibility
Ways to form communities (discussion groups, open source projects, conferences)
Shared Understanding?
Then, Kevlin began to talk about “Economy and Elegance”:
Economy and elegance are not arbitrary or whimsical concerns.
- Effective software development involves more than just a focus on functional and operational behavior
- Recognizing that these qualities have value is part of professionalism
Sufficiency
- Overachieving, speculative design is weaker and more complex, not stronger and simpler
- Clarity, ease of use and performance are often achieved by reducing both clutter and hedging
Essential versus Accidental Complexity
Complexity comes from many sources, not all of which are necessary:
- Sometimes the problem domain is complex, which may dictate complexity in the solution
- Sometimes it is misunderstanding or insufficient skill that creates complexity
- Sometimes it is cleverness that creates the complexity — code by über-programmers is often based on speculative generality and gratuitous use of advanced techniques and language features
Avoid Design by committee.
Decremental development
- Eliminate Waste (Lean Development),
- Don’t Repeat Yourself (Pragmatic Programming),
- Once and Once Only (Extreme Programming),
- Omit Needless Code and Unify Duplicate Code (Programmer’s Dozen)
Refactoring, encapsulation, conversation and libraries help in the search for the minimum. These are hill-descending techniques.
Refactoring is gradual, stable and Goal Oriented.
The Value of Economy
Economy represents care, far-sightedness and elimination of waste (in code & in process)
It is not a principle on its own, but a consideration with many consequent benefits
- If you want fast code, keep it clean. (”No. Very Clean!”)
- If you want extensible code, keep it clean
- If you want testable code, keep it clean
The Value of Elegance
Yes, aesthetics matters! But do not fall in love with a design because it seems particularly fine and clever.
Style is not fashion.
Elegance offers guidance in economy. It places human in the picture, encouraging comprehensibility, care and creativity.
Kevlin concluded his speech with an optimistic note: “We are moving in the right direction.” “Refactoring is mainstream!” J
