My first couple of months at Codurance

Some background

Five Characteristics of a Great Company CultureSome of you may know me from the various meetups in the city, especially my attendance at a number of LJC and LSCC meetup events. Attending these events I learnt about various conferences like Devoxx, SoCraTes, JAX LondonJava2Days, OpenFest, and I ended up attending and later presenting on various topic including Adopt OpenJDK.

During this time I met a lot of people with various levels of experience and my interest and urge to learn more about the Java/JVM platform, Code Quality, Software Design, XP Practices, Software Craftsmanship, etc…, were on the rise and saw no end. And whilst attending these events I came across Sandro and Mash, who were in those days hosting LSCC events. I went to many of LSCC events, especially liked the hands-on sessions (which are still my favourite).

I also noticed that many things I learnt at such events and conferences wouldn’t always be immediately recognised or accepted at the workplace. And moving to another work environment didn’t always solve this problem fully. I found that I wasn’t learning what I wanted from my peers and the things I learnt from the community I couldn’t apply at work. Besides very few were really in tuned with what the community was about. So one fine day I decided to take charge of my career and make a serious decision and take up the Apprenticeship program offered by Codurance and go through the process.

I was urged to go this way after being inspired by Sandro’s book: The Software Craftsman, attending all the SoCraTes UK conferences, and meeting with developers who valued and took pride of their work namely their craft.

I was urged to go this way after being inspired by Sandro’s book: The Software Craftsman, attending all the SoCraTes UK conferences, and meeting with developers who valued and took pride of their work namely their craft.

Where we are just now

It’s now been nearly two months since I have been working for Codurance, a formidable force. And so it’s also about time that I share my experiences with my fellow mates and the community around me.

During my first few weeks at Codurance, I have been busy learning various things that have been chalked out for becoming a craftsman.

When working on a kata or learning a concept, we paired or did what is known as ‘mob programming’ along with other apprentices and craftsmen. And most of the time used the pomodoro technique. Time boxing our work in intervals is something done both in groups and working individually. We would have a lot of discussions and retrospectives after working on a problem or writing some code from scratch.

Structure of my program

We used an internal tool based on the concept of Impact Mapping. I soon got interested in it when I saw my colleague Franzi (who is now a craftswoman) had used it to plan out her Apprenticeship route. Such a tool helps map out our goals and the tasks we need to perform to achieve it. And this can differ from person-to-person, depending on what they want to work on (driven by the Apprentice).

My mentor and other craftsmen reviewed them to get an idea of what I wanted to achieve for myself. And then its up to me to apply my own drive and perseverance to achieve the individual stories. My mentor and I meet and talk informally on a regular basis, many times pairing on a kata or a project or on the white board trying to get my head around a concept.

Days in the life of an Apprentice

I found the working hours quite flexible, remote working is also an option (when you are on the bench or if the client allows, if you are in a project). Our co-founders are understanding and compassionate about our individual situations.

Meetings are at their minimum, except for a weekly Apprentices meeting (run by an Apprentice and guided by at least one Craftsperson) and a bi-monthly company-wide catchup.

The Apprentices meetings are full of fun — we are accompanied by at least one Craftsperson, who disperses their knowledge and experience from a wide variety of topics designed to help us in the journey and fill the gaps in our knowledge and experience.

A bi-monthly catchup involves sharing of knowledge via lightning talks, discussions and pairing sessions on pet projects over pizzas and beer (and of course veggies and non-alcoholic beverages for the teetotalers).

Katas, code reviews, mob programming and projects make up a learning week – all of these done individually or when pairing with another.


On a daily basis I have worked on different katas or try to solve the same kata in various different ways (using different testing and refactoring approaches). This in turn gave me better insights into designing and refactoring techniques. Trying to solve the same problem in different ways has a positive impact on our problem solving skills especially when writing code. In my case I also learnt how to use the different libraries and methods to write tests. I would like to cite Samir, thanks to you, for the suggesting this approach during the first week of my Apprenticeship.

Code reviews

Just last week we did a group code review and time-boxed ourselves, performed a retrospective at the end of each interval and ensured we delivered a good chunk of the feedback before close of play. Such regular code review exercises are helping all of us learn about how to code better as we are not only learning from feedback from the tools we used, but also through exchange of feedback from our peers who were involved in the group code review session.

Software Design, Specification Gathering & Communication

