C++ CODING STANDARDS. 101 RULES, GUIDELINES, AND BEST PRACTICES, Herb Sutter, Andrei Alexandrescu

This book is full of great advice - even if you don't code in C++! I read it in parallel of a one-week training session in advanced C++. The training sessions contents and the books chapters matched quite precisely. It enabled me to put a name on a coding "pattern" I was unsing on my project: the Non Virtual Interface (NVI). Coupled with a design-by-contract practice (refer to Bertrand Meyer) implemented in code through assertions, this pattern can really improve your code.

What I put into practice:

+ NVI pattern.

+ Pimpl idiom.

+ RAII idiom.

I RECOMMEND THIS BOOK, EVEN IF YOU DON'T PROGRAM IN C++.

LEAN SOFTWARE DEVELOPMENT, by Mary and Tom Poppendieck

This book made me understand how many things in my company where far from being efficient!

The centralized top-down corporate organization for building software then seemed so inappropriate!

This book made me understand what "prepare the code for change" really means, though this is already said in so many books. (Maybe I'm just slow minded and need to read several books on the same subject to finally understand!).

And this book convinced me to re-install a Kanban in my team.

What I put into practice:

+ Kanban

+ Identify waste.

I RECOMMEND THIS BOOK.

PRACTICES OF A AGILE PROGRAMMER, Andy Hunt, The Pragmatic Programmers

I had to read this book, as it has both "practices" and "pragmatic" in the title.
It is a great catalog. It is designed in short chapters (~2/3 pages) which gives a real rythm to the reading.
What I put into practice:
+ I use CruiseControl to automate the one-action build of my current project;
+ I work from the list.

I RECOMMEND THIS BOOK.

AGILE SOFTWARE DEVELOPMENT, by Robert Martin

It is great to have the oo-principles explained in one same book.

We put into practice the part on dependy metrics on several applications.
What I put into practice:
+ I adaped Uncle Bob's dependy metrics tool (depend.sh) for Ada95 and plugged it in our automated build;
+ I pay attention to the oo-principles when writting and reviewing code.

REFACTORING, by Martin FOWLER

I really enjoyed the pragmatic approach to refactoring: run the tests, change the code in a little step, compile and run the tests, and so on.
The part on test-driven development is very clear and the article on the fact that the design is the code are just great.
This book is a must read!
What I put into practice:
+ I program in many little reversible steps;
+ I refactor ;o)

I RECOMMEND THIS BOOK.

EXTREME PROGRAMMING EXPLAINED, by Kent Beck

I read this book after starting to practice XP. It helped me understand how the practices worked so well together to achieve the principles.

What I put into practice:

+ I stopped trying to systematically apply all XP practices in an eXtreme way, but rather identified and applied specific practices which bring value to my business, such as continuous traceability, continuous code coverage mesure and continuous functional coverage measure.

I RECOMMEND THIS BOOK.

GESTION DE PROJET EXTREME PROGRAMMING, by Regis Medina, Eyrolles.

I discovered eXtremeProgramming with this book. It is very convincing. It made me want to practice XP. It even made me practice XP.
What I put into practice:
+ Information radiators;
+ Stand-up meetings;
+ Common workspace.

I RECOMMEND THIS BOOK.

CONCEPTION ORIENTEE OBJET, by Bertrand Meyer, Eyrolles

This book is pretty hard to read!
First, its a huge book. Too big for me to read in one go. So big reading it may seem discouraging. So I read chapters from time to time.
Second, it's complicated. Not because it isn't well written - but because the author explains the real issues of object-oriented programming.
The chapter on design-by-contract is fabulous. This is a practice which really made us improve our programming. This book is a reference.
What I put into practice:
+ My mentor made me apply design-by-contract with assertions.
+ I express design in source.
+ I autodocument the code.

I RECOMMEND THIS BOOK.

MY JOB WENT TO INDIA, by Chad FOWLER, The Pragmatic Programmers

This book is full of GREAT advice to improve your work on the short and long terms. Most of the advice isn't even restricted to IT jobs.
Reading it made me reconsider many aspects of my job. It helped me identify things I had to improve. Actually, the author even made me want to go work in Bengalore!
What I put into practice:
+ I suscribed to a programming magazine.
+ I made this blog.

I RECOMMEND THIS BOOK.

INFORMATION SHARING TOOL

Unfortunelty, we cannot use Wikis on a large scale to share information.

A top-down decision says the corporate choice is the QuickPlace, which we happen to dislikeafter giving them a try.

Therefore, we locally use lightweight Wikis, such as the one delivered with FitNesse.

BUILD TOOL

The automated build scripts are written in shell-script and Ant.

CONTINUOUS INTEGRATION TOOL

We use CruiseControl to automatically run build scripts upon detection of modifications in the repository.

TESTING TOOL

Thank God, we use free testing frameworks!
We test with Aunit when programming in Ada95 and CxxTest for C++ applications.

At home, I use JUnit for my Java developments.

ISSUE TRACKING TOOL

We track bugs and issues with ClearQuest.

ClearQuest is meant to be coupled to ClearCase, which is a nice feature as version control and issue tracking are such interlinked practices.

