Codurance

Hierarchy of opinion

2017-01-16T16:00:00+00:00

The word opinion has two distinct meanings according to the Oxford Dictionary:

How to use 'npm link' to develop sharable components

2016-12-21T00:20:00+00:00

If you are working on a node project there may come a point where your app has a dependency on another custom module you have created.

How Applying Theory of Constraints Helped us Optimise our Code

2016-12-20T00:20:00+00:00

My team have been working on improving the performance our API, and identified a database call as the cause of some problems.

Setting up Scala on Android

2016-10-16T00:20:00+00:00

Scala can be used to build Android applications, as an alternative to Java or Kotlin. Unlike them, setting up an Android project in Scala with SBT is not straightforward, and can give us some headaches to get it right. To show how this can be done, we are going to create new project template using the Android SDK Plugin for SBT.

Approaching Outside-in TDD on Android III

2016-10-11T00:00:00+00:00

In the previous post, we wrote the acceptance test as a first step and started creating the classes on the entry points of our system. In this post, we will finish implementing the system, and will summarize what we have learnt during the process.

Visualise interruptions on a LEGO Wall

2016-10-10T07:00:00+00:00

As part of the apprentice-craftsmen Programme at Codurance, I had the privilege to attend the Certified Scrum Product Owner course at Skills Matter. During the two-day course, I learnt many techniques to deliver value efficiently, and I am going to share a less widely known tool to help teams visualise interruptions.

Keeping track of interruptions helps teams improve their productivity during inspect and adapt activities such as daily meetings and retrospectives. In order to turn impediments into opportunities, both development team and stakeholders should collaborate, support and trust each other. These concepts are at the foundation of “shared responsibility”: everybody is responsible for the success of the business.

Sharing opinions about what is decelerating the team performance is easy in the best-case scenario where we know that no one will assign blame. However, the culture of fear is still widespread in most organisations and people are afraid of being blamed. When people stop sharing their concerns, they lose motivation and start to leave it to the Scrum Master and the Product Owner to fix their problems.

Team members' concerns turn into frustrations and become internalised. Impediments become even harder to identify when people are afraid to speak up in front of stakeholders.

The LEGO Wall

The LEGO Wall has been conceived to reduce the fear factor when identifying impediments. It is an artifact to keep interruptions visible while ensuring anonymity.

The whole Scrum Team (Product Owner included!) is involved and the Scrum Master facilitates the LEGO Wall Setup Session, explaining the importance of tracking interruptions. The LEGO Wall gives voice to the team’s frustrations. By collecting and displaying real data, it creates the conditions to discuss the interruptions. At a glance, the team is able understand:

How much time they spend working on delivering the value agreed during the Sprint Planning
How much time they spend working on unplanned activities

The core part of the Setup Session is to build a collective understanding of the type of interruptions the team has to deal with. The teammates share their experience and at the end of the discussion they decide to keep track of top categories of interruptions – keeping them to a maximum of five. After that, they can assign a brick colour to each of them.

In the example shown in the pictures the team identified 4 categories:

Production Support: GREEN
Release Support: YELLOW
Business as Usual: RED
Help the PO: BLUE

“Business as Usual (BAU)” is the time spent on the ceremonies and the artifacts associated with the development process. These include: meetings, creating reports, writing documents, etc.

The category “Help the PO” encompasses the activities that the development team is asked to do to help the Product Owner prioritise stories (backlog refinement sessions). In fact, these activities should be considered part of the work, but often the development team perceives these activities as interruptions. Work is not only about coding, UX design or testing; it also involves collaboration with the PO, as these activities are also essential to delivering value.

Materials and preparation

You can build a LEGO Wall with as many base plates as you need, in order to display:

The days of the Sprint (2 boards are enough to keep track of a 2-week Sprint)
As many rows as team members (4 developers as shown in the photos)
A legend of the colours used (4 colours + white)

You will need colourful LEGO bricks to display interruptions and LEGO figures to represent an anonymous team member.

From the pictures, you can see that the team decided to use LEGO figures to represent themselves. This is because this activity should be pleasurable as well as useful. In fact, I recommend creating your own figure as if you are playing a tabletop game. Thanks to the modularity of LEGO and the figures from movies and comics, you can be whoever you want and change your character as many times as you like, so that you can keep your anonymity.

