Julien Delhomme’s Blog

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

Part I: Robert C. Martin - Clean Code II: Craftsmanship and Ethics.

Do software developers feel comfortable with their profession? Many of us prefer to introduce themselves as architects or designers. Others expect to be Project Managers. Symptoms? Signs of a bad comprehension of our activity?

Bob Martin opened JAOO conference by introducing a track on the craft of software developer (Wednesday track).
We have to define our profession, elaborate an ethic, a corpus of tools and methods. For him, things are getting better, in particular with the advent of Agile practices.

Here are the main points of his speech:

What makes a Professional Developer?

Discipline
There is a lack of Discipline! L… Agile values are welcome!

Green Band (see on the picture above?)
A symbol of personal ethic and professional pride (I write good code with tests). Can’t remove it.
 

Short iterations to keep projects on track
Cycles to deployable solution (not necessary deployed)

Don’t wait for Definition
In particular, don’t wait for definitions from the customer.
Zeno and the paradox of motion: run after specifications of existing software.

Abstract away volatility (GUI / Business Rules)
No need to put business rules in JavaScript… J

Commission > Omission 
It’s better to do than not: experiment rather than wait for something (e.g. between team A and team B).

Decouple from others! Use mocks, stubs, simulators.
Never be blocked, always find some ways to progress.

Avoid Turgid Viscous Architectures, built by architects who try to solve everything. They create more problems than it solves.
Build simple, focus on problems. The architect must write code.

Incremental Improvement
Clean up day by day. Always check in code a little bit better that it was when checked it out.

No grand redesigns
Let time for usual work, fixing bugs…

Progressive Widening
Build by spikes from the GUI to data. Then, widen them.

Progressive Deepening
Go deep into layers progressively. Start with something that works (e.g. direct GUI to Data).

Don’t write bad code :-) You will immediately be slowed down by bad code. Go fast is go well.
Bad code progressively decline.

Write Clean Code:
What is clean code?? 10 lines. 5 minutes to understand. Read it is obvious. Code that do what you expect.

TDD: Nonsense! I’ve got a brain!
No… Test Driven Development is a fundamental activity. It forces to adopt a style to develop code that works minutes after minutes.
Test is what makes code flexible and maintainable. You can change and clean without breaking anything.

QA Should Find Nothing: don’t use QA to find your bugs!

100% code coverage: Not for managers!

Avoid Debugging: Temptation of leap into the debugger (« follow the debugger! »). Think & understand is better.

Manual test Scripts are Immoral: they are just big documents to put to sleep elephants.
Automate as much as possible and have testers to do exploratory testing.

Definition of done. Choose definition of done, only one definition (not “Done” and “Done done”J).

Test through right interface
Otherwise, it leads to things like « never change the GUI » to avoid break GUI tests. Don’t test business rules through the GUI.

Apprenticeship: teach to other developers (unfortunately being a good developer is not taught at school).
Pair Programming is also made for that.

Use Good Tools