We’ve had a lot of various blog posts recently on speaking in public, and Todd’s post got me thinking about the posts I’ve had in my drafts for a few days. I was going to publish one or two posts, but I thought better of it, and created a new serial, in three parts, to tell you about speaking: the truth, the whole of the truth, and nothing but the truth; except for the lies. I came to speaking, I got better, and I now have a bunch of principles, rules and tactics to speaking, hence the three-parter: Veni, Vidi, Vici.

Veni

When I was a teenager, I loved theatre. I was part of the club in school, and one outside of school, and over a few shows I really fell in love with the stage. You leave reality behind, create a persona, accessorise it with a text, and you get on a stage, a place where you can be anyone.

A few years later, as a developer, I gave my first talk. The year was 2001, the place was Munich, the subject was P2P. I had no idea what I was doing, and had the arrogance of youth combined with the self confidence of a french man - or the other way around. I did dreadfully. My talk was a “sponsored” one, and the audience was only another 15 guys, all in P2P already, and most 10 years older, including Bill Joy and Cory Doctorov. If I had had any shame back then, I would have been ashamed by that botched job.

Keep trying, failing is OK

After a heathy pause, I went back to it, I can’t remember if it’s 2007 or early 2008, my blog seems to have forgotten this. The first couple of times were really good fun, as I started going to many user group meetings People seemed to appreciate my unpolished but energetic style. I had no idea what timing meant, i swore like a sailor and I had no slides ever, but life was good.

People are very quick to provide you with help and feedback in those environments, and I keenly listened to many of the suggestions that were given. And then my talks started tanking. By trying to adopt the formulation and style of other speakers, I attempted to replicate imperfectly what made them, and lost what little I had. Life was said.

I decided to go back to basics, and not listen to speaker trainers ever again. Instead continued speaking, made countless mistakes since then, met many amazing people and heard more great ideas than most developers will encounter in their whole carreer. Life is good again.

It’s about you

Speaking in public is a difficult art. Not everyone comes from the same background, some of us are not native english speakers, some of us are terrified of people, some of us are introverts, some of you are extroverts, and yet all of us can be speakers.

User-groups are a fundamental part of encouraging people to speak: they are safe environments, often full of like-minded people with a long-standing link. They’re also, by definition, the place where talks get practiced on. It’s a system that benefits everyone, from the speakers that get to give the first health check on a talk without fear of tanking, to attendees that get information and pizza, to user-groups filling their events with interesting and varied topics.

We are very lucky in the UK to have had a very vibrant user-group community, one that has worked restlessly to provide the most fertille breeding ground for new speakers. If you want to try out, with encouragements, support, an avid audience, and no one giving a lolly if you succeed or fail, user-groups are the place to be.

It’s not about you

But to speak, you have to accept that people have to come. There is no point in giving a talk if the room is empty. While some speakers can fill a room by the sheer magnitude of their brand, most of us 124still have to find something that will draw people in.

You would be surprised by how many interesting things you’re actually doing. If you haven’t created anything, give a tutorial! I started presenting on asp.net MVC 1.0 preview 2 and on the MVP pattern. People are always avid to get an hour to discuss and see something outside of the constraints of their day-to-day job.

It’s about what?

Attendees come because they like hearing about cool, and sometimes less cool but useful, things. But what’s in it for you, and why should you care?

Public speaking is a matter of perspective. Not the speaking part of course, but the public part. Is a public made of four people in a room, eighty in a conference centre, or just your colleague next to you? They’re all the exact same thing: conveying knowledge to someone else. When speaking, you learn how to articulate the knowledge or opinions you gathered, and communicate them to others.

To communicate that knowledge, you need to take the time to reflect on how it all fits together. Be it that you find a way to split learning into parts, or maybe you have to decide the order of the slides in a presentation. I don’t believe for an instant that speakers are anything special, or that anyone should listen to anyone due to their speaker status. I do believe, and I paraphrase a blog post I cannot find anymore from I don’t remember who you are, that speakers exist because we need them to take that time off away from building things, to organise thoughts and investigate mental models to teach to others.

So I came…

Speaking helps attendees, user-groups and conferences. And if you are so inclined, it can help you organise your thoughts, have more confidence in public, and become a more effective learner and teacher. It is however full of difficulties, as we shall see in the next instalment.

Feature toggles have been on my radar for a while, thanks to Martin Fowler’s introduction from back when, where he argues for enabling or disabling certain features of an application dynamically, based on some sort of switch. For many years this fell on dead ears, for I never really encountered any reason to pursue this avenue on real systems.