Lego is an excellent tool to visualise interruptions because:

Thanks to its modularity, it is easy to split a working day in 16 1x1 blocks. A 1x1 block corresponds to 30 minutes of activity
Maintaining the LEGO Wall is an effortless activity
It is easy to get the whole team involved because LEGO bricks are beautiful and fun to play with

How to use it

I suggest you hang the LEGO Wall in a place that would be highly visible to the team and stakeholders. We want to trigger discussions in front of it. The LEGO Wall displays real and meaningful data that can be extremely useful during retrospectives. The more colourful the LEGO Wall gets the more margin of improvements the team and the organisation can work on to deliver more value.

Since the LEGO Wall is not a micro-management tool, at the end of every day, each team member should update it exclusively with bricks assigned to each category of impediment. The white bricks should be added only at the end of the Sprint. They have the function of highlighting the time spent to achieve the Sprint goal so that it’s easy to compare how much time the team has spent working and how much time has been spent on interruptions.

The power of the LEGO Wall during retrospectives

The LEGO Wall is a collector for meaningful data that shows how the Sprint went. If the LEGO Wall shows that the team has spent more time on fixing bugs then delivering new value, then they may need to put more focus on quality. Thanks to this effortless way of gathering data the team can set up discussions with stakeholders and, together, find ways to reduce impediments and improve team capacity. Production and release support interruptions are an opportunity to invest in better delivery practices.

BAU interruptions can be reduced by asking a couple of questions:

Why was the meeting or the deliverable necessary?
Does the Sprint goal have any business value (or are we just following a process)?

If the answer to the second question is YES then it means that it’s not an interruption but it’s work that should be prioritised.

Conclusion

The LEGO Wall is a powerful tool to get an idea on how much time the team can spend on working to deliver new value instead of working on problems inherited from previous Sprints.

However, this is not a step-by-step recipe because this tool can be used in several ways according to the following variables:

How experienced the team is
The type of interruptions
The environment
How the company is organised

I suggest staying focused on the principles and importance of this activity (honesty, transparency, courage, inspect and adapt). Don't be afraid of experimenting and changing this to suit your needs. If you start looking at things from another perspective, you might realise that impediments and interruptions are actually opportunities for improvement.

I’ll be happy to hear about your stories and know how you set your LEGO Wall. Which kind of impediments your team has to face? What is dragging your performance down at the moment? Feel free to contact me and send me your pictures! I hope to see walls different from mine so that I can collect them and make them become a source of inspiration for the community. Cheers!

Database Testing With tSQLt

2016-10-06T10:20:00+00:00

Evolutionary Database Development, as coined in Martin Fowler’s book Refactoring Databases, is a concept whereby the design of the database is not done upfront, but instead is done in a way that evolves as the software that is relying on the data store does. In order to have flexibility and to allow changes in the database to be made safely; you need to have a test suite to run and check for regressions. In this post we will have a look at a testing framework for Microsoft SQL Server databases.

Environment

Installing MS SQL Server

Get started installing SQL Server Express . SQL Server Express is a free lightweight version of Microsoft’s SQL Server database.

Installing MSSQL Server Manager

SQL Server Management studio provides us with a powerful user interface to access, manage and configure our MS SQL database server. If you don’t already have it, install it. Please note this will take some time.

Downloading tSQLt

We are going to use the tSQLt unit testing framework to test our Microsoft SQL Server database. We first need to get the download from the official website.

The tSQLt open source framework allows us to run our tests within transactions which makes our tests independant and takes care of cleaning up after it runs. The framework also gives us the ability to isolate our tests through fake tables and stored procedure (SP) spies.

Running the test sample

Once you have SQL Server Express up and running, and MSSQL Management Studio installed, open the latter and connect to your server.

The tSQLt team provides a quick start example database and a set of tests to help developers get started quickly on how the framework works. Let’s try the example together. First unzip the tSQLt folder you downloaded, and make sure that CLRs are enabled on your development server. Enabling CLR integration allows us to run managed code, such as C#, on our SQL Server database.

Open the Example.sql file that you will find within the unzipped folder, and execute it in your database server. This will create a test database named tSQLt_Example.