Recently we had an interesting mob-programming session where we were trying to model and write a game. At the end of the session, we had a retrospective, discussing the things we did well and didn’t do well. Each of the apprentices and craftsmen were performing a specific role i.e. Developer, Domain Expert, etc… We learnt in retrospective, about areas where we could have done better and should focus on. That any test written gives immediate feedback about how well we have understood the domain and if we were taking the right approach. Why a certain approach when starting a project is more advantageous than another approach. What questions to ask and why it is important to ask the right questions to the domain expert or to give the right level of information to another developer and vice-versa. Sandro has described this process in detail in his blog post recently.

Fun, socialising and sharing

I found our office environment to be conducive to learning, sharing and collaboration. We even have a pairing rota that we use from time-to-time to record or suggest pairing sessions during the week.

We share links to events, conferences, tweets, interesting articles, videos, blog posts, etc… via slack, document discussions and brain dumps via Google doc, huddles during lunch- and tea- breaks to talk about anything we are working on. Thanks to the library of printed and digital books to our disposal, the huge collection of blog posts and videos on our site.

The apprentices and some craftsmen have collectively started a social event which of course happens every Friday, sometimes it’s dinner at a nearby restaurant, while at other times an indoor movie over snacks and drinks at our office premises.

It is worthwhile and that’s why we are here

It is a privilege to be able to work alongside very experienced craftsmen from our industry. We are very lucky and thankful to have the opportunity to be guided and mentored by talented and like minded developers.

This is my first job where the company has a completely flat hierarchy and where we share similar values.


Closing note

Work is fun and learning is enjoyable when we love what we do and are amongst friends with similar goals and aspirations.

Thank you for taking the time to read this post and I hope it was interesting. Looking forward to write more and share such experiences in future posts.

Many thanks to Sandro, Tomaz, Alex, Franzi and David for all the feedback provided for this blog post.


SoCrates UK 2013 – my experiences!

Refactoring TDD habits

It’s about 15:21 on 19th September, a group of us from the London Software Craftsmanship Community gathered to leave for SoCrates UK 2013. We all gathered in the same and luckily found empty seats next to each other.

Amongst a lot of jokes, we suggested lets do a small dojo in the two hours we will be travelling. Wifi is free but terrible, on this train – nevertheless we tethered our phones and enabled Wifi on our laptops to make the most of the bandwidth.

This was also about the time when others sitting around me took notice of the desktop wallpaper, it looked something like this:

13 habits of good TDD programming

13 habits of good TDD programming

One thing lead to another, and before we knew, we were going through the above list of habits – some found the habits difficult to remember, others found duplicates and overlaps. There was this tendency that, this is a big list to remember when doing TDD!

So like developers we said we can “refactor” these habits into something more meaningful, maybe even organise them as per our thinking process.

From this conversation the below list was born:

12 habits to good TDD programming:
  1) Write the assertion first and work backwards
  2) Test should test one thing only
  3) See the test fail
  4) Write the simplest code to pass the test
  5) Refactor to remove duplications
  6) Don’t refactor with failing test(s)
  7) Write meaningful tests
  8) Triangulate
  9) Keep your test and model code separate (except when practising TDD-as-if-you-meant-it)
10) Isolate your tests
11) Organise your tests to reflect model code
12) Maintain your tests

You can notice already that the 13…habits shrunk to 12 habits, and their order changed in comparison to the original.

Then @Frankie mentions the difference between Test-first development and Test driven development, no one claimed to know it, but suggested the below:

Test-first development
– you start the development with tests, and change the tests if goal is not achieved via model (domain) code. – No guidelines about design, flexible approach.

Test driven development
– test drives the model code, you never change the test, only model code to reflect any changes that does not satisfy the tests! Guided by design.
Model code = production code or implementation, domain (better term)

Soon we arrived at Moreton-in-Marsh and our focussed changed to getting a taxi to the venue.

I continued contemplating with the idea of collaborating with other developers and ironing our this list – so it can be helpful at the least.

I met @gonsalo and @sandromancuso and ran the idea by them and they thought it was certainly an idea to present and get others involved to see what the final outcome could be.

Next morning everyone was proposing their presentations at the “Open Session”, and I took the chance of presenting – Refactoring TDD habits… in the Cheltham Loft room in the house called Coach at the Cotwold estate!

30 minutes into the conversation and we already attracted discussions between @sleepyfox and @sandromancuso, we did try to persuade them to avoid tangenting from our core topic of discussion.

@sandromancuso also shared with us one of the rules of simple design – as these have evolved over time, these sorta look like this on the flip chart he scribbled on:

4 rules of simple design

4 rules of simple design (thanks @racheldavies for taking this pic at the event, I have cropped it to fit it in here)

