Live Coding at a Conference, and why it is Scary

In less than a week, I’m giving my first ever professional talk at the I.T.A.K.E. Unconference in Romania. The topic: the four elements of simple design, and how functional programming is absolutely necessary to achieve them.

I’m quite excited.

I’m also quite terrified.

You see, I don’t like giving talks. I like showing people code and letting them experiment by themselves. Usually I learn way more this way round, and what’s the point of teaching if you can’t learn from it?

Unfortunately, you can’t do that at a conference where you’ve been asked to speak. Doesn’t sit well with the attendees, who have paid good monies to learn from you. (By the way, that fact right there is why I’m terrified.) So I’ll be coding live, taking imperative and object-oriented code and showing how a touch of functional really makes your code much better.

There was just one problem.

It turns out, much to my surprise, that there isn’t a decent way to find code that is quite good but broken in just the way you’d like. This is unfortunate, but I understand why: indexing GitHub by terms such as “kind-of-imperative and a bit Java as it was written in 2008” is tricky. Even Google would struggle with that one, I think.

So I wrote my own: Quacker. It’s a Twitter clone that’s kind of crappy (mostly intentionally) and very much a toy for me to mess around with BDD, dependency injection, object-oriented style, functional programming and lots more. Right now, there’s no functional code on there (it’s on a secret branch hidden from your prying eyes) but after the conference, I’ll merge it in and the current, imperative state of the code will become a tag, confined to history, immortal but forgotten. (I hope. It’s not very good.)

The intention behind Quacker is that it’s a sizeable enough codebase that interesting things can be demonstrated by changing things around, but it’s simple enough that you can figure it out and start changing things to fit your needs fairly easily. If you want to show, for example, the difference between code with dependency injection and without, you can probably re-wire part of it in under an hour to demonstrate your point. It’s a bit enterprisey, enough to feel realistic, but not enough that you can’t get anywhere.

It’s been fun writing it, but unfortunately, it’s not as clean as I’d like, even though that was one of the goals. Why? Because of deadlines. Now, I haven’t compromised completely—pretty much everything is fully tested—but I have had to actually start working on the presentation rather than just hacking on a random toy project.

Now the presentation is finally coming together, and I feel pretty good about the result. I hope it goes well on Friday (and if not, you’ll be able to laugh at the recording later). My fingers are well and truly crossed.

The Social Networking Kata

Last week, Sandro and I had a lot of fun running our monthly hands-on session for the London Software Craftsmanship Community. We decided to make things more difficult for ourselves (and the attendees) by combining two of our favourite sessions: testing with BDD, and object calisthenics. The victims lucky people had a choice of solving the problem using BDD/ATDD, object calisthenics, or both. Of course, if they opted for just the latter, TDD was still mandatory.

Our original plan was to use the Bank Account kata: Sandro used it in a previous session with object calisthenics and it worked well. On the day, though, I decided I was bored of it and that we should write a new one. Sandro had the bright idea of thinking in the realm of social networks (paraphrasing his words, “Social networks are cool, bank accounts are not.”), and we went from there. A few minutes later, we had something, and it went down really well on the night.

So, I present to you, our Social Networking kata.

Read More

Quality, Revisited

Wow, that was a lot of great feedback in a few hours.

So let’s talk about it.

The first thing I want to talk about is the tone of the piece. It’s kind of idealistic. Of course, things didn’t always go that smoothly, but we aspired to meet the standards we set for ourselves. And things were definitely improving everywhere you looked. syl commented on how the TV screens were mostly red. This is actually true at a lot of places that measure build breakages, because keeping all 200 builds green at all times is an absolute nightmare. Especially when a lot of them are hitting a test web server with Internet Explorer 6 and WebDriver, trying to break your application. You might break the application, or you might simply break IE.

This got a lot better when we made the (painful) upgrade from Selenium 1 to Selenium 2 + WebDriver, by the way. If you’re running anything through Selenium, I wholeheartedly recommend you take the hit—your browsers will become so much more stable. When I visited TIM Group recently, everything was looking nice and green.

Andrew Parker asked what the question was that prompted the piece. It was in an email from Ed: “Basically I wanted to know what process (Agile, Kanban, Waterfall???) you follow and what tools you may use to help (JIRA, etc)? Any books/resources you can recommend too?” I replied with an answer, but I was dissatisfied with it, so I blew it up by a thousand words or so and made it into a blog post.

Finally, David Green pointed out that the dogma on the cost of fixing bugs has been debunked by Laurent Bossavit in his book, The Leprechauns of Software Engineering, along with other myths and legends. I’ve added it to my reading list and I’m really looking forward to it.

Thanks so much again to everyone who retweeted, commented and gave advice on the post. I really appreciate it.

Quality

Update: I’ve answered a few comments I had in another post, entitled Quality, Revisited. Please check it out after you’ve read this one.

“Tests take too long. We don’t have time for that.”

Good one, Bob.

Let’s talk about TIM Group, a company for which I used to work.

Imagine a few different teams within the IT department of your local investment bank. The developers at TIM Group are kind of like those guys, except without all of the bureaucracy. The “technology” department at TIM Group is the biggest part of the organisation, and they have complete control of the technical portion of the products. Product teams figure out what needs to be done, but the developers build the product and the infrastructure team are responsible for deploying it as they see fit. What this means is that new products (classified as “anything built after we heard about continuous deployment”) are deployed immediately, as soon as all the tests pass, and old, feature-laden products are maintainable and generally quite stable. There is the odd regression or bug, but it’s usually something minor.

