NCrafts Conference report

Last week I’ve been attending, and speaking at, the NCrafts conference in Paris. It was a great conference, which had many talks to offer on wide-ranging topics that should make any software craftsman/craftswomen quite happy. Below you will find some remarks, summaries, notes, etc. related to the talks I visited on the first day of the conference.

Sandro Mancuso - The long road

The NCrafts conference was opened by Sandro Mancuso. I didn’t know him, but apparently he is the author of the “Software Craftsmanship” book, which has been republished as “The Software Craftsman” in the Uncle Bob series. Sandro spoke about career development - taking steps in the right direction on the right career ladder. Some interesting ideas:

• Jobs are steps in your career.
• Don’t go too long in one direction; don’t identify with a label that’s too specific (like “Java developer”).
• If you take steps within one job, you might be trapped in your company’s bureaucracy: optimizing for its particular ideas about a career path.
• Sometimes your empoyer isn’t evil, but you leave anyway, since your paths are deviating because of your own desires.
• Becoming a manager is not naturally a career progression - it’s a step on a different ladder. You may get out of touch with the reality of software development.
• A job is an investment. Both your employer and you invest in it. If both of you have gotten from it what you wanted, it may be time to go.
• Switching jobs may be taking a step back on the ladder, only to advance even further after some time.

I found what Sandro discussed very recognizable and approve of his message: think about your career and what you want from it. Study other people’s movements on their career ladders to get some ideas on how to get where you want to be.

Some more practical suggestions:

• If you’re looking for work: apply directly. Don’t let recruiters match you up with a company.
• While reading vacancies, look for signs of passion.
• Make sure the company doesn’t work with project managers who tell developers what to do. Prefer strong team work.
• Look for a company that shows you who they are (e.g. using personal profiles of people who work there, blog posts, Twitter handles).

Vasco Duarte - No estimates: how you can predict the release date of your project without estimating

For many a project it’s true that time makes or breaks it. Some deadlines are real: if you deliver a project after a certain date, lots of money will be lost and you sometimes even have to wait another year for your next chance. Applying #NoEstimates to your projects will make sure they will always be on time.

The journey towards #NoEstimates is scary, but worth it. Vasco in fact allowed us to decide whether or not we wanted to continue the session by picking the red, or the blue pill. The main realization is that: estimates are not there for you. They are - of course - meant to get a grip on the development process, to prevent chaos from happening, to enforce discipline. When estimates get related to budgets, we’re in big trouble, since that removes all the required freedom (to try, fail and try again).

Anarchic though #NoEstimates may sound, it requires great discipline. For example, features have to be developed in a vertical style. This should allow for a constant flow of value being delivered to stakeholders. #NoEstimates is an agile practice, because it makes you, just like the Agile Manifesto wants you to:

Value customer collaboration over contract negotiation.

Value responding to change (over following a plan).

We always have to deliver customer value, and deliver it now. We shouldn’t be focusing on the long-term plan. If we, like we say we do, respond to change, then all the plans we have been making (including estimating the work needed for executing those plans) will have been a waste of time. So, no need to have a backlog, nor estimate what’s on the backlog, let alone re-estimate backlog items.

According to Vasco, we should always ask ourselves: what prevents us from releasing tomorrow? Then fix those issues. Furthermore, when picking up some work, we can follow this heuristic to decide what we should do:

1. Decide what’s most important to build today.
2. Break down that work in risk-neutral chunks.
3. Develop those chunks.
4. Deliver.

“Risk-neutral” means: if that part of the work goes wrong (e.g. takes longer than you thought it would), the project isn’t lost.

Once we’ve been working several sprints in this way, we can calculate a velocity and make predictions. This works better than estimating how much time future tasks will cost. The only thing you need is small stories. With bigger stories, the amount of time that was needed to implement them is often not that strongly related to the story point estimation that was done before starting the work. In general, the size of estimates has very little correlation with the actual duration.

It turns out that the number of stories (as opposed to story points or estimated time) is actually a good way to estimate future release dates. Once you have about five sprints of data, you can easily predict how many stories you can finish before a certain end date or deadline.

Like Mancuso, Vasco has also written a book, which he offers for free for a “limited period of time”. I will definitely read it.

Felienne Hermans - Using F# and genetic programming to play computer bridge

And now for something completely different. Felienne is known for her functional programming work with spreadsheets. This talk was about one of her latest projects: finding an optimal solution for an automated bidding algorithm for the card game “Bridge”. It started out with several steps toward an easy to understand DSL (Domain-Specific Language) for bidding rules. Along the way, Feliene gave a lot of tips:

1. A simple language is more important than a perfect model (you can always add some assertions to prevent invalid usage).
2. If you find a pattern in the language, this is often an opportunity for rewriting the code into something more generic.
3. Read parts of the DSL out loud every once in a while. This gives you quick feedback for improving the understandability of the DSL you’re designing.
4. Pick a language you know. Since a good DSL requires some changes at the level of the language itself, it helps if you know all about it and its possibilities.

With the basic DSL available, we entered the next phase, which was about genetic programming. It’s an interesting concept I had never heard of before. The idea is to mutate code, run it again, and see if the result is closer to what we want to accomplish. This is verified using a so-called “fitness function”, which just returns a boolean indicating if the result is better or not than the previous result.

When you have designed a DSL, the language is already simple enough to mutate code written in it. You “just” need to define some points in the AST (Abstract Syntax Tree) where a mutation would still result in valid code (you can imagine that many, many possible code mutations aren’t interesting to try, since they will result in language-level problems from which the program would be unable to recover).

The program is still work-in-progress, but Felienne mentioned some of the things she has been doing to make the bidding algorithm better. For example she introduced cross-overs, which means splitting the code of two solutions and combining them again after swapping the first “half”. She’s been taking the x best results and decided to mix in some lesser results, in order to keep the population fresh and to not over-fit the final result.

In conclusion: this was a very interesting talk, which introduced me to some nice and interesting new ways of thinking about code.

Jef Claes - Evil by design

I was eager to watch Jef’s talk (although it made me miss Carlo Pescio’s one, but, as the conference organizers told us: no need to be afraid to miss a talk - they are all being recorded!). Jef has been working on software for an online gambling company. His talk was an interesting story about the effectiveness and helpfulness of Domain-Driven Design in an initially “legacy” project. He and his team members started to learn all about the world of online gamblings. This discovery process led to some useful insights into the different domains that were at play.

The idea of course is to convince people to start gambling, then give them the feeling that they are winning, convince them to stay a little longer using bonuses, and finally earn a lot of money from them (because the casino always wins). To optimize this flow, they started introducing events in their software. At first they used a hybrid model for entities, with both the state being persisted in a good old database, and the new events being appended to an event stream in an event store. It’s not something to start with if you have a green-field application, but in their case, it was the next-best thing.

Having all these events at hand, they were able to run all kinds of interesting reports on them. They basically had a log of everything that had been going on in their system, including time stamps and user identifiers. So they could find out what usually happens at different times of the day, month, or year.

When visualized, the event streams would give them insights into aggregates modelled wrong (too many events happening inside of them), anomalies after a certain release (they would be able to see spikes on their dashboard). They could also start dividing players into groups according to their particular behavior and the pattern of the events that were linked to them. This would help other people in the organization to come up with ways to give those players a better (and longer lasting) experience.

If I remember correctly, Jef is the first speaker who publicly addressed the ethical aspects of his work as a software developer in this interesting area of business. I guess that talking about this subject in public should at least alleviate some of his worries about karma.

Simon Brown - The Art of Visualising Software Architecture

Another talk I was looking forward to very much! Simon addresses a big problem that is everywhere in our industry: the lack of proper architecture diagrams. Ever since we abandoned UML, we have been creating all “boxes and lines” drawings, without having an actual standard for these. So most drawing sessions with a team end up in a big visual mess. Someone who wasn’t at the meeting wouldn’t be able to understand, let alone explain the diagram to other people. Simon has been looking for a style of drawing an architecture diagram that doesn’t require you to forever come with it to explain it - it should be self-explanatory. After all, we want to be agile, moving fast, together and in the same direction, so we need good documentation, written as well as visual.

Simon proposes a set of notation agreements, but also a distinction between different views of the same system. He recognizes four different viewing contexts (hence the name of his architecture diagram model: C4). There is a Systems context, a Containers context, a Components context and optionally a Classes context. These are basically just different zoom levels for the same thing, showing more or less details.

The problem with architecture diagrams is that they will soon be out-of-date. They are part of static documents, created only once, and never updated when something in the architecture changed. If an architecture diagram doesn’t reflect the application’s code, then it is useless. So ideally we would generate architecture diagrams from the code. Much of the architectural knowledge is implicit in the code though. For example, in many languages it’s impossible to mark code as belonging to a certain component, yet, there is likely to be some (tacit) knowledge about the implicit component boundaries.

To solve this issue, Simon has created a service called Structurizr. He also developed tools for Java and .Net code bases to extract information about a project’s architecture and publish that data to Structurizr’s API. From that point you can let the actual architecture diagrams be auto-generated, posisbly even as part of your build/continuous integration process.

Very promising actually, and such a “simple” idea that I guess that it has a serious chance for survival. But even if you would never use Structurizr, you could at least use the C4 model to draw proper architecture diagrams from now on.

Simon has also written a book, The Art of Visualizing Software Architecture, which I put on my reading list right-away.