Unfortunetly, we use the pair uncoupled!

This is one of these cases when big corporate top-down decisions just don't help ...

Therefore, we violate the "Don't Repeat Yourself" practice as we identify issues and the impacted code in the ClearQuest. Samewise, we identify the impacted code in ClearCase using activities named as the reference of the issue to solve.

VERSION CONTROL TOOL

Our version control tool is ClearCase, with the UCM extension.

BUILD VS BUY VS DOWNWLOAD

After a long legacy of "Build it", my company is now into "Buy it".

It's a real pity, as the best tools are actually free to download thanks to great open-source pojects!

TESTS

One of the first practices applied on my current project was Test Driven Development.
Programming in Ada95, we downloaded the AUnit open-source test framework.
Team-members actually began to enjoy testing, even though is was traditionally seen as boring activity.
In our common workspace, you can often hear: "Thank god these tests exist! They just detected a regression I added while changing the code ...".

PAIRING

Lets face it: Some people just dislike pair-programming and you can't force them.

We've never managed to practice systematic pairing. Too bad, because pair-programming is so efficient.

However, we've sort of transformed it into a "on-demand pairing" practice: "Hey, I've got this tough refactoring to do. Can someone come help me through this one?".

Its good to have a teammate ;o)

SYNCHRONIZE AND DELIVER AT LEAST ONCE A DAY

Instinctively, many developpers will keep their code checked-out overnight, or for several days.

That's another situation when it is good to share a common workspace. Indeed, you nearly always have a teammember to ask you: "You look satisfied with your tests results. Have you checked in and delivered your work?"

It's good to have a teammate ;o)

TEST-FIRST

This is a very tough discipline!

Even though experiencing it clearly reveals better designs, it is very difficult to make it a practice.

TESTING

When a bug is detected, there is nearly controllable force pushing team-members to hack a quick correction.

That's when you need a common workspace with a colleague asking THE question: "Have you started by adding a test revealing the bug?".

It's good to have a teammate ;o)

SUB-CONTRACTING, OUT-SOURCING, OFF-SHORING

We have been through painful sub-contracting experiences.
Even though everybody was fully competent and willing, everyone has suffered from contracts which enforced early decisions and following plans over responding to change.

HAVE A MENTOR

This personal practice is described in My Job Went To India [ChadFowler].

Fortunetly I have a coach in my job, and I seek a lot of advice from a very talented peer.

I also consider the authors of my favorite software engineering books as mentors. I track the lessons of Kent Beck, Robert Martin, Bertrand Meyer, Martin Fowler, Mary Poppendieck, Andy Hunt ...

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.

CONTINUOUS INTEGRATION

Developpers synchronize and deliver their work at least daily.

A continuous integration system automatically builds the application upon detection of modifications.

The build dashboard and the build artifacts may be freely consulted by managers and clients.

With this practice, integration is performed just-in-time.

ONE ACTION BUILD SCRIPTS

The applications are build, tested and measured in one-action builds.

The build

• produces the application,
• tests it,
  
• generates code to requirement traceability matrices,
  
• generates requirement to acceptance test matrices,
  
• measures code coverage by tests,
• measures feature (requirement) coverage by tests,
  
• generates detailed design documentation,
  
• generates UncleBob's depency metrics,
• generates quality metrics,
• generates to-do lists,
  
• profiles the code,
• etc ...

The build gives a boolean status : success/failure.

TEST-DRIVEN DEVELOPMENT

The requirements and the code are verified by tests.
These are organized into unit-tests and acceptance tests.
The unit-tests and as many acceptance tests as possible are automated and self-checking.
We give proof of full code coverage and full feature coverage by the tests.
The tests are used to measure progress.

REVIEWS

The main development artifacts (plans, requirements, design, code, tests, traceability matrixes, etc ...) are formally reviewed in process by peers.

REQUIREMENT BASED DEVELOPMENT

The features to develop are identified as high-level requirements.

The specific business algorithms to implement are identified as low-level requirements and traced to the high-level requirements which justify their existance.

The code is traced to the requirements.

The compliance of the application to its allocated requirements is verified by tests, formally traced to the requirements they check.

ISSUE TRACKING

Issue tracking is a practice very closely coupled to version control.
Again, for certification purposes, we clearly specify our issue tracking practices.

VERSION CONTROL

The company I work for doesn't joke with version control.

The software we build must be certified before it can be officially used and the independant auditors look seriously into our version control practices.

DEVELOPMENT METHODOLOGIES

The certification norm we must comply with requires us to clearly describe our development methodology.
The company I work for has a long legacy of waterfall processes.
However, things are changing and locally we manage to apply Agile processes with interative and incremental cycles.
Still, we must give proof of compliance with our applicable certification norm.

STANDARDS

The practices we apply are identified and described in standards.

COMPANY ENVIRONMENT

I work for a big corporate company.
Its software applications must be certified by independant auditors before they are but into production.
The certification norm imposes requirements on planification, development process, quality assurance, change management, etc ...
To comply with these certification requirements, organizations often adapt a heavyweight attitude: heavyweight waterfall processes, heavyweight documentation and heavyweight expensive tools.