– passes all tests
– minimises duplication
– maximises clarity (clear, expressive, consistent)
– has fewer elements

The idea is that all your actions and practises could use these as guiding light to keep on track.

An hour and few minutes later and we have refactored and cleansed the original 13 habits down to 12 habits – reshuffled and rejuvenated. They may not be perfect but close (Kent Beck: use ‘perfect’ as a verb, not a noun – its a journey not a destination!

12 habits of good TDD programming

I sincerely hope that these list of habits do cover the essence of the principles, values and practises of TDD programming.

Prepare yourself with things you should or should not do, and then perform the Red-Green-Refactor actions to satisfy the TDD process.

The things some of the attendees not like is the way of the first list of habits were worded:

  • definition of the word ‘model’ or ‘domain’
  • use of the term duplication
  • the habits being assigned with numbers
  • use of the term assert – one assert per test or groups of assert per logical test

I also brought up the topic of the difference between Test-first development and Test driven development – and there were disagreements about it amongst the attendees, on the meanings of the definition itself. Please share with me your input!

Back to the final list of habits, @CarlosBle brought up a very valid point that some of the habits on the list might be time-based rather than relevant all the time – they were not linear but appear and disappear from the list depending on the current task in hand. We agreed we would sit together and work it out, but @sleepyfox was ahead of us and kindly drew this flow / state diagram on the flip chart that illustrated the list of habits but in a diagrammatic format:

Flow diagram of TDD habits

State/flow diagram of TDD habits (my apologies if its not clear, sometime down the line one of us could come up with a digital version of the state/flow diagram)

@CarlosBle – please feel free to come up with your time-based / non-linear list and share it with us when you get a chance.

Although we got a lot out of the session with discussions on various topics, we haven’t covered everything and finished discussing everything!

I’m more of the idea, that we could try to look at the above habits as trigger points (practical and pragmatic use) to make us do the right things when we are writing code with the intention of writing good code…clean code…quality code…whatever the terminology be in your environment.

At the end of the day, good practises become habitual only when practised repeatedly, with focus and intent.

Please do provide constructive criticism, if any, such feedback to the above are very welcome as they help improve the quality of the post!

Thanks to @sandromancuso & @sleepfox for helping and participating during my session. Big thanks to Socrates UK – its host, facilitators, organisors and sponsors for making this event happen!

Installing SonarQube ™ (formerly Sonar ™) on Mac OS X Mountain Lion 10.8.4


How do we know “how it is being done” when we look at a product or even a code-base of a F/OSS project? In today’s high-speed, fast-paced software industry getting something out quick and earning lots points at the end of a sprint, is becoming a mainstream practise these days. If you want to make sure you are sticking to your Software Craftsmanship motto: “We do not want to ship s**t” like Uncle Bob very rightly says – then you have gotta find a better way to streamline your development process to achieve just that!

That’s when tools like SonarQube ™ (formerly known as Sonar ™) come to our rescue or at least help us in the interim to get a better understanding of what software metrics and software quality can mean for your team! How to compare progress on a timeline and use it to get quick feedback to assess and improve the quality of the code we write and maintain is certainly an important thing to be able to do.

Installing SonarQube on a Mac OS X system hasn’t been as smooth as on systems with a Linux/Unix environment hence this blog. With some tweaks, assistance from third-party sites and following the do-s and don’t-s you should be able to get long and successfully install SonarQube and SonarQube Runner!

As installing and configuring SonarQube is an involved process, a number of items need to be taken into consideration and they have been categorised below under the various topics and sub-topics. Hopefully this makes the journey easier for all of us – since we have done it once and it has been a bit painful, its here for everyone else’s benefit.


The below is a list of hardware/software installations are required to get success out of the instructions put together in this blog:

  • Mac OS X Mountain Lion 10.8.4
  • SonarQube 3.7 artefacts
  • SonarQube Runner 2.3 artefacts
  • MySQL 5.6.12
  • JDK/JRE 1.7.0 or 1.8.0


These instructions have been performed on a system with the below configuration:

Model Name: MacBook Pro    
  Processor Name: Intel Core i7
  Processor Speed: 2.3 GHz
  Total Number of Cores:  4
  Memory: 8 GB

HDD Capacity:  249.8 GB (SSD)

System Version:  OS X 10.8.4
Java version: 1.8.0-ea-b103

Downloading, installing and configuring MySQL

A suitable MySQL binary can be downloaded from [01] or directly from [02].

Installing & configuring

MySQL must be present on the machine running SonarQube – which is the data store where all the relevant metrics per project are stored. To find out on how to go about installing MySQL on the Mac, please refer to the blog post How to install and configure MySQL on MacOS X for UTS [13]. The below window is an indication of a successful installation (System Preferences > Other > MySQL – blue icon at the bottom of the window):

Once the installation is complete, the create SonarQube database SQL script [14]will require to be run via the MySQL console or through another SQL client that can connect to the currently running MySQL server.

Hint: MySQL Workbench for the Mac can be downloaded from this MySQL dev site [03].

Command-line Interface (CLI)

There’s also a few other commands to know as part of daily MySQL operations:

(start the MySQL)
$ sudo $MYSQL_HOME/bin/mysqld_safe &
- or -
$ sudo $MYSQL_HOME/support-files/mysql.server start &

(restart the MySQL if its running)
$ sudo $MYSQL_HOME/support-files/mysql.server restart &

(stop the MySQL if its running)
$ sudo $MYSQL_HOME/bin/mysqladmin shutdown &
- or -
$ sudo $MYSQL_HOME/support-files/mysql.server stop &

Where MYSQL_HOME was set to /usr/local/mysql (check if it is the same in your case) in the respective bash configuration file.

In order to not perform the above command on a regular basis, ensure that the Automatically Start MySQL Server on Startup is switched on.

Check if the database has been created correctly, by performing the below commands on the CLI (look for the highlighted database, you will also need to enter the root password for your MySQL server here):

$ mysql -u root -p

mysql> show databases
| Database           |
| information_schema |
| mysql              |
| performance_schema |
| sonar              |
| test               |

Installing & configuring JDK/JRE

A JDK/JRE must be present on the machine running SonarQube (the java –version command on the CLI, followed by the whereis java or a peek into the  /Library/Java/JavaVirtualMachines/ should indicate the version and location of the JDK/JRE on the machine concerned). A version of the JDK/JRE can be downloaded from either Oracle or Apple’s Java support and download websites. Once installed (or if already present on the system), ensure that the JAVA_HOME is set to the appropriate location, for e.g.:
JAVA_HOME = /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre

Downloading, installing and configuring SonarQube

Download the latest binaries from the SonarSource downloads site [04].

Installing & configuring

Unzip the archive into a folder of your choice for e.g. the /opt/ folder. Once done, set the SONAR_HOME environment variable to point to this location, in the respective bash configuration file:SONAR_HOME = /opt/sonar-3.7/

Source the bash configuration file and perform the below actions to ensure that SonarQube can connect with the available MySQL database:

$ cd $SONAR_HOME/conf
$ vim

    1. comment the derby configuration
    2. uncomment the mysql configuration,
    3. save the changes and close the file.

Also note SonarQube’s JDBC credentials are:

login: sonar
password: sonar

By default the web port where SonarQube is listening, is set to 9000, which can be changed in the $SONAR_HOME/conf/ file. Change the sonar.web.port property to another setting if port 9000 is being used by another application, i.e.


There’s one more place where this is defined and must be in sync with this file, see below in the settings.xml file – the line referring to …localhost:9000… which should be changed as well (to …localhost:9100… if the port settings in the $SONAR_HOME/conf/  is also changed).

Install maven if it does not exists already (recent versions of the Mac OS X comes with maven installed), ensure it is included in system path i.e. PATH and run the below command at the CLI to verify this:

mvn -version

Check if the below maven options are set otherwise set the MAVEN_OPTS environment variable in the respective bash configuration files:

export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=128m"

Finally put the settings.xml containing the below lines into the ./m2 folder (maven’s configuration folder):

                <!-- Example for MySQL-->
                <!-- Optional URL to server. Default value is http://localhost:9000 -->

(additional reference: Installing and Configuring Maven [05])

Upgrading SonarQube from the current 3.x.y to version 3.7

In case you already have SonarQube installed from a previous attempt, then you would just need to upgrade to the new version. But before upgrading to a newer version, please ensure the existing database is backed up, just in case the upgrade process does not restore the existing data (use the Backup facility available under the Settings menu option or go to it directly via http://localhost:9000/backup).

Upgrading to a newer version of SonarQube is as easy as downloading the latest binary and placing the expanded folder into the /opt/ folder or elsewhere on your system, updating the environment variables via the respective bash configuration files (see previous section).Restart SonarQube (see below section to know how to do that), wait for a couple of minutes, and finally run the database migration process by opening the below location via the browser and clicking on the Upgrade button:


…this should take few minutes and the databases should be migrated to the latest version.

Once finished, navigate to the web address http://localhost:9000/ to see the very familiar SonarQube dashboard (see below the screen-shot of the live SonarQube implementation i.e. Nemo [06] on  as an example):

Once the dashboard has been been presented, log in by clicking on the Log in link on the top right corner of the browser window with the below credentials:

username: admin
password: admin

Running SonarQube via the CLI

Starting SonarQube from the CLI with the below command:

$ sudo $SONAR_HOME/bin/<b>macosx-universal-64</b>/ <b>start</b>

or restarting it, if it is already running:

$ sudo $SONAR_HOME/bin/<b>macosx-universal-64</b>/ <b>restart</b>

…stopping it is the same:

$ sudo $SONAR_HOME/bin/<b>macosx-universal-64</b>/ <b>stop</b>

A few other parameters are available i.e. consolestatus and dump – SonarQube needs to be running in order for any of these to work, which you will find out very easily with the “sonar is not running.” message.

Note: MySql must be running when SonarQube is (re)started. In the above case it is assumed that SonarQube is installed in the /opt/ folder.

Download, install and configure SonarQube Runner

SonarQube can be setup to analyse projects through various ways, one of the other ways is to use SonarQube Runner, which requires a file that would contain the basic definitions of the nature of the project. It is used in case the project to analyse is not maven project (does not have a pom.xml file).SonarQube Runner can be downloaded from the same location where the SonarQube binaries are kept [04].

Unzip the archive containing the binary for SonarQube Runner into a folder i.e. /opt/ folder and set the environment variable SONAR_RUNNER to this location in the respective bash configuration files.

SONAR_RUNNER = /opt/sonar-runner-2.3/

Now open the $SONAR_RUNNER/conf/ file to enable the configuration to refer to the running SonarQube instance. Uncomment all the lines except the ones containing the settings to PostgresOracle and Microsoft servers.

Checking SonarQube or SonarQube Runner 

We will cover the two ways SonarQube can be used to analyse a project (written in one of the SonarQube supported programming languages [07]) by either via maven or through sonar-runner (for non-maven projects).
via maven
Here are a couple of links to sample pom.xml files which should help with creating new/ amend existing configurations to integrate maven projects with SonarQube (including additional maven CLI switches) i.e. Analyzing with Maven [08] and SonarQube examples on Github [09]
via sonar-runner

Here are a couple of links to sample files to assisting in creating new ones i.e. Sonar setup for non-maven Java project [10] and Analyzing with SonarQube Runner [11].


The log files created in the $SONAR_HOME/logs folder is a good place to look when faced with build failures or when the web GUI throws unexplainable errors. Also examine this file during the migration process from an older version to a newer one.

In particular $SONAR_HOME/logs/sonar.log contains SonarQube specific system level log messages.


All the CLI commands can be set as aliases in the respective bash configuration files as shown here [12].
Add the below settings to the environment variable PATH definition in the respective bash configuration files:


Always source the bash configuration files after amending them.

Terminologies used
 bash configuration file    ---  $HOME/.bashrc    -or-   $HOME/.bash_profile
 CLI                              ----   command-line interface

External resources

During the installation of SonarQube, a number of links came to rescue by helping tackle some technical challenges and have been mentioned throughout the blog including some below.

[06] (Live SonarQube implementation)
[07] (List of languages, plugins & tools supported by SonarQube)

SonarQube website
SonarQube screen-shots

Sonar project examples on github (multi-languages)

Extend Sonar Integration
Eclipse Sonar plugin

MySQL Tuner
Installing Sonar on the CI server (2011)
Installing Sonar on a linux build server (2009)

In theory these instructions should work on other versions of Mac OS X as well, but they have only been tested on the above environment (see section Environment). 

These instructions are in principle similar to the steps for Ubuntu or other Unix/Linux based OSes – with some tweaks it should be possible to install and run SonarQube in such environments as well.

The terms Sonar and SonarQube have been used interchangeably in a number of places above. Some of it is due to the referred links not being updated, and others are due to the fact that scripts and program references have continued to be used with their original names to prevent issues with dependencies.

Do not take the settings, paths and file locations, url references, excetra mentioned in this blog literally, in some cases they would need to be adjusted to settings relevant to your environment.

Please note all the external links on this blog may or may not stay actual and is not feasible to maintain them as part of this blog post.

Please feel free to contribute to the above post in the form of constructive comments, useful links, additional information, excetra to improve the quality of the information provided. If something hasn’t worked for you and you have managed to make it work or have a work-around / alternative solution, please do share it with us!