Anti agile words: weekly

I don’t like the term weekly.
It sounds fixed, it does not sound agile.

Used in contexts such a weekly meeting: do you really need a meeting every week? I would rather consider to have a meeting as needed, when there’s a real problem, when the benefit is evident.

A weekly status report? Why? Why not pulling the status of the project directly from your continuous integration system or from your tracking tool (Mingle? Track?).

A weekly catch up? Why not having informal catch ups, only as needed, only when there’s something to talk about it?

A weekly release? Why not releasing as soon as you have working software, why breaking your work flow in weekly iterations?

I worked in a project where there was the bad habit of a weekly commit (!), on Friday late afternoon, to close the week.

I worked in a project where there was a weekly remote standup meeting, nothing more useless and boring: people talking at the phone and no one listening.

Weekly doesn’t sounds good for nothing, not for iterations, not for releases, not for meetings.

A Value Stream Map might help you to understand if your weekly commitments are really giving you value or not.

TDA, test driven analysis

Recently one of our clients had a big problem on production, having to restart a critical application a couple of times in two days, with few hours of service outage.We have been asked to investigate where the problem was and in order to figure it out we wrote few tests around the legacy application.The finger was pointed to a Bash script launching a Java class that has been written in the past without any test coverage, as soon as we covered the code with tests we gave the unit test reports to the client analysts.The test methods names were of course specifying how the obscure code was behaving in the very common (at least inside ThoughtWorks) way

Should...()
{
   Given...
   When...
   Then...
}

Test driven development is important not only to drive the design but also to have an executable, up to date documentation, if there’s a lack of tests I can’t think on anything better rather that writing tests around a legacy system in order to understand it and documenting it.

Domain Driven in the financial world (II)

Josh was right on his comment on my previous post about DDD in the financial world: we had a new requirement from the client: design a market simulator.

Basically our market simulator is a tool to parse the production logs, inject them into the application and verify that the behaviour of the application is correct. (A commercial tool called VeriFIX does more or less the same job, but we need more flexibility)

It will be used when upgrading to newer releases and when installing a new instance of the Fix Routing Engine.
It is end to end black box testing, with some reports to understand if everything is still processed by the Fix engine as it’s supposed to be.

From a new joiner on the Fix support team we had the request to show in the reports not the tag values for the processed fix messages but the description and (not a surprise) even a senior developer of the client was asking the same feature.

Looking then to the full picture we are always playing with the same object, the famous Fix message, with his near to 1000 fields but we use friendly tag descriptions on tests and code, tag numbers on the DSL: concise and quicker to understand by the Fix team and finally again tag descriptions for the Fix support team in the test reports.

Every context has its own language, even inside the same division, even in the same domain.

Fan Programming Language

I’m just having a look to Fan and it seems quite a cool language, soon more posts on this.

Fan Programming Language: “Portability
Write code portable to both the Java VM and the .NET CLR.

Familiar Syntax
Java and C# programmers will feel at home with Fan’s curly brace syntax.

Concurrency
Tackle concurrency with built-in immutability, message passing, and REST oriented transactional memory.

Static and Dynamic Typing
Don’t like the extremes – take the middle of the road.

Elegant APIs
We’re quite obsessive about providing all the key features required for a standard library, but with much less surface area than the APIs found in Java or .NET.

Object Oriented
Everything is an object.

Mixins
Interfaces but with implementation.

Functional
Functions and closures are baked in.

Serialization
Built-in ‘JSON like’ serialization syntax makes Fan ideal for declarative programming too.

REST
Model data with a unified namespace of resources identified with URIs.