Fast forward a bit in time, and I inherited a project in which those feature toggles were used everywhere. Having to deal with the downfall resulting from their spreading in code-bases has been, to put it mildly, emasculating, the kind of pain I imagine child birth must induce.

The goals

The original intent of feature toggles is mighty fine. We’ll build this new feature, and it will be nicely enclosed in if statements, and we will only show it when it’s ready to be released. Maybe the feature will get enabled based on which user is an admin, and which user is a standard average Joe user. The promise to segregate development and prevent the release of a feature until it is complete is compelling, and the idea of activating or deactivating features is as well.

So what happend to make it so painful?

The path to heaven is paved with zombies

Implementation-wise, the code-base I inherited was littered with if / else. Each feature toggle was created in an XML file, and each code impacted by the changes would be enclosed in conditionals.

As you can imagine, the first issue was a code-quality one. When you manually have to remember to if/else everything, people make mistakes. With feature toggles, they make even more. Not only do you have to conditional the code, and as such have an extremely thorough understanding of the dependencies involved with a feature, but you have to double your tests, for you need to check with or without each feature combination the expected result. If you have multiple features in flight, you have a cross product of such test configurations. As it’s too hard to do, no one does, and your reliability goes down the drain.

Once a feature is released, developers, at release n+1, are expected to remove the feature toggle. This presents its own set of challenges: a feature toggle may be forgotten somewhere, developers in charge of that feature have moved on to another feature and forgotten to remove it, and it’s very hard to automate the detection that some toggle should not be there anymore. When people continuously make mistakes around a manual process, we automate it, and this automation is usually absent.

Run, zombie, run!

That’s just the development-time issues. I touched about the difficulties in understanding your dependency graph when you have code using conditionals to activate or deactivate things: the contract is poorly defined. Without strong contract and component boundaries, activating or deactivating things is too complicated for my head to reason about.

As for changing something at run-time that influences the way your software works, we reach the most unreliable and dangerous part of the idea. You will corrupt systems. Be it that you are using SQL, or event-sourcing, introducing data that is only understood by a new component can only be done if the old component is ready to ignore those things, and all those changes were made additionally. It’s doable, and I’m a big supporter for such forward compatibility designs, but that is not without its costs, and those are usually not explained to the developers implementing those toggles.

And if corruption was not enough, one has to think about operation boundaries, a.k.a. what is the unit of work, and is it possible to activate and deactivate a feature half-way through that. Is your unit of work the adding of a line item in your basket, or is it the whole buying process? Can you change data in the ordering part and revert back the feature by the time you check-out?

The complexity graph is enormous, and anyone that says the contrary has not been exposed to the code bases I’ve seen. This stuff is dangerous, unreliable, hard to automate and just plain unusable.

No if, no but?

From a functional perspective, we have to formalise the changes in data structures we pass around various systems for features that persist or message data to be able to be activated or deactivated independently. A good guideline is to ensure a system with a feature toggle only persist to its own datastore it does not share with any other system using a different version, aka keep storage private. For communicating with the other services in your systems, extensible and compatible messages with forward and backward compat still apply, be it that you’re in ESB or ReST or whatever. Those constraints ought to be applied and understood first and foremost.

For code quality, it’s a bit simpler, and already has a name, and it’s called composition. New components implementing new features using existing contracts (say, implementing an interface) can be developed in a copy-on-write way, keeping the old and the new components in your code-base, and switching at will between the two. Alternatives allow you to do this by branching code, but I tend to privilege the copy-on-write, as it forces you down the path of making component boundaries more explicit. The components get selected and wired-up together at startup time of an app, so if you want to enable or disable a feature, you’ll have to restart the box, and it’s a good thing: you make sure that no component ends up expecting a changed behaviour from another component that just reverted to an old version.

As for the UI, the sweet spot for me has always been to use an Eventing model for building UI areas dynamically. For example, the app emits an Init event, each module replies with a self-descriptive message containing the extension points it desires to add to the interface. Want a “kick/ban” button if you’re an admin? Check the user credentials and add yourself by responding with a message describing buttons you want to provide.

R.I.P.

If you build your software as a set of independent plugins, with messaging to communicate and composition as a feature toggle, you’ll end up with cleaner and more reliable code. You can still litter your codebase with ifs, but be careful not to fall.

Building software is easy. Really, it’s just a matter of writing a bunch of statements that do something, and voilà, you have a running program. Building the right software is where the complexity lies.

Too often, we fail at building the right thing, and in my experience this has always come from poorly communicating what the software ought to achieve.