Once your database is created, open a new query window on that DB and run the following command: EXEC tSQLt.RunAll This is a command to run all the tests. You should see a failing test in the result screen:

Test case number 11, named "test ready for experimentation if 2 particles", is failing. Let’s open the file and see what’s wrong with it; we will need to navigate to the stored procedures folder to find the test.

The failing test is calling the IsExperimentReady function and checks that it returns 1 when the particle table has two particles. Looking at the function, it seems that it is not counting the number of rows in the Particle table, and it is not doing the right checks.

Once we’ve solved the issue, we can run the tests again and see that they are all passing now.

What is this test doing and how is the fake table working?

Tests in the tSQLt framework are run within transactions. The function we are testing relies on the Particle table to determine whether the system is ready for experimentation. Looking at our test here, we can see that we are creating a fake table of the Accelerator.Particle in which we will insert two rows.

If we have closer at look at the tSQLt.FakeTable stored procedure, we can see that it is renaming the original table we are faking, and copying its structure into a new table of the original name without applying any of the constraints. Then we run the test by calling the function under test, knowing that it should use the table we just faked. After the test has run wrapped inside the transaction, this transaction is rolled back. This will revert all the changes made to the mocked table. The test results that were stored in temporary fields are then saved in a test result table.

In this first blog post we learned about database testing, and how the tSQLt testing framework works. In the next post, we will go beyond the quick start example and see how to approach legacy transact-SQL, implementing tests into an existing database.

What I wish I knew when I started as a software developer

2016-10-03T10:10:00+00:00

Having worked in the software engineering field for 6 years, I sometimes pause and consider how much I have learned since I started my career. One thing that strikes me is how many things I would want to tell just-out-of-college me if I had the occasion.

When a good architecture helps you in your UI design iterations

2016-10-03T10:00:00+00:00

I’m currently working on an internal app for Codurance, which started as a pet project while I was working with my previous client. I started the project with one simple goal: to make it work. After six or seven months of trying to put it all together in my spare time, I ended up with a skeleton of a working app. However, I wasn't entirely satisfied with my work. Even though I had been test-driving all the code and all my ViewControllers were as light as I could imagine, I thought it wasn't enough. So I decided to carry out a big refactoring and apply the VIPER architectural pattern.

Approaching Outside-in TDD on Android II

2016-09-29T00:00:00+00:00

In the previous post, we introduced the Bank kata. We explained how we are going to implement it in Android, reviewed the different kinds of tests that we use in Outside-in and transformed a user story into a bunch of acceptance criteria.

Approaching Outside-in TDD on Android I

2016-09-28T00:00:00+00:00

Outside-in Test-Driven Development (TDD) can be a challenge to implement. In this 3-part post series, Christian and I would like to share our experiences applying it to Android development and offer some practical tips for doing so yourself. In this first post of the series we will introduce the necessary concepts and present our broad approach to the problem.

Codurance Barcelona

2016-09-27T10:10:00+00:00

We are very happy to announce that we have opened a new office in Barcelona.

Server side Swift

2016-09-20T10:00:00+00:00

In December 2015 Apple open-sourced Swift, which has been a real success. Many developers are contributing, not only via pull requests directly into the source code, but also by helping to define the shape of the language in the swift-evolution repository. One of the things that came with Swift was server-side development. There's a new version of Swift developed for Linux with a toolset that includes a package manager, the LLDB debugger, and the REPL. This opens a whole set of new possibilities for a lot of companies, such as IBM who are currently making a huge investment in its framework Kitura.

Chinese whispers on Scrum roles

2016-08-24T10:00:00+00:00

Few days ago, I attended the 2-day Martine Devos' Certified Scrum Master, Estimation & Planning Class at Skills Matter. I had the privilege of meeting and learning from Martine Devos, one of the best Scrum trainer in Europe. This also gave me the opportunity to discuss many aspects of the Scrum process.

The Java Synchronisers

2016-08-24T10:00:00+00:00

Threads communication happens primarily by sharing access to fields and objects. Although extremely efficient, this form of communication is prone to errors such as thread interference and memory consistency. Synchronization is a tool that helps to prevent such errors.