OPEN-UP! READ SOFTWARE ENGINEERING BOOKS AND BROWSE THE WEB

Lets avoid re-implementing the wheel!

Books and the web contain so much available and useful information.

At first, reading books on my job was a self-imposed discipline. Now, I has become a real pleasure.

THE LIST

As decribed by "Work From The List" in Ship It! [Richardson/Gwaltney], I prioritize and track my to-do activities in a list.
However my list doesn't contain the features and issues assigned to me on the project Kanban board (Don't Repeat Yourself!).

DESIGN BY CONTRACT

According to Bertrand MEYER's design by contract practice (implemented into Eiffel), we specify class responsibilities in terms of pre-conditions and post-conditions.

These conditions are evaluated in assertions.

Class invariants are also checked by assertions.

Combined with a test-driven practice, this is a great way to implement the stop-the-line culture. Furthermore, it a great way to build mistake-proof code, as a class instance may not be used without respecting its operations pre-conditions.

SHARED DESIGN

Design decisions are always taken as a team.

At least two developpers gather in front of a whiteboard and start working on a short term design.
At least one of the designer is then assigned the design to code and test.
If the design-decision is important, it is logged and justified into the design description document.

INFORMATIVE WORKSPACE

Whiteboards and large post-its show the design the team is currently working on.

Prioritized features and issues are described on post-its. They are moved along the sequential sections of a large Kanban board.

The sections are named TO-DO, ASSIGNED-TO, TO-REVIEW, TO-DELIVER and DONE.

The Kanban reprensents the team's workflow.

COMMON WORKSPACE

The software developpers share a common workspace to enhance informal communication, pairing and team-spirit.

HIGH QUALITY

Simplicity, clarity, no-duplication and design-patterns are enforced during pair-programming sessions, peer-reviews and continuous refactoring.