On the technical side, test-driven design has made great progress in becoming a mainstream approach to delivering simpler systems, and that’s great when you think back on where we were in the early 2000s. Yet, more often than not, the resulting test suites can become brittle, poorly maintained, hard to read and refactor-unfriendly.

So over the years I’ve refined a methodology to try and address, or at least minimize, both issues.

User stories with feature Injection

There is a French saying, “Ce qui se conçoit bien s’énonce clairement”, which translates roughly to “whatever is well conceived is clearly said”. When discussing something we want to build, how do we make it clear enough so it describes well what it does and why it is needed?

The first step, as we are in our first iteration, is to discover what our user is trying to do. To do so, i’ll write my first user story, using feature injection, which my good friend Liz Keogh has written about for quite a while now.

In order to chose which movie to watch
a user can browse all movies available on restflix

So there is our first feature. The fact that we talk first about the value it brings is essential to understanding and keeping in mind, all along our analysis and development, why we are building what we are building.

The first feature is as such a movie browser, and it exist for the sole reason that it allows someone to watch a movie. Time to drill down a bit into more details.

Scenarios

The next step is to drill down into reproducible and understandable scenarios, which we provide using examples, as they are more palatable to humans.

Given Anna has a valid account
 When Anna logs in
 Then she can see the list of all available movies

Is this clear enough? Can we assert that she sees all available movies? Probably not, for we don’t know what “available movies” mean. Let’s be a bit more specific in our example, so we can assert the correct thing.

Given Anna has a valid account
  and "Star Wars Episode IV" is available
 When Anna logs in
 Then she can see the list of available movies
  and "Star Wars Episode IV" is in the list.

This example is now self-describing enough to be encoded straight away in tests.

Specification-driven development

I’ve never been a big fan of spec tools, as I find that the code diverges more often than not from the intent of the original code-base, or sometimes even force most of the work to be about gluing things together rather than delivering value (coughfitnessecough.)

I don’t claim to have found anything new here, as this style of testing is a combination of many things I’ve seen and liked / disliked over the years. Nevertheless, here it is.

First we start with encoding the specification itself in code. Please note the code may not compile, it’s written from my iPad, it doesn’t really matter if it does, as long as the example is understandable.

You’ll notice that there is a bit of variance from the original text, but it should still be readable by non-developers, provided you tell them to remove all the punctuation.

Secondly, you’ll also notice the Users and Movies classes. Those are testing personas I always create in a project. I may leave that for another session.

The file name ought to be a reflection of the scenario you are testing, which I would describe as a summary of the preconditions in the test. As you evolve your specifications, the names may change to become more descriptive, or you may split them in sub-folders, as I’ll describe a bit later.

You’ll finally notice that I inherit from a “context” class, in which all the given/when methods are actually implemented.

The givens and whens are implemented in a base class so that our tests are easily readable. I usually start hacking all of them on the class, then introduce a base class and pull up the implementations in the base abstract class.

The design of the App class evolves from the implementation of the context class, forcing you in designing the first cut of your object model, just enough to get the compiler happy and the tests implemented.

A folder structure

From this code, the tests tend to be organised in a structure that mimics the logical structure I just described.

/tests/component/feature/scenario.cs

In this example, it would be.

/tests/app/browse_movies/movie_available.cs

As you add more and more scenarios, the payoff becomes obvious. Find a new combo of examples, a new initial state, and you get to failing tests in a matter of seconds.

You need to continuously re-evaluate the name of the tests as you discover more descriptive ways of talking about all the scenarios for which you provide examples. This is where sub-folders within each feature can help.

Conclusion and thoughts

Your mileage may vary. Once upon a time one developer considered having one abstract context class to be too complicated to navigate to.

I find this way of modeling my specifications to be great for refactoring (only the base class to change, the language does not), the existing scenarios stay valid over iterations and focus on language and benefits, on what the software is supposed to deliver rather than the how it does it internally.

To be useful, this means language ought to be extracted from practices and discussed openly and continuously. I have seen architects that spend too much time in conferences argue for a company-wide ubiquitous language, going as far as specifying their own terms they pulled out of a hat, that were already in use over multiple domains, and enforce them with the authority bestowed upon them by their title to other development teams. The result: old and new terms, used continuously and erratically, and the idea that “people just need to…” will lead to a clear way to communication.

I disagree. By putting specifications, examples and conversations at the core of the discovery and development of an application, a language will naturally evolve. And when things are not easy to name, a dictionary is your best friend.