Tuesday, October 5, 2010

The industrial mindset

There is an industrial age mindset that has carried over in the software industry and it's horribly broken.

It's the belief that management is science. 

Management has very little to do with science (although there are tons of studies of actions that do and don't work from a management perspective) and should be mostly about dealing with individual personal issues, the things that make employees non-interchangeable, the things that keep employees motivated.

Unfortunately, it looks like very few organizations are able to apply modern management strategies that help workers stay happy and motivated. Workers are often regarded as interchangeable Lego bricks. Taylor inheritance? Corrupted business schools?

The three essentials for motivation from a managerial perspective when dealing with non-repetitive work are autonomy, flow-mastery and purpose.

Autonomy is essential for happiness. You need to feel like you're making the decisions that affect you directly. This will probably be the hardest one for traditionally-schooled managers to absorb. Employees come in whenever it works for them, work at home, meetings are not mandatory by default and there are no time clocks. The only thing that matters is results. Superfluous to say is that autonomy builds on trust and purpose.

Flow is the daily satisfaction you get from doing something that's not too easy but not too hard. Ideally you get flow every day, and it's what carries you through the difficulties of achieving mastery.

To achieve flow, you need:
  • Clear goals
  • Immediate feedback
  • A challenge that is not too easy nor too difficult
  • Autonomy
  • Something that engages you
  • Enough structure
Continuous flow leads to mastery over time.

Examples: TDD, iteration ending with functionality demo

Purpose is the feeling that you are working towards a higher goal. The idea that there's a reason (mainly non-profitable) why we do what we do (Maslow's self-actualization).

You really need all of them in order to feel happy & motivated. For example, you could be working in an environment where you feel autonomous but you get no sense of flow at all (not enough structure, no feedback in time).

Monday, October 4, 2010

Continuous integration anti-patterns


Rare check-ins

The most important practice for CI to work properly is frequent check-ins to trunk.

Many projects use branches and forget that if you are not merging your changes to trunk often then you are not doing truly continuous integration since you are not integrating the changes done in different branches.

There's a collision between branching and CI. That's why branches are not recommended except in very limited circumstances.

Lack of a comprehensive test suite

Without unit, component and acceptance tests being run by your CI system, how do you know that your software is working?
Many projects just rely on a passing compile build which is clearly not enough for most applications.

Long build times

Ten minutes is probably the limit. More than that will make people check in code less often which in turn could lead to more failing builds.

The problem is usually long-running tests. To overcome the problem, split your test process into 2 stages that run separately: the commit stage that just creates a deployable binary after running unit-tests (on every check in) and the heavy-testing stage that uses the binary from the first stage and runs a series of acceptance, integration, performance or other type of long-running tests against it.

Slow development workspace

The most common problem is that the application cannot be run locally or it takes a long time to do so. This means that the application cannot be tested on the developer's machine prior to check-in without going through a lot of pain.

Possible solutions include deploying the application on lighter containers on the local machine or use products e.g JRebel that make it possible to skip (longer) redeployment phases.