Continuous delivery or deployment is the norm, backed by a large cluster of Jenkins and Selenium nodes that ensure the software is always functional. As soon as a test case fails, its name flips from green to red on the massive TV screen, in view of every developer, as well as on pretty much every dev’s screen. Tom Denley, who works at TIM Group, built CI-Eye for exactly this purpose: making sure that when something’s broken, everyone knows it.

So how does the development process work? Basically, they use a modified version of scrum with elements from lean (and quite a few things that were invented in house, specific to the developers around). There’s a daily standup, either first thing in the morning or right after lunch. They use a universally detested (but fairly functional) online kanban to list the work for the sprint (usually one or two weeks) and allocate work in pairs. Pair programming is highly encouraged—to the point that you should have a good reason not to pair.

The developers are split across the London and Boston offices. Teams tend to have approximately five developers and a business analyst, but one or two of them are divided between the offices, which presents some interesting challenges. When I left, our “Atlantic” team was pairing by sharing screens and by using the Eclipse plugin Saros, which allows you to share editors within Eclipse. This was also the technique used by our two remote developers in France.

So how do they afford to put so much effort into pairing, remote development, testing and all of that agile mumbo-jumbo? Doesn’t it cost a fortune? It turns out, not so much. Central to the development practices at TIM Group is the mentality that the whole “price, speed, quality: pick two” mentality is bullshit. Quality is the priority, and speed will follow, driving down the cost of development. In their case, quality means end-to-end acceptance tests, unit tests, pairing so you have four eyes on everything, and tasks broken down so that each individual piece of work takes no more than a day or two for a pair. There is a server farm dedicated to running the acceptance tests. Maintaining all of this is a shitload of work, but it results in a product with which customers are very happy.

Of course, it’s very easy to do a great job on entirely the wrong thing. Steve Freeman talks about “doing the right thing” vs. “doing the thing right”. Both are important, but you should be asking whether you’re doing the first one before you worry about the second. Talking about the product vision is way out of the scope of this article, but there’s also a lot the developers can do, in the form of retrospectives. This involves all huddling up in a room at the end of the iteration (basically, every one to two weeks) and talking about what went well, what went badly, and how things can get better. The important thing here is to come out with actions, which allow you to actually fix things, rather than whining about them week after week.

In the long run, the hundredth feature to a project costs less with all of this baggage than it does without it. Without it, you have to test you didn’t break the other ninety-nine manually. Chances are fairly high that it’s going to take forever, you’ll get sloppy, and you’ll miss a regression that should have been caught. Research states that that throughout each phase of development, the cost of a bug increases by an order of magnitude. Catching a bug during development costs a lot more to fix it than catching it during the design phase (which could just be thinking, discussing and whiteboarding). If you find it during manual regression testing, it’s much more than that. The cost of your customers finding a bug in production isn’t just development time, test time and release time, it’s your reputation. When something that easy to lose goes on the line, the numbers tell you you’re much better off taking the time up front.

With practices so important to the continued success of the teams, recruitment becomes very important. Developers can’t just accept feature requests and pump out code. They need to be heavily involved with the business, rejecting features and suggesting alternatives if necessary to avoid a slow, dysfunctional, hard-to-use application. This means they need to understand the business requirements as well as how to write code in the latest, greatest programming languages. In addition, commitment to good practices is necessary. A single person avoiding test cases will destroy confidence in the infrastructure surrounding the project—if new things aren’t covered, we have to resort to manual testing. And then, finally, they have to be competent at their job—to write code that is functional, understandable, flexible, and maintainable.

The important thing is not the methodology, it’s the mindset. Figure out what your team’s priorities are and build your processes around them. How you do client meetings, design, development, hiring or anything else isn’t as important as whether it fits in well with the goals of your team and the future of your product or service. Your goal is the most important thing, and everything else should be constructed in aid of it. If your goal is to deliver something tomorrow, hack it out. But if it’s to deliver a great product that makes people enjoy handing over their wallets, then maybe it’s time to start doing things right, as well as doing the right thing.

Thanks to Edward Wong for asking me this question via email, therefore prompting this blog post. Thanks doubly for the criticism after I’d written it once. Sorry it took so long to finish, Ed.

Don’t Call Us. We’ll Call You.

I’ve been thinking about why I dislike Ruby on Rails for over a year now. It’s not the much-touted “convention over configuration”—that’s actually quite lovely. It’s not the ever-increasing rate of zero-day security vulnerabilities: while that’s worrying, it’s not going to stop me from using it to knock out a web site over a weekend. Security is only necessary when you have a product and some customers. It’s not even because DHH is a bit of a tool. I don’t think I’d get along with him at a conference, but that’s no reason to shun his company and product.

It’s because it dictates the terms of agreement. You don’t.

When you create a new Rails application (and you have to use their command-line tool to do so), it comes with a folder structure, from which you really shouldn’t be deviating. You must use ActiveSupport, which monkey-patches everything. ActiveRecord is pervasive, and comes with some pain: once you use it, nothing is testable in isolation. I’m told that that’s OK—integration tests will take care of everything—but that’s not the way I operate and not the way I think. It also forces me to write a test suite that is designed to make me avoid running it, because slow feedback is almost as bad as no feedback.

All this, because it’s a framework.

Read More