Category Archives: code

Shipping *is* a Feature

I once received a wall clock with these words : “Shipping is a feature”

I don’t remember what happened to the clock. Maybe I should have kept it around.

Sometimes remembering that you need to ship your code is enough to give you a well-needed push. Good UI, architecture, testability are all necessary… but it’s easy to push too far. Sometimes you have to go with ‘good enough’ and ship.

Code Reviews – A Positive Experience at Last

In the past I had terrible experience with code reviews. Proposed changes never got integrated. The same people were always doing the code review. Some reviews were almost useless – very little comments except for “this getter is not documented and that’s our coding standard”.

That changed recently and I now appreciate being on both sides of code reviews. Everyone participates and the reviews I received improved my code. Hopefully the reviews I gave did the same. Since we started I think the quality of our application is higher.

Having your code reviewed has great advantages:

  • It forces more rigor. Comments help to clean up and be more consistent.
  • It helps to make code clearer. If code is not understood by your peer, there’s a good chance you won’t be able to understand it in a month.
  • Reviews often simplify code. Your colleagues might have code to solve the same problem or they may know a better way.

That’s only one side of the story though. Reviewing code offers other perks:

  • It spreads knowledge and helps to break silos.
  • The reviewer sees other designs. Some of your colleague’s ideas might be worth stealing.
  • It helps to get better and faster at reading code and understanding algorithms.

Maybe it’s just me, but I believe code reviews make me achieve higher coding standards. What I would like to improve in my team is to get a shorter feedback loop. I try to commit early to get initial comments on my feature. Unfortunately everyone is busy and code review is not always the priority of the day so I often have time to finish the feature before it gets reviewed. Nobody’s perfect – I’m the first to be guilty of prioritizing the feature I’m working on over a review. I’m committed to change my priority from now on.

What should be reviewed to make your application better? Functionality. Compliance to requirements. Code. Naming conventions. Tests. Design. Clarity. Documentation. Usability. Performance. Everything that matters to your team.

Perfection lies in details. Code reviews is one way to make your app shine.

Git Part 2 – Share Code with (a few) friends

In my current project we shared code among a few team members without impacting the others using Git. Since it happened twice and I already forgot it once, I put it here as a personal reminder. Hopefully it will help you too.

Imagine you’re working on a feature and a teammate wants to use your code. But you’re not finished, your code might break the build or some other functionality is broken. You have a few choices. You can send a patch. You can accept that the build is going to be broken. Or you can use Git and create a temporary branch for the sub-team to work on.

Setting up

Let’s say you need to work on a new feature. First you create your branch:
git checkout -b myfeautre

The feature takes longer than expected. And you need help. But your changes will break the application and you don’t want to impact every one. So you push your branch back to origin:
git push origin myfeature

Get work done (with some help)

Those who want to help you can create their own local branch.
git fetch
git branch myfeature origin/myfeature

I suggest you delete your own local branch and create another one as above. Your new branch will be linked to origin/myfeature so push/pull will work as usual. If you know another way to do this without deleting your branch, please tell me.

To sent your changes back to origin/myfeature, simply do

git push origin myfeature

Now everyone involved in the feature can commit as they wish.

Cleaning up

When you’re ready to merge back to master:
git checkout master
git merge myfeature

Then delete your old branches once everything is working:
git branch -d myfeature # deletes your local branch
git push origin :myfeature # deletes the remote branch

If you push using git push, it will push every thing from every branches, including master. Make sure all your branches are in a stable state when pushing. Otherwise you can push a single branch:
git push origin myfeature

I you feel I missed anything, don’t hesitate to tell me.

No Code

Less code is good. Actually the best code is code that is never written.

Code is going to be read by someone else. Less code makes everything easier to understand.

And the what a feeling you get from cleaning code!

Every line of code that can be removed brings a grin
Every method that can be deleted makes me smile.
Every object that can be eradicated makes me laugh.

Act like there is no tomorrow.

Obliterate code.


I once worked on a project that had some tests but the architecture was… let’s say it could be better. There were many files with over a thousand lines of code many classes had too many responsibilities I did not have enough fingers to count them all.

I think I failed to be as effective as I could in this environment for one reason. A very simple reason.

“Coding in the right mindset you did not” said my master. And the master gave me a bunch of dead trees which people commonly refer to as ‘a book’.

Reading Working Effectively with Legacy Code by Micheal Feathers triggered a few thoughts. The book just led me to think differently about legacy code.

And what I found out the hard way is that I should have realized that I was working with legacy code.

Simple isn’t it?

Then I would not have minded putting methods public to be able to test them. At least it allows me to test my code without too many changes.
Then I would not cared if the class I was working on had thousands of lines of code – I would just make sure the bit of code I was modifying was tested.
Then I would not have tried to refactor too much code. Small steps are the key.

I plead guilty. I was trying to hard to remove the design flaws. This slowed me down when I had to add features.

Learn from my mistakes. When working on legacy code, change your mindset. Forget about great and extensible design – or at least don’t make it your priority. You have a job to do. Do it effectively. It might not be glamorous but in the end, you’ll get the features out a bit faster while still improving the test coverage.

Essential Bookshelf – Pragmatic Programmers

I read lots of books. Lately I’ve been evangelizing the virtues of two of the books that had a deeply impacted me lately. This is the review for one of them.

The first book I want to talk about is Pragmatic Programmer, from Journeyman to Master by Andy Hunt and Dave Thomas. I read this book in 2001, after I worked for a year or so, and it totally changed the way I think about software.

There were lots of great advice under the form of catch phrase (DRY – Don’t Repeat Yourself, No Broken Window, the Law of Demeter…). The authors even wrote about usage of metaprogramming and compilers in (almost) everyday software. But that’s not what influenced me to become a better programmer.

What inspired me was that the authors have a deep passion for programming and it shows. They talked about investing in yourself as you would in an investment portfolio. “Learn a programming language every year”. “Learn your tools”. “Care about your craft”.

I first heard the expression “rubberducking” in this book as well – if you can’t find a human to talk to, talk to the duck.

However programming goes beyond coding. The code is important, but so is knowing your tools, the command shell, deploying an application in a real environment, build files and build automation. Programming is a social activity, you need to show your code to peers to get feedback and improve, you need to talk to your customer to know his requirements. You need to care, improve, learn!

That made me realize that the knowledge I have today is already obsolete – I needed to be aware of where the future might be heading, which technologies might come out on top in a few years. I started to read more books and blogs. I went to local user group meetings. I started a few pet projects in a few languages. And I realized that I would probably be programming even if it wasn’t my day job – I was just lucky to get paid for it.

If you haven’t read this book yet, it’s a must for every programmer who is passionate about his craft.