Source Control Workflow

At the heart of many software projects (if not all), no matter which language you use (framework, IDE, etc) you have source code.

There is lots of tools out there (git, mercurial, SVN, CVS, TFS, etc) that help us to version the code and keep it safe so valuable changes are never lost.

However when working with a team choosing a tool is not enough and a workflow has to be agreed to ensure that the same practices are applied by all the members of the team, changes are merged properly, tests run, etc.

Lately I been hearing many companies complain about how hard is to find developers.

I do agree, finding good people is extremely complicated.

But not only because perhaps there’s a shortage in the city. Also hiring processes are out of date, driven by the wrong people and produce poor results.

I have done my share of interviews trying to find the right candidate for a position. Let me share a bit of what I learned…

Model your process

Probably by now if you work in the software industry you heard about the word kanban or already are using a Kanban board with your team.

A Kanban board (usually implemented using a whiteboard, wall with stickies, or electronic version) lets you model the series of steps that as a team you have to take in order to produce working software.

Some of the benefits are that you gain visibility, communication and transparency in one simple step. And if you use it right you will be able to show bottlenecks and cope with them or at least elevate the issue to someone that has the power to solve it.

Most important is that you can focus on working based on your team capacity (Pull) vs. working by demand (Push).

However today I don’t want to do a 101 post on Kanban. There are plenty of posts for that, you can find them here, here and here.

Today I want to talk about what is the result when, once you read that intro, decide to implement Kanban with your team. What happens next?

Working with state

In the previous post I showed some examples of writing specifications using immutable classes. For an introduction to specifications please refer to my post about testing.

There’s no denying that immutability can provide lots of benefits in terms of testing, reducing complexity and lowering coupling. Having a language/paradigm that embraces it could be a huge productivity booster.

Unfortunately that’s not always the case or our choice to make ;).