Trisha's Ramblings

Why the customer isn't always right

2012-02-12T21:01:00.000Z

Last week I went to get my hair cut (yes, sorry, this is a story about hair). I had thought long and hard about what I wanted. I researched, checked styles online, and bought a magazine so I could show my hairdresser exactly what I was after and there would be no confusion. I was determined I would not be spending that ridiculous amount of money on something I was not going to be happy with. I was even bold enough to ask for some changes to it at the end, which I have never ever had the courage to do before.

He did an excellent job. It was almost exactly what I had asked for, with some variations to account for my particular hair type. It was a very cute hair style that suited me. But I had a niggling doubt.

A few days later, that niggle was a certainty. It wasn't what I wanted.

However, it was what I had asked for.

Being English, the thought of going back and telling him I wasn't happy with it was horrifying. Especially since he had done a really good job of it. It wasn't his fault that what I'd asked for wasn't what I had actually wanted. But I knew what I wanted now, and I was prepared to pay for it (again).

This time I didn't show him a picture. I didn't point to anything specific. I said I wanted it much shorter after all and outlined the look I was going for. We had a conversation about it and I left it to him to apply his skills to actually implement it.

This time, I was much happier with the results. In fact, it was exactly what I wanted.

So what?

Of course this got me thinking about work. It's not just a lame excuse to write about girl stuff on a supposedly technical blog. It got me thinking about our customers.

Whoever our customers are, whether they're end users, internal business owners, external clients, or we work in a bank and have fifteen thousand layers of Business Analysts between us and Real People, whoever they are they want something from us. And in many places, we, the techies, have trained them to ask for more and more specific things, so they can be sure they're going to get what they really want. Remember that time Bob asked for that extra field on that report because it would make his job easier? Remember when Sandra wanted the workflow to be altered in a specific way? It's because they know that if they ask for something specific, the chances are better that it will make its way to the front of the work queue at some point, and when it comes out the other end it is more likely to be what they wanted.

Only it isn't, is it?

There's always another field to add, or another change to make. And your customer isn't quite satisfied, even though you did exactly what they asked for. And sometimes they don't tell you that they're not getting what they need from your system, because it's expensive or time consuming to get changes made.

The key to delivering something they really want, instead of something else that's merely adding to the weight of your code, is finding out what they're actually trying to achieve.

So Bob wants that extra field. That's easy enough. But when you ask him why he wants that extra field, turns out it's because the numbers in the reports he's getting at the moment aren't the ones he needs, or aren't quite correct. He's probably created a monstrous Excel spreadsheet into which he manually types half of the numbers from the reports it took you ages to develop, which munges them into something quite different, in order to get the real thing he wants. He's just missing this one small piece of information to get the final figure correct. It would save your company a lot of time/money/mis-typing errors if you completely re-wrote the reports Bob uses to give him exactly what he needs. Or if you gave him a tool to download CSV formatted raw data from the database.

It's not Bob's fault he can't ask for this, he doesn't know what we're capable of providing him. It's not our fault for not delivering it the first time round, we don't know what he does day-to-day. But having a conversation where we recognise where the knowledge lies (Bob knows what the output of his day job is presumably, and we know what's available and how we can provide it), and collaborating to come up with the least rubbish solution for everyone, is a step to providing that overused term, "business value".

We're not on different sides here, we all play for the same team - we want our jobs to be as painless as possible, which (should) ultimately provide better efficiency for our company. After all, we want the company to make money so they can pay us, right?

Caveat: Mileage may vary. Sometimes, with some customers, you really do need to tell them what they want.

Upcoming speaking events

2012-02-01T07:43:00.001Z

In theory, I am busy writing material for my upcoming speaking events, rather than writing terribly illuminating posts on my blog (see what I did there?). In actuality I am being lazy and have pretty much taken January off for a recharge.

In the spirit of doing something which ticks both the event-speaking and blogging boxes, this is a quick update on the conferences I'm confirmed for so far. Put the following dates in your diary - these are my first international solo speaking events:

7th March - QCon London - Concurrent Programming Using The Disruptor (sadly I can't stay for the whole conference as it clashes with the only holiday I had booked for 2012).
23rd May - GOTO Copenhagen - Concurrent Programming Using The Disruptor & War Stories.
25-26th May - GOTO Amsterdam - Concurrent Programming Using The Disruptor.

The presentation will be more of a user's guide to the Disruptor than anything we've done before. An hour isn't a lot of time to cover all the functionality everyone might want to see, so I'm still trying to work out the balance between giving an introduction/overview for those who haven't seen it before, and going into some of the cool features that have been added since I first started blogging about it. If there's anything you would particularly like to see covered, let me know - I'll put the most frequently requested things in there.

Ideally I'd run a workshop session at some point, but that will require quite a lot more preparation, so I'll only do that if there is interest in it (if someone wants to fly me somewhere interesting to do that so much the better!!).

Maybe I'll see you at one of these events?

Christmas decorations teach me a lesson about troubleshooting

2012-01-17T18:08:00.000Z

And now, after an absence of several weeks, you get to see how long it takes me to write some of these posts.

I was putting up the Christmas decorations one Saturday when my worst fear was realised¹ - one of my three strings of lights was not working.

The first two went up fine. The third lit up when I plugged it in, and in less than a second went out. Curses. This is not what I wanted, this was supposed to be a short exercise in making my tiny little flat look festive.

So I set about the tedious task of starting from the end closest to the plug and replacing every bulb, one by one, with a spare one to see if it magically lit up again. When it doesn't, you take the spare back out and replace it with the original bulb. I remember my parents going through this ritual every Christmas, the tediousness of this activity is more memorable than the fleeting joy of shinies.

While I was doing this, my mind was back on the job I'd been doing at work the previous week - battling an Internet Explorer 7 performance problem. We have automated performance tests which give us an indication of the load time for our application in Chrome and IE, and some time in the previous couple of weeks our IE performance had significantly degraded in the development code. Due to a number of too-boring-to-explain-here circumstances, the last known good revision was four days and nearly 250 revisions earlier than the first revision that showed the performance problem.

Since we couldn't see anything to indicate it was an environmental problem, the logical next step was to pinpoint the revision which caused the problem, so we could either fix it or get performance gains from somewhere else in the system.

The most obvious way to do this, given there were no obvious suspects, is with a binary search of the revisions. Our last known good revision was 081, our first poor performing one was 240. So the thing to do is to check revision 160, see if it falls on the poor or good performance side.

If 160 proves to be a poor performer, check revision 120....

...if 160 is fine, test revision 200...

...and keep splitting the revisions by half until you find the suspect.

So of course that's what I want to do with my stupid Christmas lights. I do not want to sequentially check each light bulb, that has a worst-case number-of-bulbs-tried = n, where n is the number of bulbs (probably a couple of hundred, although it felt like several thousand). So, in computer speak, O(n). The binary search algorithm is O(log n). At university, this Big Oh had no context for me. But when you've taken 10 minutes to get a quarter of the way through your Christmas lights, and you diagnosed your IE performance problems... well, actually it took days. But the point is, a binary search for the missing bulb would definitely have been a Good Thing.

I know you're dying to know if I tracked down the problem in Internet Explorer - I did. What's the worst case when you're doing a binary search? It's when the thing you're looking for is veeeery close to either your start point or your end point.

The revision number I was after was number 237. Sigh.

And my Christmas tree lights? Well, through the boredom I remembered that modern lights are in sections, so they have a sort of built-in binary search - well, limited segments will go dark if a single bulb is out - which allows you to narrow down your problem area. Since the whole string was out, I figured something else was probably wrong.

Turned out the plug had come out of the socket.

So:
Lesson 1: Theoretical computer science does have a place when you care about how long something takes. When it's you feeling the pain, you'll do anything to make it stop.

Lesson 2: When diagnosing a problem you will always biased towards what you think it is, in the face of actual evidence. I was afraid I would have to search the whole set of lights for a blown bulb, so that's the problem I was looking for when the lights failed. In actual fact it was a problem with a much simpler solution.

¹ - OK, "worst fear" in this very limited context only - it's not like I lie awake at night in July afraid that one of the bulbs on my Christmas lights has blown.

Video: Why we shouldn't target women

2011-12-22T15:53:00.000Z

If you have a Parleys subscription, you can watch the whole "Why we shouldn't target women" panel from Devoxx 2011 a month or so ago. Watch me attempt to monopolise the whole panel as if it was my idea or something...

How to make your CV Not Suck

2011-12-21T17:46:00.002Z

When you're applying for a job at LMAX, your CV (or résumé, for our American readers) usually comes through me and I decide whether to call you for a technical phone screen.

I'm going to let you into a secret.

I'm going to tell you the criteria I use when judging your CV.

Now, you could say this is a foolish thing for me to do, because now when you apply you'll be "cheating" and writing your CV to pass these guidelines.

Good.

LMAX isn't the only company that's going to judge your CV based on these criteria. I firmly believe that an increase in quality of the CVs in our industry can only be A Good Thing. An increase in the quality of your CV is definitely A Good Thing for you.

Even more importantly, if I get CVs that do not pass these basic criteria, now I know you either don't read the LMAX blogs (shame on you), or you're not able to follow simple instructions (bodes poorly for your ability to learn within the company).

The thing that you have to keep in mind when you're writing your CV is that the reader really does spend less than a minute reading it. It's not fair, true. But it's the way humans are. I'm not in HR or recruitment, I have a proper job as a software developer, and I need to get back to that as soon as I can. When I get CVs in batches of up to 12, as I regularly do, I'm not free to spend more than 10 minutes going through all of them.

The Easy Stuff
You must be able to spell
You really must. There are things called Spell Checkers and they are amazing. Some of these new-fangled pieces of software even show you your errors in this cool squiggly red underline in your document.

I'm reading your CV in Open Office, and if I see red squigglies under words that aren't technologies or acronyms I'm going to wonder how good your attention to detail is.

You must use capital letters in the appropriate places
It's traditional to start a sentence with a capital. It's also traditional to use a capital "I" not "i" when referring to oneself. We're not 14 years old, we're not writing an SMS to our mates. We're applying for a proper job paying proper money.

Correct grammar is appreciated
Whether you're a native English-speaker or not, you need to get someone else who is a native English-speaker to check the prose in your CV to see if it scans correctly. For me, it's not about being prejudiced against you because you're not a natural author, it's a) attention to detail again and b) your ability to make yourself understood. If your sentence construction, choice of words or simple comma placement is off, I'll have to read that sentence a couple of times to parse it and it's going to trip me up and ruin my flow. I want to get a good feel for you from reading your CV, so if I stumble a few times I'm not going to feel like I connected with you.

Harder and fluffier
I don't care which versions of Spring you've worked with
I know you need a checklist of technologies on your CV so it gets past the non-technical recruitment agents and get picked up via automated searches. This is a bigger problem with our industry than one I want to tackle right now. So I'll let you off having buzzword bingo on your CV. However, your CV needs to be more than just a list of technologies you have used vaguely, or perhaps once read about.

It's useful to me if a) you put the technology check list in a single place on your CV, b) you give an indication of your level of proficiency in that technology (novice/competent/master) or length of time you've used it in a commercial environment, and c) you organise them in some useful fashion - preferably the ones that are appropriate to the job you're applying for near the top, or at least those you're happiest with at the top. Alternatively put the checklist of technologies next to the role you used them in.

Often I will completely ignore this section because I'm more interested in your ability to learn and your passion for what you do.

I want to know about your passions
In the old days I used to fast forward to your hobbies and interests, but these days we're encouraged not to put those on the CV in case you're judged against them. Which seems like political correctness gone crazy, but then when you think about it you can infer a lot about a person from their hobbies and interests, and therefore you could be pre-judging them based on some criteria that is not at all associated with their ability to do the job. For example, if they have hobbies that take them all over England I might infer they have a car and can drive - OK, it's a dumb example, but you get the idea.

These days, given that I'm trying to find great team members to work with me at LMAX, I'm looking for things like: your blog; any contributions to open source software; your involvement in a Java User Group (or other extra-curricular activity). I'm not going to discard you if you don't have any of these things, but if you do it's definitely extra brownie points for you.

I want to know if you worship at the altar of technology, or if you're business-value driven
Either of these things is fine - we need people who are very business-focussed and people who are rabid about technology, as well as all those in between, to build a good team. Another axis of interest is people/process - are you passionate about people, about building a good team, about helping them to deliver?

Getting a feel for where you sit on these axes is not for me to discard you, but if you look like you're strongly in one of these camps and I feel like we need a team member to really push that area, then you stand a much better chance of getting a phone interview.

I'll get an indication of where you are by the way you talk about your roles and your achievements. This does not help me:

Senior Developer on a web administration application. Product was implemented using JavaScript, HTML, Spring, Hibernate, JMS, and MySQL.

This is much more useful:

I was part of a team of four developers implementing a web based administration application, commissioned to enable internal users to update the settings of our reporting tool. This saved the support staff approximately 4 hours every week, as they no longer needed to manually update the database. We used agile techniques such as daily standups and weekly iterations in order to provide quick feedback to the business.

(I made both of those up, by the way, before anyone starts trying to sue me for stealing something off their CV).

Here I can see:

The size of the team, and your ability to work in a team
You understood the business need you were trying to fulfill
You have worked in an agile environment and at least pay lip service to why you were working that way.

I don't really care about the specific technologies you used, the fact that you mentioned web-based and database gives me enough of a feel.

Sometimes prospective employers really do stalk you
Personally I think claims that prospective employers will check every facet of your web presence are somewhat over-exaggerated. If I barely have 60 seconds to read your CV, I'm not going to check you out on Facebook, my life is too short.

However, if you claim to have written a book I will look it up on Amazon. If you have a publication or example code, I will glance at those. If you've worked for a company I've worked for in the past, I'll look you up on LinkedIn to see if we have any common connections (or worse, to see if I should remember you and simply don't). I'll also use LinkedIn if your CV is not screaming yes or no, to see if there's an extra dimension in your profile which will tip me one way or the other.

So be aware of your web presence, particularly something that is aimed at your professional image like LinkedIn, and make sure it represents you the way you want it to.

In Conclusion

This post might be simply a good way to increase my own workload - every CV I get from now on may be an automatic pass, and then I have to call all of you before I can start weeding you out.

But I don't mind too much about that. I get concerned sometimes that good people are not getting the interviews they deserve, not just at LMAX but across the industry, because they get almost no good CV advice. Frequently the people who are the first to read CVs are agencies who are not technologists. By all means, have words on there that will make your CV appear on their search results. But you need to put something on there for me, a real developer, because strings of keywords tell me nothing about you.

If I can improve the quality of just one person's CV with this post, I'm happy. If I have given you that first step towards that job you really want, then that's even better.

Video of our JAX London session

2011-12-04T12:28:00.001Z

At JAX London Mike and I presented "Understanding the Disruptor - A Beginner's Guide to Hardcore Concurrency". This is the session we initially previewed to the London Java Community a few weeks earlier. The content is the same, but the feel of the presentation was quite different to us - the venue for the LJC event was more intimate, and it was easier to interact with the audience. At JAX, we were up on stage, which was pretty cool actually, but meant that it felt more like a lecture and it was less easy to connect with the audience.

We received some really great feedback on this presentation, and it was brilliant to see a lot of the speakers from JAX there watching us.

Interview by the Oracle Technology Network at Devoxx

2011-12-04T12:05:00.001Z

Tori Wieldt from the Oracle Technology Network interviewed me at Devoxx. Because I was there to be on the Why We Shouldn't Target Women panel, the interview is just another platform for me to air my views on this subject again.

Yes, I am actually wearing pink....

London Java Community Open Conference

2011-11-28T20:37:00.001Z

Saturday was, hopefully, my last conference of the year. My lucky readers should start to see some posts which are not simply me gushing about another opportunity to hang out with awesome people and learn about interesting "stuff".

Who wants to propose a session?

In many ways the London Java Community Open Conference was my favourite one so far, and not just because it's near home and I helped to organise it. One of the awesome things about both Java One and Devoxx was the opportunity to travel, to see new places and to meet people you might not meet in London. The scale, and the opportunities to meet key players in the Java world, were the things I probably appreciated the most from both of those conferences. And you can tell from my posts I really enjoyed them.

But the LJC conference was probably perfect as my last one for 2011:

"How do you spell 'lightning'?"

Being on home turf with awesome people who have really helped drag me kicking and screaming into the conference scene really brought home to me what an amazing year this has been. This time last year, I felt I barely had the credentials to be a behind-the-scenes organiser for the LJC, and I didn't attend last year's conference because I wasn't sure how much I would get out of it. This year, I'm at the conference giving two sessions, having made my international début already.
With 120 people you feel like you can talk to everyone at some point if you want to. I don't think I managed that, but I probably chatted in one way or another with maybe half the attendees. The great thing about this is you see the wide variety of things people are working on - the technologies, the business problems, the team and company sizes, the methodologies. It's eye-opening and quite exciting.
It seemed that a small, open conference like this drives content based on relevance. We had no vendor pitches, although John was contractually obliged to mention Atlassian at least once every half hour (but as they paid for the beer, this was only fair). People vote with their feet, and attend the sessions that they will get the most out of. I liked this format a lot.
I presented alone for the first time, not hiding behind Mike or Martin. I found this surprisingly liberating. I love working with those guys, but without them providing a safety net I actually found my confidence increasing as I realised I was perfectly capable of answering things I would probably have let them field.
My second session was more workshop-like, and I wanted the audience to guide what we covered. I thought it went really well, I loved letting the audience guide it, and I enjoyed giving it.
I was honoured (and terrified) to be asked to be part of a Meet the Experts panel with people who actually know what they're talking about. I was very very pleased to get away with not being asked any questions about being a girl or the length of my skirt. We had a great discussion around writing high performance code, about different technologies and their applicability, and about the future of Java and JVM-based languages.
I loved the venue. The rooms were a nice range of sizes, all with projectors of course, but also whiteboard space and flip charts. It looked like a 1960s version of the future - all shiny white surfaces and curving lines. But it felt like a space to create and innovate in.
Mike's Hacking the Open JDK session in the morning was excellent. Again, this was another example of a workshop format working really well. He gave some good background to compilers in general, and a good walk through of some of the code that's there at the moment. He was happy to share stuff he'd learnt the hard way, and it made me want to get more involved in that side of things.
The food was awesome.

Clearly people haven't had enough coffee yet.

My sessions were User's Guides to the Disruptor - a beginner's and a more advanced one. The beginner's was an updated summary of the Disruptor stuff already covered in this blog - the ring buffer, writing to and reading from it, and configuration. The second session covered more advanced ideas: you don't need a ring buffer any more; cache lines and false sharing; worker pools; aggregate event handlers. This session was a lot less prepared and more collaborative, and I loved giving it. Maybe that's my teacher-genetics coming out.

The aim of both sessions was to give people an idea of how to actually use the Disruptor - developers are definitely interested in how and why it works, but we've been evangelising a lot and now there are very sensible questions being asked about how to get it to do various things. I'd like to run some more of these sessions in future, and to add more material to the blog.

And finally, a proper meal before more beer.

Back to the conference. Were there any downsides? Personally I had none. If I had to suggest an improvement for next year, it's that we would like to see more novice speakers presenting. The LJC has always been about nurturing this talent, and a small conference like this one with a friendly audience, many of whom you may already know, is a great place to practice. The lightning talks showed the great variety (and abilities) of our members, it would be nice to expand this to full sessions. As I found, filling a 30 minute session is not anywhere near as hard as you think!

I'm really looking forward to next year's LJC conference, and I'm totally buzzing from the positive vibe from this year's.

The LJC Associates modelling their lovely new t-shirts. Mine fits!

Why We Shouldn't Target Women

2011-11-20T07:07:00.001Z

I'm back from Devoxx, having had lots of food for thought. In particular, my panel on Why We Shouldn't Target Women generated a lot of discussion and I'm still trying to process it all.

Martijn Verburg; Regina ten Bruggencate; Trisha Gee; Antonio Goncalves; Claude Falguière; Kim Ross

The panel went really well, we got decent interaction from the audience, and of course my fellow panel members were awesome. I managed to restrain myself from using the opportunity as my own personal soap box and allowed other people to speak occasionally. Sadly the only male on the panel stole the show somewhat, so Antonio won't be invited in future... Actually in seriousness, it was great to have a guy on the panel to present his point of view. It was interesting that he's a father, highlighting that parenting issues are not the same as women's issues, and conflating those two concerns hurts both genders. But Antonio's hair is far too shiny and pretty and he's funnier than I am, so I'm not standing next to him again.

I'd love to make a note of all the issues discussed during the hour, but I'll be honest, I was too busy trying not to fall over in my girly six-inch stiletto boots to remember anything that happened. The video will hopefully be available on Parleys some time in the future, so I will link to it when it's there if it's not too horribly embarrassing.

Someone let me have the microphone again...

One question that came up more than once throughout the week was: IT/programming is not the only industry with a lack of women, why should we care? Maybe it's just natural?

I think we need to be very careful before writing off such an imbalance as "natural". We need to make sure first that we aren't discriminating against groups, consciously or through some unnoticed system bias. And for me, the thing is that we notice that women aren't well represented in technical roles, but we don't necessarily notice the other groups of people who might be being put off for similar (or maybe totally different) reasons. We can't so easily tell if gays, jews, parents, shy people, folks from poor backgrounds or any other less distinguishable sets of people are finding it hard to make it as a programmer.

We can see the figures for females. In the UK in 2008:

44.7% of people taking ICT (Information and Communications Technology) at GCSE (age 14-16) are girls. As in many other subjects these days, the girls get better results than the boys.
38.6% of kids taking ICT at A Level (16-18) are girls. Only 9.6% of Computing students are girls. Again, girls outperform the boys in both subjects.
19.4% of those studying Computer Science at university are women. This is down from 24% in 2003.
Through a not-very-scientific poll of the members of the London Java Community, it looks like approximately 15% of techies in industry are women. Interestingly, some companies have a much higher proportion than others, but I think that's something to explore another time.

The thing that worries me about these figures are a) the "pipeline" hints at a drop-off in interest in the subject, not a lack of ability, since the girls are doing well tech subjects but choose not to pursue them and b) the numbers are declining in some areas, specifically university applications. I've read studies that show the percentage of those in technical jobs who are women has been steadily declining since the 80s, but it's difficult to get specific figures, especially as I'm particularly interested in programming / technical roles rather than just the percentage of women "in IT".

If the numbers are declining, that seems like a smell to me. Not only do we have some sort of image problem which puts people like those who have two X chromosomes off from entering our industry, we're driving them away when they get here. And I don't believe that's because women find they're not good at it.

Other industries have been successful at attracting a higher proportion of women - for example, in 1950, only 15% of accountants were women. By 1985 half of all accounting majors were women, and by 1990 the majority of the workforce was female. It would be nice to think we could learn something from our friends in the Maths world. After all, the skills are not dissimilar. But they have a slight advantage over us - in many countries all children are required to study maths until age 16. However, there are very few 16-year-olds who have any programming experience at all. Either we need to accept that we're going to have to hire kids with other degrees and train them to be programmers, or we're going to have to do some serious outreach to interest kids in programming and technology long before they start to make their exam choices. In the UK, they need to choose their GCSE subjects at 14, which means we probably need to be targeting kids as young as 10 or 11. That's not inconceivable, when you think about it - how many of us were programming in BASIC aged eight or nine? Could we not teach kids to write an iPhone app or a Facebook app instead? I was very pleased to hear someone in our audience was teaching their daughter to program. At an even younger age, the least you can do is buy your kids Lego - I'm sure that exercises the right parts of the brain.

The point is, that I don't think we can conclude that it's "natural" for girls to not be interested in programming. The first programmer was a woman, and during the war and even into the '60s many programmers were women. I think that if we can work with schools to provide some tutoring in computing at a younger age we might be able to attract kids who wouldn't have thought about programming as a career choice before. Some of these may be women, some will not. That's fine, diversity is our ultimate goal.

Which leads me onto another point - special treatment of women. I've said it before I'm sure - I think singling out women to attempt to increase their numbers does more harm than good, for a number of reasons:

It makes women think that there must be something wrong in our industry if women need to be treated differently, or mentored differently, or need additional training to get by. Or it makes us think that we really aren't as good as our male counterparts because we're being given special treatment.
It builds up resentment amongst our male colleagues, so they soon begin to wonder if we're doing our job because we're good at it, or if we got there because we got lots more help, or because we're there to tick some sort of box
It's not solving the problem of lack of overall diversity - where are the programs for people who went to the wrong schools, for those who didn't think about programming as a career, for a million other special interest groups that exist out there?

Some of the ideas that imply special treatment are things like: all women events (you should know by now how I feel about those); free entry to conferences for women; higher pay for women at certain companies. Although I would benefit from all of these things, I hate them. I feel like I'm being compensated for this terrible affliction of being born female.

So, what can we do?

Reach out to those you want speaking at your conferences. This might include women, it might include people from other "minorities", or it might just be awesome people that you want there making your conference look good.
Use these people for marketing and role models - it is indeed possible that if you have some female faces on your conference site and posters, you might attract more women attendees. Actually, if you have more women role models you might attract more men, but hey, it's all about diversity.
Buy your kids Lego and teach them programming.
Treat women in your company like people the same as anyone else. We were asked about how to deal with a younger female boss. Kim's answer was perfect: "Like an older, male boss".
Get involved in mentoring programmes, not just for women but for people of all ages - kids at school, undergraduates, or people who are already in the industry and want to take that next step, for example to speaking at conferences or writing or leading teams or becoming CTO.

Since the panel I've been pointed, numerous times, to this excellent article which talks about racism, sexism, and meritocracies. I particularly like the line "Explicit diversity programs have the solution exactly backwards". Well worth a read.

Devoxx: The story so far

2011-11-16T18:16:00.001Z

Stephan wearing the Brazilian flag at the opening keynote

European conferences are different (and cool) because you get to hear even more languages spoken than you usually do in London (apparently the most diverse city in the world for spoken languages). I think the idea of a Paris Devoxx with 75% of the talks in French is brilliant - I'm always banging on about diversity, we shouldn't expect developers to learn in English only.
Really great to meet up with some of the people I met at Java One and am starting to feel more a part of the global community.
Seems to me there are slightly more women here than at the other conferences I've been to, and not just because Regina and I pulled together four women for a panel on women technologists. And once again, a lot of guys asking why this is, because they want things to change.
A highlight was seeing my namesake, AutoTrish, up on a cinema-sized screen in front of hundreds of people at Dave Farley's Continuous Delivery presentation.
Building on from my twitter revelation at JAX London, I've found twitter very useful here for messaging people I want to meet up with, but also for chatting to new people and making new friends. It's not quite as intimate as JAX London though because there are billions more people here, so the chances of actually bumping into the twitter friends is much lower.
Have had lots of interesting conversations with people about the Open JDK, which I guess is the logical extension of the interesting conversations I had about the JCP In San Francisco.
A community event like this is different to an event like Java One, because a single organisation isn't calling the shots. It's interesting (and great) that Oracle and Google can both be here talking about the cool stuff they're up to.

The Diabolical Developer

Conferences are clearly something that appeal to me - I love meeting people and chatting about interesting and (sometimes) intelligent things; I love learning stuff and indexing it away, possibly for future references; I love hanging out with people like the LJC guys (Ben, Martijn and John); I love kicking around ideas of what more we can do at LMAX with our lot (Mike, Dave, Dali).

Dave's Continuous Delivery

I'm really looking forward to my panel this afternoon, I'm going to be ranting about how we target women for tech jobs. Should be fun.

Nice 'tash!

Shameless plug: Mike and Dali are raising money for men's health with their rather awesome 'tashes. It took guts to stand up on stage and present with that handlebar, please give a penny or two:

JAX London - I learn stuff and meet people

2011-11-15T18:00:00.000Z

A couple of weeks ago, I was at JAX London along with a number of the London Java Community regulars (Martijn/Ben/John/Sandro/Simon/Zoe I'm looking at you....)

My purpose for attending was largely to present the Hardcore Concurrency for Beginners talk that Mike and I debuted at an LJC event a few weeks back. Almost as important was catching up with the aforementioned LJCers and meeting with as many people as would talk to me. After the disappointment of the sessions at Java One, sitting in a room being talked at was quite low down on my list of priorities.Sometimes it's nice to be wrong.

The sessions at JAX were of a very high standard, and I learnt something from every one. I was pleasantly surprised by the calibre of international speakers that were there, and the sessions seemed to be pitched right for me personally, which was nice.

Downsides:

I'm going to cover these first because I like to end on a high note. Firstly, although I was interested in the Open JDK session at the community night, it was really on way too late (and after too much beer - i.e. more than none) to get the most out of it.
It's a bit of a shame that our session was the last presentation on the final day, by that time people's brains are fried and we didn't get as many questions, or as much interaction, as we usually would. Maybe that's because everyone understood and agreed with us. But we did get great feedback so I could be scraping the barrel for things to complain about.

The following sections outline the main takeaway points for me.

Software Craftsmanship / Design

Sandro did a great job emphasising that Software Craftsmanship is about professionalism, not beauty. We should be doing the right thing because we want to, because it makes everyone's lives easier in the long run, and because it is the right thing to do, not because some process dictates that we do it. The other thing that really struck me was how having a craftsman's mindset leads to us taking ownership of our career and investing in it. He also challenged us to stop being miserable and negative. If we're happy, we'll attract more (presumably happy) people into our circle.

Jason Gorman's Slow and Dirty presentation showed that ignoring quality slows down delivery not just in the long run, in terms of maintainability, but also in the short run - a TDD exercise of approximately 30 minutes took less time to get right when done in a test driven fashion, despite that fact that we all still think writing tests takes too much time. He pointed out that Twitter and Facebook are statistical aberrations - not every startup can afford to assume they will be bought out of their scalability problems. There was lots of interesting stuff here about quality, which was pretty inspiring at the time but in retrospect, as a team that already does Test Driven Development almost to the extreme, I wonder what's next for us to improve our quality even further.
Simon Ritter's keynote stated that code should be a joy to read, not simply easy to read, and Adam Bien's presentation talking about simplifying code: thinking about design, and not getting bogged down in unnecessary design patterns in order to implement something simple.

Concurrency / Parallelism / Performance
Russel Winder's session around message passing had me thinking. It was particularly interesting to see him say things that are possibly the opposite of what we (the LMAX/Disruptor types) are preaching. For example, that programmers shouldn't care about the low-level details; that we should be using models (i.e. abstraction) to deal with parallelism; that you should let the JVM deal with thread management. However, I think he's fundamentally coming from the same place as us: "concurrency" in the past was not a good model, it was designed for old hardware that was trying to run multiple processes on a single core. With multi-core systems you need to be running code in parallel instead.

Dan Hardiker's performance testing presentation was another one that reinforced that testing first, finding what the real performance is, profiling and then targeted experimentation are all fundamental to getting good performance. There was a lot of good advice to how to write good performance tests too.
Another point from Simon Ritter's keynote reiterated that the performance free lunch was over, and we need to get better at writing parallel code.

Workshops
Both the Open JDK session and Ben and Martijn's "Spring cleaning your code base with Java 7" had me attempting to do things with my mac I never intended to do (i.e. write code). Thanks to Ben and Martijn's patience, I finally got IntelliJ playing nicely on the mac with Java 7, which was a challenge but I'm pretty pleased I've achieved it. The Open JDK one was not as successful for me personally, but I got a good feel for the process of building it (i.e. it's hard and it takes a very long time).

Other great stuff:

The keynote by James Governor from Redmonk was really thought-provoking. So thought-provoking I wrote no notes and can't remember any of it.
As last time, the Community night was really great. I met new people and I hung out with some old favourites. Dear God I must stop drinking with those guys. Hotel bars are particularly awful for losing track of time.
I heard about the Java 7+ features enough times from various people to be able to give an overview of the release plan to my geek friends in the pub on Friday (hey, they asked).
I learnt how to use twitter to bridge that gap between me and other attendees, and made new friends without having to do the scary thing of approaching strangers.
The lunches we rather good.
Going to a conference 20 minutes from home is a bonus. Nice to meet other London devs as well as the European ones too.
To me, it seems as if the relevance of the JCP is starting to seep out into the real(er) world.
The tables for laptops at the front of the rooms was an awesome idea. For a start, it encouraged people to get into the room early to get one of those seats.

I had a great time at the conference, I learnt stuff and met people, which is all I really want.

For once, the photos aren't mine. Images courtesy of JAX London.

A NYSE Product Manager and an LMAX Developer walk into a low latency trading seminar...

2011-11-09T08:16:00.000Z

"What... exactly... were you guys looking to get out of today's event? Because..."

"Because we're girls?"

"Um... yes..."

Kim impetuously opts for The Truth: "We're here to meet men."

Our interrogator looks round dubiously.

"No, really, why are you here?"

Phew. My reputation is intact¹

Kim eloquently describes what her situation is as Product Manager and the criteria she's measuring third party products against. I explain how LMAX aims to be the fastest retail exchange in the world, and therefore low latency is a tiny bit important to us. I talk about how we created The Disruptor on our path to achieve that goal. The guys gathered around us look a little... shell-shocked.

I'm exaggerating for Dramatic Effect. Before anyone starts getting upset about the only two girls at the event who weren't staff or hospitality being singled out, you have to give the guys credit. They approached us, engaged us in conversation, and had a very serious question about what we were after, and was there anything the vendor could do to either improve their offering or to make their sales pitch more appealing.

And don't get me wrong - it's brilliant being different in a situation like that, if people are brave / foolish / drunk enough to talk to you. It beats the hell out of sitting in a corner trying to get up the nerve to speak to Strangers (been there, done that).

But it is quite a contrast, even from the Java events (JAX London, Java One). There, I was in a select group of people of the female persuasion. But I was also part of a community, and treated as A Developer. At very specialised events (low latency, high performance in particular) diversity is almost non-existent. You can count the number of women on one hand (if you can see any at all) and even the developers wear suits (poor bastards). However it would probably be better if you could hide your surprise at hearing technical terminology coming out of a woman's mouth.

But... I kinda like it. Yes, I'm an alien. Yes, I'm special. But if it means you make the extra effort to speak to me, I can live with that.

¹ "Extra extra, read all about it! Blogger And International Conference Speaker Only Does It To Meet Boys!" Not quite Jordan Stalks Rugby Ace For Sperm Donor. Which I really did see this morning.

EDIT: oh yes, and of course I forgot to plug my panel at Devoxx next week: "Why we shouldn't target women"

On The Similarities Between Girls And Aliens

2011-10-28T15:52:00.003+01:00

I discovered, through the power of the search words that lead to my blog, that there was an incident at JavaOne that once again opens the can of worms that is Sexism In IT.

This Makes Me Sad. I had a really positive experience at JavaOne. In fact, I would say it was the one conference I've been to in the last 12 months where I felt like my gender wasn't a problem - I even got away with wearing hotpants (tweed is business-casual, right??) without being mistaken for anything other than a developer.

I know incidents like this cause a lot of tension, and I want to explore why. Get ready for some gross generalisations: women get upset because they feel they're being marginalised or treated differently; men get upset because they think we're being over-sensitive, especially when the cause is something unintentional. I sometimes wonder, as I'm sure other people do, if perhaps picking up every incident harms our cause more than advancing it. But then I feel that the unconscious stuff is exactly the stuff that needs to be pointed out - if you don't realise you're causing a problem, you can't change your behaviour.

So what I wanted to do was... well, what I wanted to do was not rant about gender (again) and be a good little non-gendered programmer. But then I thought that spreading a bit of understanding might be A Good Thing. After all, we're all about continuous improvement, right?

I'm sure many people have been one of a minority at some point in their lives (brace yourselves for a litany of stereotyping) - the only man at their daughter's dance recital; the only white guy on a basketball team; the only straight guy in a gay bar (accidents happen!); the only girl on the development team... Speaking for myself, in those situations I'm not actually looking for things which prove that I'm Not One Of Them. I'm sub-consciously seeking reassurance that I'm not an alien, a freak of nature, the odd one out.

I've been in mostly male environments for the last 16 years - this is the norm for me, it's my life. It freaks me out if I'm surrounded by women actually. What's jarring and uncomfortable is when the difference of your gender becomes apparent: when all the t-shirts are boy-shaped and boy-sized; when someone makes a joke about "women"; when someone addresses the room with "Gentlemen" - or worse, they try and make up for it: "Gentlemen. Oh, and Ladies. Well, Lady <nervous smile>". Thanks, that doesn't make me feel like an outsider at all.

Something else that really highlights the difference in genders is when you have plenty of women at the conference... but they're not the attendees. They're manning the booths (marketing/sales or just plain hired "help"), they're taking tickets, they're dishing out the lunches. In these cases, it becomes normal to assume that "girl" = "staff". Not guest. Not equal.

TradeTech was one of the worst examples of this that I've experienced. Those (wo)manning the booths had been chosen for their aesthetics not their knowledge. There was even entertainment consisting of scantily clad stilt-walkers - at a financial conference! I made the mistake of turning up in a skirt - for those who know my dress sense, it was not one of my arse-length ones, it was just above my knees - and everyone assumed I was selling something. I had a job to persuade them that I had actually paid for my ticket.

So. What am I trying to get at?

We're not trying to make you uncomfortable when we point out tiny accidental possibly maybe sexist or sexist-seeming comments/incidents. We're trying to stamp out behaviour that can subconsciously be pushing women (or other minorities/groups) out of our industry. We like it here, we want to stay, and we want others to join us.
It's very easy to alienate people who are not 100% comfortable in your environment. Every time I see t-shirts in boys size only I'm reminded I'm Not One Of You.

...and what can we do?

Well, the t-shirts is an easy one. So easy, and so stupid, you might not think it's worthwhile. Especially as people like me don't even want your free t-shirt. But I want to feel like you wanted me to want it. Please stock some skinny-fit tees in multiple sizes, and stock smalls and mediums of the normal shape. There are guys who would like this too. Even if you can't get rid of your skinny tees, it will do wonders for your image.
Never assume your audience is all male. Never even assume it's "mostly" male. If your sister/girlfriend/mother/daughter might frown at something you're saying, don't say it. You'll look like an idiot. You can assume your audience is all technical, and joke about managers, or is all Java, and take the mickey out of C#. Don't draw arbitrary battle lines based on gender/race/origin - any jokes should make all the audience feel included, not like specific individuals are excluded.
There's already been a lot said elsewhere about encouraging women speakers at events. I'm totally behind this, but it's a fine line because I'm also totally against positive discrimination. For the purposes of this blog, I would just say make sure you have some women on your speakers list, in the same way you would probably ensure you have a Java 7 talk, or a talk on the shiniest new technology, or other miscellaneous checkboxes you need to tick in order to make your conference a success.
Not sure what to suggest around many of the girls there being staff... I guess something simple like clear uniforms would stop people assuming female delegates are there to hand out lunch. And making sure that your staff/helpers/organisers are of both genders too.

If you're interested in this whole topic, or want to tell me I'm wrong to my face, come along my panel at Devoxx - Why We Shouldn't Target Women.

Mike and I debut our new Disruptor presentation

2011-10-21T10:41:00.001+01:00

Last Tuesday Mike and I unveiled our brand shiny new presentation: Understanding the Disruptor, a Beginner's Guide to Hardcore Concurrency. This was a preview of the talk we'll be doing at JAX London on the 2nd November.

A video of the session is available, as are the slides. I promise not to say "so" anywhere near as many times when I repeat my performance at JAX (is there anything more painful than watching yourself on video?).

I thought the session went really really well. We got some great questions at the end, we had an audience that was engaged, and I was dead pleased we didn't lose anyone with the assembly language. We had some very valuable feedback afterwards too.

As well as our presentation, there were three great lightning talks:

Somay Nakhal on Java Thread States

Ged Byrne on the shiny new LJC Book Club

Oracle Coherence 3.5

Beautiful Software

Peter Lawrey on Common Java Misconceptions

Tackling Folklore

mandatory

All of us (me, Mike and the lightning talk presenters) got such a great response it has encouraged us at the LJC to try and push for more real developers presenting their experiences. We have a lot of great presentations from vendors, but what's more applicable to Java guys and girls across the board is other developers sharing the problems they're trying to solve and how they go about that process.

I'm very much looking forward to presenting this again at JAX.

JavaOne 2011: Roundup

2011-10-12T16:02:00.000+01:00

Having been back in London for a few days I've had some time to digest the madness that was last week.

My lasting impression of JavaOne is almost entirely positive. Granted, it was my first major conference, so maybe I'm just not jaded yet. But let me tell you what I loved about it (yes, I did cover some of these in my last post):

First and foremost, the people. I don't remember meeting a single grumpy person. Everyone I spoke to was there to get the most out of the experience, regardless of how many times they'd been previously. In my experience, techies are not conditioned to be socially comfortable, yet introductions were made and the conversations flowed easily.
Of course it wasn't just the attendees who were friendly, the staff and organisers were approachable and helpful, and it was nice to have people hanging around to direct you.
One of the (few) advantages of having the event over multiple hotels was the outdoor space between them. It's unfortunate that it rained, but I really liked being able to hang around outside. I especially liked that they had provided power points for your laptop, so you didn't have to be cooped up indoors to update your blog. I also thought that having to walk between the venues was good exercise, given I didn't make it to the gym last week. However I can see why people want to move the event back to one central location.

I personally found the sessions less useful than the networking. I mostly attended the high-performance / concurrency sessions, but I probably should have been to ones about things I didn't know (e.g. other JVM languages). My favourite session was Martijn's Diabolical Developer session, but then I'm a fan of stand-up comedy.
Another favourite was the Java Posse live podcast. I'm ashamed to admit that I've never listened to one before (my excuse: I don't listen to podcasts at all because I don't have a long commute to work, which would be the ideal time). I thought it was great how everyone felt like a part of the Java Posse and not a passive audience.

I really felt that Oracle was trying its best to invoke the spirit of community. Maybe that's because when I wasn't in sessions or having random conversations, I was in Java User Group or Java Community Process events. It seems pretty clear to me that the inclusion of SouJava and the London Java Community in the JCP EC has shaken things up a bit. But then, I would say that - I'm biased. But the vibe I was getting across the whole conference was that having the community involved in this key decision-making organisation is a step forward. I would even go so far as to claim that it inspired a number of other players to seriously consider getting on board rather than complaining from the sidelines.

On a related note, I really enjoyed the final keynote on community. To me, that was an indication that Oracle takes our participation very seriously. I liked that it was split into a lot of different interviews and panels, all quite short, which showcased the variety of the Java platform community. I came out of that feeling pretty warm and fluffy about the future of our technology, and proud to be an active part of it.

Stuff I was not so bothered about:

Vendor keynotes. Pretty dull to be honest. I understand why they had them but after the first one I didn't turn up to any more.
The other bad points I already mentioned in the last post.

Personal highlights:

Picking up the Duke's Choice Award (video - note: only seems to work in Firefox for me) for the Disruptor. Yeah yeah, I'll shut up about it at some point, let me have my moment of glory.
Co-presenting a session on the Disruptor with Martin. He invited me to stand up with him when we realised I could go to the event, and I was terrified of the thought. So I did it.
Meeting and being interviewed by the JDuchess ladies. The video doesn't seem to be available, so maybe I was rubbish, but it was a cool thing for me all the same.
Talking about the Disruptor for the Java Spotlight Podcast and the Oracle news guys (again, I can't find the content for this yet).

I had a really brilliant time, and would love to repeat the experience again as soon as possible!

JavaOne: Initial Observations

2011-10-04T23:31:00.000+01:00

So I've been at JavaOne for the better part of three days, it's time to record some of my observations so far:

The wireless access is rubbish.
<Gross generalisation> technical people are not natural public speakers. Makes me feel better about the presentations I'm going to be giving (see A Beginner's Guide to Hardcore Concurrency).
The sessions are less useful than getting out and chatting. I've had a really excellent time, I've met: people from other Java User Groups; the Duchess girls; other Duke Award winners; the Azul guys; guys (well, girls) from O'Reilly books; JCP members and many random and awesome people.
Everyone thinks that Large is an acceptable default t-shirt size (it's not). Vendors - if you're really serious about appealing to The Other Gender you need to stock XS, if not actual skinny tees.
If you're running a conference, you should probably have your projection screens above the height of the audience members' heads
People at JavaOne are dead friendly. I've ended up in a lot of conversations just by virtue of standing alone for longer than 30 seconds. It is noticeably easier to talk to people here than at the conferences I've been attending in London. Not sure if that's a location thing or a domain thing.
Socialising in London is great practice for this sort of event. I am capable of taking advantage of free drink and still maintaining a conversation and staying upright in 6 inch heels.
I miss American breakfasts. I've been gorging myself on pancakes, biscuits and gravy, and eggs benedict. I'll be calling my personal trainer as soon as I return.
Haven't seen anything to contradict my view that San Francisco is not the Brit's typical view of California - the weather is rubbish. London has been hotter and sunnier this week.
Sharing an apartment with your CTO is not as weird as you might think. Especially if you relegate him to the closet (no, that's not a euphemism).
It's difficult to remember to Tweet or blog when you're totally engrossed in conversations with people.

Here's a photo of me representing LMAX as I pick up the Duke Award we won for the Disruptor:

(Thanks to Martijn for taking the photo).

I was grabbed for an interview which should be available (un-edited - erk!) on java.net at some point, I'll post it when it's available (if it's not rubbish).

JavaOne 2011

2011-09-27T18:01:00.001+01:00

So, I'm off to JavaOne next week!

This is an unexpected and very pleasant surprise. I'll be there with Martin (of the Disruptor fame), and Martijn (that's not going to get confusing at all). Martin will be talking about the Disruptor on Thursday, and Martijn is busy talking about... everything. Most importantly for the LJC he's representing us in our shiny new JCP Executive Committee role.

I'm really looking forward to meeting pretty much anyone and everyone who'll talk to me. It's the first international conference I've been to and I'm hoping to meet people I wouldn't normally get a chance to see in London. It's also really cool to be able to represent both LMAX and the London Java Community. Hopefully it won't lead to some sort of split personality syndrome.

Almost more excitingly, I'll be doing a spot of shopping in New York on the way there and back. Because, well, it would be rude to fly over to the States and not drop in on my old home.

Maybe I'll get a chance to catch up with some of you in one of those amazing cities...?

First public appearance caught on video

2011-09-23T21:05:00.000+01:00

Remember a while back I talked about my first public appearance?

Well, I chased down the video, because I'm masochistic, and here it is for you all to enjoy. Pleasingly my mannerisms are slightly less of a camp man trapped in a woman's body, which was my impression the last time I saw myself presenting. It helps that YouTube has made the video so dark you can't see me.

Slides are available for all to enjoy.

Special thanks to Playfish for hosting the event - as always, their hospitality was awesome. The fact that they didn't serve wine is probably a Good Thing.

Are you an awesome developer?

2011-09-20T18:09:00.001+01:00

We are hiring!

If you think we're doing something interesting, or if you think you can help us do our thing even better, come join us. Your boss will be the dude who wrote Continuous Delivery, you'll get a chance to experience what Danny calls meta-Agile (or Agile Agile), and you'll really start to care about Domain-Driven Design.

Ideally we're after Java people, but at the heart of it we want people who are dead passionate about development.

Apply via the Stack Overflow Careers advert (you get extra brownie points if you mention my blog).

What my hangovers can teach you about Agile

2011-09-17T15:53:00.000+01:00

As a survival trait for living and working in the cites¹ of London, I have a set of rituals to avoid hangovers. If you are not a single person living in a city like London, you might not understand how vital this is. Most networking, particularly in the financial services industry, is done in the presence of alcohol.

So preventing the inevitable hangover is quite important to the other part of the job – the actual working bit. I'll let you into a secret and tell you my nightly ritual:

Floss and clean teeth (OK I'll admit, I barely floss when I'm sober let alone drunk)
Cleanse/tone/moisturise (I'm a rubbish girl, this is a very recent ritual for me)
Apply cuticle cream
Do my calf stretches
Drink 500ml of water
Eat something, even if it's a dirty McDonalds (quarter pounder with cheese, no pickle no onion).

Prior to all this is the additional requirement “don't drink more than a bottle and a half of wine”. Everyone has their limits, lots of practice means I know full well what mine are.

This actually works for me. I won't claim to feel capable of being quite as high performance as the code I'm working on, but I won't feel like killing myself, and I will make it to the gym before work and do a whole day of productive coding.

If you were trying to solve a similar problem (“no debilitating hangovers”), you might try and follow my rituals. But you might decide that drinking the water was going to mean you had to go to the loo in the night, and strike that off the list. You might be on a diet, so you don't have the food, thinking the alcohol is calories enough for the night. And you'll follow everything else religiously, but still have hangovers.

Or you might ignore the alcohol intake guidelines, thinking the stuff that you do at home to repair the damage should be enough, and drink 12 pints of margaritas. Or you might be the sort of person who can only get away with drinking a couple of glasses of wine / pints of beer, and follow my rules perfectly, but still feel like dying the next day.

And when this happens you'll look at my rituals and think "What a waste of time! This person has no idea what they're talking about", and throw the whole lot out of the window and go back to doing waterfall development (oh wait, I'm getting ahead of myself).

Or you'll do the bits that actually prevent the hangover (the water, the food, restricting alchol) and go around telling the interweb I have no idea what I'm talking about because the other stuff is a waste of time.

The key point here is that this works for me. It's foolish of me to tell the world this will fix all their problems, and pointless for others to copy it without realising why they're doing it.

For example – why on Earth is “apply cuticle cream” on there? It doesn't actually fix the problem of dehydration due to excessive alcohol intake. But it's important to me, because I need to make the time to do the whole ritual to get my brain into the right place for sleep. It's also dead important for my subconscious – alcohol is basically abuse of my body, the beauty part of the regime is to remind my brain that its important to take care of myself too. It doesn't fix the immediate issue of hangover the next day, but it aims to prevent future problems of drowning my sorrows in alcohol. It's an important part of my Long Term Plan – these rituals need to be worked into the daily steps to lead eventually to World Domination.

And calf stretches? Well, I'm injured, have had shin splints for a million years. If I want to run the Royal Parks Half Marathon in October, I need to stretch 3 times a day. Doesn't matter if I'm drunk or not, it's not an excuse. The half marathon is a very important longer-term goal. But you don't need to do it. Well, unless you have the same issue.

The important thing is that all of these rituals are tied to a goal. But they're not the same goal:

Floss and clean teeth. GOAL – don't get told off by the dentist. Don't require fillings - costs money and not great for overall health.
Cleanse/tone/moisturise. GOAL – prepare subconscious for sleep and remind brain that body needs love.
Apply cuticle cream. GOAL – prepare subconscious for sleep and remind brain that body needs love.
Do my calf stretches GOAL – Royal Parks Half Marathon
Drink 500ml of water GOAL – prevent Debilitating Hangover
Eat something, even if it's a dirty McDonalds GOAL – prevent Debilitating Hangover.

The thing here is that if I didn't do the stuff to aim towards longer-term goals, I might be more inclined to drink more out of boredom or despair, I might have worse hangovers in the future.

To paraphrase Eddie Izzard “...and that's like ~~our Lord Jesus~~ the agile process...”. Agile, in whatever form you take it (actually all processes) is supposed to enable you as a team / organisation to work better. Whichever cult you follow, there are practices designed to work for you to make you more productive. But you do have to continuously improve, gather and act on feedback, and, most importantly, to know why you're doing what you're doing. Otherwise it's just cargo cultism – you look like you're doing everything, but the results just don't arrive. I've worked for a scrum-but company – they had the cards, short iterations, invested customers. But no single product owner, they never acted on the results of retrospectives, and most importantly the team didn't own the work they'd signed up to. They also had a project manager who told people what they were doing. This doesn't answer the question. This is drinking 12 pints of scrumpy and doing "cleanse/tone/moisturise", and wondering why it still hurts.

You have to understand the problem. You can't blindly follow the stuff that you fancy, the stuff you find easy. If it's easy, it's probably something you were already doing. If you picked up agile to make a change to deliver more/better/faster, there is going to be some pain. Because if what you were doing before was working, you'd carry on doing it. So improvement is going to be hard. At first.

The key is to stick with it, to check progress, to continuously improve. To find what works for you.

¹ Random fact of the day: London is actually two cities, the City of London and the City of Westminster. But you probably already knew that.

Effective Sketches

2011-09-04T18:52:00.002+01:00

On Thursday I was at Simon Brown's Effective Sketches session at Skillsmatter. Just because my pictures are pretty awesome doesn't mean there's no opportunity for continuous learning.

The points Simon made in the session really made sense to me, and I wish I could have had something like that as a primer when they taught us UML at university. Without the context of what the diagrams were supposed to mean, to convey, all the boxes and lines made no sense to me back then. I'm still not a fan of large chunks of UML because I think the convention sometimes gets in the way of real meaning.

My take-away points were:

Don't try and squidge everything onto a single diagram. The reason lots of different flavours of architecture diagrams exist (e.g. logical view, infrastructure view, etc) is because you have different audiences for each of the diagrams and different things that are important when you're looking at it from one particular angle.
One diagram you particularly need, especially if you are producing a stack of documentation for a system (e.g. you're a consultant presenting findings to the client) is a really succinct, summary view of what the system is actually trying to achieve.
If you're not going to use UML, you should at least agree on consistency and some conventions - for example, does the direction of an arrow represent data flow or dependency?
UML tools make it easier to represent different views of a data model and retain consistency. One diagram is less likely to contradict a different view if your sketching tool points this mistake out to you.
Yes, your code should be self-documenting. But you can't give the code to your business customers or expect your hardware guys to figure out your requirements from it. To pass knowledge around the business it's more efficient to have diagrams representing the shared understanding of the domain.
Architecture diagrams should show the intent and the vision of the system.

I also used my laptop to take notes for the first time. In the past I've preferred not to use a laptop, because a) I like pencil and paper and it allows me to doodle and b) the temptation to read my e-mail or check facebook is not something I want to succumb to. But using Evernote really worked for me, I could annotate the slides with my notes, and it made converting my notes into this post a lot easier.

PS it has not escaped me that this is one post without a diagram. The irony is not lost on me.

Disruptor 2.0 - All Change Please

2011-08-30T10:18:00.002+01:00

Martin recently announced version 2.0 of the Disruptor - basically there have been so many changes since we first open-sourced it that it's time to mark that officially. His post goes over all the changes, the aim of this article is to attempt to translate my previous blog posts into new-world-speak, since it's going to take a long time to re-write each of them all over again. Now I see the disadvantage of hand-drawing everything.

In the old world

This is an example of a configuration of the Disruptor (specifically a diamond configuration). If none of this means anything to you, feel free to go back and refresh yourself on all the (now outdated) Disruptor details.

The most obvious changes over the last few weeks have been:

Updated naming convention
Integrating the producer barrier into the ring buffer
Adding the Disruptor wizard into the main code base.

The New World Order

You'll see the fundamentals are pretty much the same. It's simpler, because the ProducerBarrier is no longer an entity in its own right - its replacement is the PublishPort interface, which is implemented by the RingBuffer itself.

Similarly the name DependencyBarrier instead of ConsumerBarrier clarifies the job of this object; Publisher (instead of Producer) and EventProcessor instead of Consumer also more accurately represent what these things do. There was always a little confusion over the name Consumer, since consumers never actually consumed anything from the ring buffer. It was simply a term that we hoped would make sense to those who were used to queue implementations.

Not shown on the diagram is the name change of the items in the RingBuffer - in the old world, we called this Entry, now they're an Event, hence EventProcessor at the other end.

The aim of this wholesale rename has not been to completely discredit all my old blogs so I can continue blogging about the Disruptor ad infinitum. This is far from what I want - I have other, more fluffy, things to write about. The aim of the rename is to make it easier to understand how the Disruptor works and how to use it. Although we use the Disruptor for event processing, when we open sourced it we wanted it to look like a general purpose solution, so the naming convention tried to represent that. But in fact the event processing model does seem more intuitive.

No more tedious wiring
Now the Disruptor wizard is part of the Disruptor itself, my whole post on wiring is pretty pointless - which is good, actually, because it was a little involved.

These days, if you want to create the diamond pattern (for example the FizzBuzz performance test), it's a lot simpler:

DisruptorWizard dw = new DisruptorWizard<FizzBuzzEvent>(

                         ENTRY_FACTORY, 

                         RING_BUFFER_SIZE, 

                         EXECUTOR,

                         ClaimStrategy.Option.SINGLE_THREADED,

                         WaitStrategy.Option.YIELDING);

FizzBuzzEventHandler fizzHandler = 

                         new FizzBuzzEventHandler(FIZZ);

FizzBuzzEventHandler buzzHandler = 

                         new FizzBuzzEventHandler(BUZZ);

FizzBuzzEventHandler fizzBuzzHandler = 

                         new FizzBuzzEventHandler(FIZZ_BUZZ);



dw.handleEventsWith(fizzHandler, buzzHandler)

  .then(fizzBuzzHandler);



RingBuffer ringBuffer = dw.start();

Note there is a Wiki page on the Disruptor Wizard.

Other changes: performance improvements
As Martin mentions in his post, he's managed to significantly improve the performance (even more!) of the Disruptor in 2.0.

The short version of this is that there is a shiny new class, Sequence, which both takes care of the cache line padding, and removes the need for memory barriers. The cache line padding is now done slightly differently because, bless Java 7's little cotton socks, it managed to "optimise" our old technique away.

I'll leave you to read the details over there, in this post I just wanted to give a quick summary of the changes and explain why my old diagrams may no longer be correct.

What I Did On My Holidays

2011-08-13T10:17:00.000+01:00

And now, a post for my long-neglected, less technical readers.

I took a week off in July to try and avoid that Oh My God I Missed Summer Again feeling. Granted, it's easy to get that in the UK even if you're not stuck in an office the entire time.

Really this is just an excuse to post some photos on the blog.

Monday
Hopped on the bike and explored from Kensington to Westminster.

Felt distinctly smug when I grabbed my lunch from Victoria amongst all the less fortunate people who had to go back to their offices.

Tuesday
Decided to dose up on Culture, and went to the National Gallery. Last time I was there I was eight years old, and I distinctly remember admiring the frames more than the art.

The rather marvellous Artfinder makes up for the fact that you can't take photos inside the gallery - I can share most of the pieces that struck me when I was there.

Wednesday
Finally got around to embarking on one of the walks in Secret London. I chose to do the City, from St Paul's, covering Bank, Monument and Liverpool St.

It was fascinating. I've worked in a lot of places round there, socialise there regularly, and have explored a number of the nooks and crannies. But I was astounded at how many places I had never seen, alleys I had no idea existed, and gardens hidden away between modern office blocks.

Highly recommended.

Thursday
My parents dropped by and I racked my brain for a different way to explore this massive, old city. And it came to me: using the artery of the city - the river. So we took a boat to Greenwich.

Where they were filming Batman.

And I didn't know until after we'd left.

Gutted.

Friday
The sun finally makes an appearance. I was going to write a blog post, but I refuse to be indoors on a sunny day if I can get outside for some Vitamin D production (and I hadn't bought my new shiny then).

Sat in the park, sunbathed.

Brilliant day.

Brilliant week.

Dissecting the Disruptor: Demystifying Memory Barriers

2011-08-07T19:37:00.002+01:00

My recent slow-down in posting is because I've been trying to write a post explaining memory barriers and their applicability in the Disruptor. The problem is, no matter how much I read and no matter how many times I ask the ever-patient Martin and Mike questions trying to clarify some point, I just don't intuitively grasp the subject. I guess I don't have the deep background knowledge required to fully understand.

So, rather than make an idiot of myself trying to explain something I don't really get, I'm going to try and cover, at an abstract / massive-simplification level, what I do understand in the area. Martin has written a post going into memory barriers in some detail, so hopefully I can get away with skimming the subject.

Disclaimer: any errors in the explanation are completely my own, and no reflection on the implementation of the Disruptor or on the LMAX guys who actually do know about this stuff.

What's the point?
My main aim in this series of blog posts is to explain how the Disruptor works and, to a slightly lesser extent, why. In theory I should be able to provide a bridge between the code and the technical paper by talking about it from the point of view of a developer who might want to use it.

The paper mentioned memory barriers, and I wanted to understand what they were, and how they apply.

What's a Memory Barrier?
It's a CPU instruction. Yes, once again, we're thinking about CPU-level stuff in order to get the performance we need (Martin's famous Mechanical Sympathy). Basically it's an instruction to a) ensure the order in which certain operations are executed and b) influence visibility of some data (which might be the result of executing some instruction).

Compilers and CPUs can re-order instructions, provided the end result is the same, to try and optimise performance. Inserting a memory barrier tells the CPU and the compiler that what happened before that command needs to stay before that command, and what happens after needs to stay after. All similarities to a trip to Vegas are entirely in your own mind.

The other thing a memory barrier does is force an update of the various CPU caches - for example, a write barrier will flush all the data that was written before the barrier out to cache, therefore any other thread that tries to read that data will get the most up-to-date version regardless of which core or which socket it might be executing by.

What's this got to do with Java?
Now I know what you're thinking - this isn't assembler. It's Java.

The magic incantation here is the word volatile (something I felt was never clearly explained in the Java certification). If your field is volatile, the Java Memory Model inserts a write barrier instruction after you write to it, and a read barrier instruction before you read from it.

This means if you write to a volatile field, you know that:

Any thread accessing that field after the point at which you wrote to it will get the updated value
Anything you did before you wrote that field is guaranteed to have happened and any updated data values will also be visible, because the memory barrier flushed all earlier writes to the cache.

Example please!

So glad you asked. It's about time I started drawing doughnuts again.

The RingBuffer cursor is one of these magic volatile thingies, and it's one of the reasons we can get away with implementing the Disruptor without locking.

The Producer will obtain the next Entry (or batch of them) and do whatever it needs to do to the entries, updating them with whatever values it wants to place in there. As you know, at the end of all the changes the producer calls the commit method on the ring buffer, which updates the sequence number. This write of the volatile field (cursor) creates a memory barrier which ultimately brings all the caches up to date (or at least invalidates them accordingly).

At this point, the consumers can get the updated sequence number (8), and because the memory barrier also guarantees the ordering of the instructions that happened before then, the consumers can be confident that all changes the producer did to to the Entry at position 7 are also available.

...and on the Consumer side?

The sequence number on the Consumer is volatile, and read by a number of external objects - other downstream consumers might be tracking this consumer, and the ProducerBarrier/RingBuffer (depending on whether you're looking at older or newer code) tracks it to make sure the the ring doesn't wrap.

So, if your downstream consumer (C2) sees that an earlier consumer (C1) reaches number 12, when C2 reads entries up to 12 from the ring buffer it will get all updates C1 made to the entries before it updated its sequence number.

Basically everything that happens after C2 gets the updated sequence number (shown in blue above) must occur after everything C1 did to the ring buffer before updating its sequence number (shown in black).

Impact on performance
Memory barriers, being another CPU-level instruction, don't have the same cost as locks - the kernel isn't interfering and arbitrating between multiple threads. But nothing comes for free. Memory barriers do have a cost - the compiler/CPU cannot re-order instructions, which could potentially lead to not using the CPU as efficiently as possible, and refreshing the caches obviously has a performance impact. So don't think that using volatile instead of locking will get you away scot free.

You'll notice that the Disruptor implementation tries to read from and write to the sequence number as infrequently as possible. Every read or write of a volatile field is a relatively costly operation. However, recognising this also plays in quite nicely with batching behaviour - if you know you shouldn't read from or write to the sequences too frequently, it makes sense to grab a whole batch of Entries and process them before updating the sequence number, both on the Producer and Consumer side. Here's an example from BatchConsumer:

    long nextSequence = sequence + 1;

    while (running)

{

try

{

            final long availableSequence = consumerBarrier.waitFor(nextSequence);

            while (nextSequence <= availableSequence)

{

                entry = consumerBarrier.getEntry(nextSequence);

                handler.onAvailable(entry);

                nextSequence++;

}

            handler.onEndOfBatch();

            sequence = entry.getSequence();

}

...

        catch (final Exception ex)

{

            exceptionHandler.handle(ex, entry);

            sequence = entry.getSequence();

            nextSequence = entry.getSequence() + 1;

}

}

(You'll note this is the "old" code and naming conventions, because this is inline with my previous blog posts, I thought it was slightly less confusing than switching straight to the new conventions).

In the code above, we use a local variable to increment during our loop over the entries the consumer is processing. This means we read from and write to the volatile sequence field (shown in bold) as infrequently as we can get away with.

In Summary
Memory barriers are CPU instructions that allow you to make certain assumptions about when data will be visible to other processes. In Java, you implement them with the volatile keyword. Using volatile means you don't necessarily have to add locks willy nilly, and will give you performance improvements over using them. However you need to think a little more carefully about your design, in particular how frequently you use volatile fields, and how frequently you read and write them.

PS Given that the New World Order in the Disruptor uses totally different naming conventions now to everything I've blogged about so far, I guess the next post is mapping the old world to the new one.

Dissecting the Disruptor: Why it's so fast (part two) - Magic cache line padding

2011-07-22T16:42:00.001+01:00

We mention the phrase Mechanical Sympathy quite a lot, in fact it's even Martin's blog title. It's about understanding how the underlying hardware operates and programming in a way that works with that, not against it.

We get a number of comments and questions about the mysterious cache line padding in the RingBuffer, and I referred to it in the last post. Since this lends itself to pretty pictures, it's the next thing I thought I would tackle.

Comp Sci 101
One of the things I love about working at LMAX is all that stuff I learnt at university and in my A Level Computing actually means something. So often as a developer you can get away with not understanding the CPU, data structures or Big O notation - I spent 10 years of my career forgetting all that. But it turns out that if you do know about these things, and you apply that knowledge, you can come up with some very clever, very fast code.

So, a refresher for those of us who studied this at school, and an intro for those who didn't. Beware - this post contains massive over-simplifications.

The CPU is the heart of your machine and the thing that ultimately has to do all the operations, executing your program. Main memory (RAM) is where your data (including the lines of your program) lives. We're going to ignore stuff like hard drives and networks here because the Disruptor is aimed at running as much as possible in memory.

The CPU has several layers of cache between it and main memory, because even accessing main memory is too slow. If you're doing the same operation on a piece of data multiple times, it makes sense to load this into a place very close to the CPU when it's performing the operation (think a loop counter - you don't want to be going off to main memory to fetch this to increment it every time you loop around).

The closer the cache is to the CPU, the faster it is and the smaller it is. L1 cache is small and very fast, and right next to the core that uses it. L2 is bigger and slower, and still only used by a single core. L3 is more common with modern multi-core machines, and is bigger again, slower again, and shared across cores on a single socket. Finally you have main memory, which is shared across all cores and all sockets.

When the CPU is performing an operation, it's first going to look in L1 for the data it needs, then L2, then L3, and finally if it's not in any of the caches the data needs to be fetched all the way from main memory. The further it has to go, the longer the operation will take. So if you're doing something very frequently, you want to make sure that data is in L1 cache.

Martin and Mike's QCon presentation gives some indicative figures for the cost of cache misses:

Latency from CPU to...	Approx. number of CPU cycles	Approx. time in nanoseconds
Main memory		~60-80ns
QPI transit (between sockets, not drawn)		~20ns
L3 cache	~40-45 cycles,	~15ns
L2 cache	~10 cycles,	~3ns
L1 cache	~3-4 cycles,	~1ns
Register	1 cycle

If you're aiming for an end-to-end latency of something like 10 milliseconds, an 80 nanosecond trip to main memory to get some missing data is going to take a serious chunk of that.

Cache lines

Now the interesting thing to note is that it's not individual items that get stored in the cache - i.e. it's not a single variable, a single pointer. The cache is made up of cache lines, typically 64 bytes, and it effectively references a location in main memory. A Java long is 8 bytes, so in a single cache line you could have 8 long variables.

(I'm going to ignore the multiple cache-levels for simplicity)

This is brilliant if you're accessing an array of longs - when one value from the array gets loaded into the cache, you get up to 7 more for free. So you can walk that array very quickly. In fact, you can iterate over any data structure that is allocated to contiguous blocks in memory very quickly. I made a passing reference to this in the very first post about the ring buffer, and it explains why we use an array for it.

So if items in your data structure aren't sat next to each other in memory (linked lists, I'm looking at you) you don't get the advantage of freebie cache loading. You could be getting a cache miss for every item in that data structure.

However, there is a drawback to all this free loading. Imagine your long isn't part of an array. Imagine it's just a single variable. Let's call it head, for no real reason. Then imagine you have another variable in your class right next to it. Let's arbitrarily call it tail. Now, when you load head into your cache, you get tail for free.

Which sounds fine. Until you realise that tail is being written to by your producer, and head is being written to by your consumer. These two variables aren't actually closely associated, and in fact are going to be used by two different threads that might be running on two different cores.

Imagine your consumer updates the value of head. The cache value is updated, the value in memory is updated, and any other cache lines that contain head are invalidated because other caches will not have the shiny new value. And remember that we deal with the level of the whole line, we can't just mark head as being invalid.

Now if some process running on the other core just wants to read the value of tail, the whole cache line needs to be re-read from main memory. So a thread which is nothing to do with your consumer is reading a value which is nothing to do with head, and it's slowed down by a cache miss.

Of course this is even worse if two separate threads are writing to the two different values. Both cores are going to be invalidating the cache line on the other core and having to re-read it every time the other thread has written to it. You've basically got write-contention between the two threads even though they're writing to two different variables.

This is called false sharing, because every time you access head you get tail too, and every time you access tail, you get head as well. All this is happening under the covers, and no compiler warning is going to tell you that you just wrote code that's going to be very inefficient for concurrent access.

Our solution - magic cache line padding

You'll see that the Disruptor eliminates this problem, at least for architecture that has a cache size of 64 bytes or less, by adding padding to ensure the ring buffer's sequence number is never in a cache line with anything else.

    public long p1, p2, p3, p4, p5, p6, p7; // cache line padding

    private volatile long cursor = INITIAL_CURSOR_VALUE;

    public long p8, p9, p10, p11, p12, p13, p14; // cache line padding

So there's no false sharing, no unintended contention with any other variables, no needless cache misses.

It's worth doing this on your Entry classes too - if you have different consumers writing to different fields, you're going to need to make sure there's no false sharing between each of the fields.

EDIT: Martin wrote a more technically correct and detailed post about false sharing, and posted performance results too.

Dissecting the Disruptor: Why it's so fast (part one) - Locks Are Bad

2011-07-16T16:36:00.003+01:00

Martin Fowler has written a really good article describing not only the Disruptor, but also how it fits into the architecture at LMAX. This gives some of the context that has been missing so far, but the most frequently asked question is still "What is the Disruptor?".

I'm working up to answering that. I'm currently on question number two: "Why is it so fast?".

These questions do go hand in hand, however, because I can't talk about why it's fast without saying what it does, and I can't talk about what it is without saying why it is that way.

So I'm trapped in a circular dependency. A circular dependency of blogging.

To break the dependency, I'm going to answer question one with the simplest answer, and with any luck I'll come back to it in a later post if it still needs explanation: the Disruptor is a way to pass information between threads.

As a developer, already my alarm bells are going off because the word "thread" was just mentioned, which means this is about concurrency, and Concurrency Is Hard.

Concurrency 101

Imagine two threads are trying to change the same value.

Case One: Thread 1 gets there first:

The value changes to "blah"
Then the value changes to "blahy" when Thread 2 gets there.

Case Two: Thread 2 gets there first:

The value changes to "fluffy"
Then the value changes to "blah" when Thread 1 gets there.

Case Three: Thread 1 interrupts Thread 2:

Thread 2 gets the value "fluff" and stores it as myValue
Thread 1 goes in and updates value to "blah"
Then Thread 2 wakes up and sets the value to "fluffy".

Case Three is probably the only one which is definitely wrong, unless you think the naive approach to wiki editing is OK (Google Code Wiki, I'm looking at you...). In the other two cases it's all about intentions and predictability. Thread 2 might not care what's in value, the intention might be to append "y" to whatever is in there regardless. In this circumstance, cases one and two are both correct.

But if Thread 2 only wanted to change "fluff" to "fluffy", then both cases two and three are incorrect.

Assuming that Thread 2 wants to set the value to "fluffy", there are some different approaches to solving the problem.

Approach One: Pessimistic locking

(Does the "No Entry" sign make sense to people who don't drive in Britain?)

The terms pessimistic and optimistic locking seem to be more commonly used when talking about database reads and writes, but the principal applies to getting a lock on an object.

Thread 2 grabs a lock on Entry as soon as it knows it needs it and stops anything from setting it. Then it does its thing, sets the value, and lets everything else carry on.

You can imagine this gets quite expensive, with threads hanging around all over the place trying to get hold of objects and being blocked. The more threads you have, the more chance that things are going to grind to a halt.

Approach Two: Optimistic locking

In this case Thread 2 will only lock Entry when it needs to write to it. In order to make this work, it needs to check if Entry has changed since it first looked at it. If Thread 1 came in and changed the value to "blah" after Thread 2 had read the value, Thread 2 couldn't write "fluffy" to the Entry and trample all over the change from Thread 1. Thread 2 could either re-try (go back, read the value, and append "y" onto the end of the new value), which you would do if Thread 2 didn't care what the value it was changing was; or it could throw an exception or return some sort of failed update flag if it was expecting to change "fluff" to "fluffy". An example of this latter case might be if you have two users trying to update a Wiki page, and you tell the user on the other end of Thread 2 they'll need to load the new changes from Thread 1 and then reapply their changes.

Potential Problem: Deadlock

Locking can lead to all sorts of issues, for example deadlock. Imagine two threads that need access to two resources to do whatever they need to do:

If you've used an over-zealous locking technique, both threads are going to sit there forever waiting for the other one to release its lock on the resource. That's when you reboot ~~Windows~~ your computer.

Definite Problem: Locks are sloooow...
The thing about locks is that they need the operating system to arbitrate the argument. The threads are like siblings squabbling over a toy, and the OS kernel is the parent that decides which one gets it. It's like when you run to your Dad to tell him your sister has nicked the Transformer when you wanted to play with it - he's got bigger things to worry about than you two fighting, and he might finish off loading the dishwasher and putting on the laundry before settling the argument. If you draw attention to yourself with a lock, not only does it take time to get the operating system to arbitrate, the OS might decide the CPU has better things to do than servicing your thread.

The Disruptor paper talks about an experiment we did. The test calls a function incrementing a 64-bit counter in a loop 500 million times. For a single thread with no locking, the test takes 300ms. If you add a lock (and this is for a single thread, no contention, and no additional complexity other than the lock) the test takes 10,000ms. That's, like, two orders of magnitude slower. Even more astounding, if you add a second thread (which logic suggests should take maybe half the time of the single thread with a lock) it takes 224,000ms. Incrementing a counter 500 million times takes nearly a thousand times longer when you split it over two threads instead of running it on one with no lock.

Concurrency Is Hard and Locks Are Bad
I'm just touching the surface of the problem, and obviously I'm using very simple examples. But the point is, if your code is meant to work in a multi-threaded environment, your job as a developer just got a lot more difficult:

Naive code can have unintended consequences. Case Three above is an example of how things can go horribly wrong if you don't realise you have multiple threads accessing and writing to the same data.
Selfish code is going to slow your system down. Using locks to protect your code from the problem in Case Three can lead to things like deadlock or simply poor performance.

This is why many organisations have some sort of concurrency problems in their interview process (certainly for Java interviews). Unfortunately it's very easy to learn how to answer the questions without really understanding the problem, or possible solutions to it.

How does the Disruptor address these issues?
For a start, it doesn't use locks. At all.

Instead, where we need to make sure that operations are thread-safe (specifically, updating the next available sequence number in the case of multiple producers), we use a CAS (Compare And Swap/Set) operation. This is a CPU-level instruction, and in my mind it works a bit like optimistic locking - the CPU goes to update a value, but if the value it's changing it from is not the one it expects, the operation fails because clearly something else got in there first.

Note this could be two different cores rather than two separate CPUs.

CAS operations are much cheaper than locks because they don't involve the operating system, they go straight to the CPU. But they're not cost-free - in the experiment I mentioned above, where a lock-free thread takes 300ms and a thread with a lock takes 10,000ms, a single thread using CAS takes 5,700ms. So it takes less time than using a lock, but more time than a single thread that doesn't worry about contention at all.

Back to the Disruptor - I talked about the ClaimStrategy when I went over the producers. In the code you'll see two strategies, a SingleThreadedStrategy and a MultiThreadedStrategy. You could argue, why not just use the multi-threaded one with only a single producer? Surely it can handle that case? And it can. But the multi-threaded one uses an AtomicLong (Java's way of providing CAS operations), and the single-threaded one uses a simple long with no locks and no CAS. This means the single-threaded claim strategy is as fast as possible, given that it knows there is only one producer and therefore no contention on the sequence number.

I know what you're thinking: turning one single number into an AtomicLong can't possibly have been the only thing that is the secret to the Disruptor's speed. And of course, it's not - otherwise this wouldn't be called "Why it's so fast (part one)".

But this is an important point - there's only one place in the code where multiple threads might be trying to update the same value. Only one place in the whole of this complicated data-structure-slash-framework. And that's the secret. Remember everything has its own sequence number? If you only have one producer then every sequence number in the system is only ever written to by one thread. That means there is no contention. No need for locks. No need even for CAS. The only sequence number that is ever written to by more than one thread is the one on the ClaimStrategy if there is more than one producer.

This is also why each variable in the Entry can only be written to by one consumer. It ensures there's no write contention, therefore no need for locks or CAS.

Back to why queues aren't up to the job
So you start to see why queues, which may implemented as a ring buffer under the covers, still can't match the performance of the Disruptor. The queue, and the basic ring buffer, only has two pointers - one to the front of the queue and one to the end:

If more than one producer wants to place something on the queue, the tail pointer will be a point of contention as more than one thing wants to write to it. If there's more than one consumer, then the head pointer is contended, because this is not just a read operation but a write, as the pointer is updated when the item is consumed from the queue.

But wait, I hear you cry foul! Because we already knew this, so queues are usually single producer and single consumer (or at least they are in all the queue comparisons in our performance tests).

There's another thing to bear in mind with queues/buffers. The whole point is to provide a place for things to hang out between producers and consumers, to help buffer bursts of messages from one to the other. This means the buffer is usually full (the producer is out-pacing the consumer) or empty (the consumer is out-pacing the producer). It's rare that the producer and consumer will be so evenly-matched that the buffer has items in it but the producers and consumers are keeping pace with each other.

So this is how things really look. An empty queue:

...and a full queue:

The queue needs a size so that it can tell the difference between empty and full. Or, if it doesn't, it might determine that based on the contents of that entry, in which case reading an entry will require a write to erase it or mark it as consumed.

Whichever implementation is chosen, there's quite a bit of contention around the tail, head and size variables, or the entry itself if a consume operation also includes a write to remove it.

On top of this, these three variables are often in the same cache line, leading to false sharing. So, not only do you have to worry about the producer and the consumer both causing a write to the size variable (or the entry), updating the tail pointer could lead to a cache-miss when the head pointer is updated because they're sat in the same place. I'm going to duck out of going into that in detail because this post is quite long enough as it is.

So this is what we mean when we talk about "Teasing Apart the Concerns" or a queue's "conflated concerns". By giving everything its own sequence number and by allowing only one consumer to write to each variable in the Entry, the only case the Disruptor needs to manage contention is where more than one producer is writing to the ring buffer.

In summary
The Disruptor a number of advantages over traditional approaches:

No contention = no locks = it's very fast.
Having everything track its own sequence number allows multiple producers and multiple consumers to use the same data structure.
Tracking sequence numbers at each individual place (ring buffer, claim strategy, producers and consumers), plus the magic cache line padding, means no false sharing and no unexpected contention.

EDIT: Note that version 2.0 of the Disruptor uses different names to the ones in this article. Please see my summary of the changes if you are confused about class names.

In answer to one of the search terms which led to my blog...

2011-07-12T18:41:00.000+01:00

..."what do female programmers look like":

Well, sometimes...

If there are any girl programmers out there who are interested in being part of a montage showing who we are, I'd be dead (see what I did there...?) interested in putting us all on one page. And not just because I'm narcissistic. Although that helps.

Dissecting the Disruptor: Wiring up the dependencies

2011-07-10T17:02:00.003+01:00

So now I've covered the ring buffer itself, reading from it and writing to it.

Logically the next thing to do is to wire everything up together.

I talked about multiple producers - they have the producer barrier to keep them in order and under control. I've talked about consumers in a simple situation. Multiple consumers can get a little more involved. We've done some clever stuff to allow the consumers to be dependent on each other and the ring buffer. Like a lot of applications, we have a pipeline of things that need to happen before we can actually get on with the business logic - for example, we need to make sure the messages have been journalled to disk before we can do anything.

The Disruptor paper and the performance tests cover some basic configurations that you might want. I'm going to go over the most interesting one, mostly because I needed the practice with the graphics tablet.

Diamond configuration
DiamondPath1P3CPerfTest illustrates a configuration which is not too uncommon - a single producer with three consumers. The tricky point being that the third consumer is dependent upon the previous two consumers to finish before it can do anything.

Consumer three might be your business logic, consumer one could be backing up the data received, and consumer two may be preparing the data or something.

Diamond configuration using queues
In a SEDA-style architecture, each stage will be separated by a queue:

(Why does queue have to have so many "e"s? It's the letter I have the most trouble with in these drawings).

You might get an inkling of the problem here: for a message to get from P1 to C3 it has to travel through four whole queues, each queue taking its cost in terms of putting the message on the queue and taking it off again.

Diamond configuration using the Disruptor
In the Disruptor world, it's all managed on a single ring buffer:

It does look more complicated. But the ring buffer remains the single point of contact between all the players, and the interactions are all based on the barriers checking the sequence numbers of the things it's dependent upon.

The producer side is fairly simple, it's the single producer model described in my last post. Interestingly, the producer barrier doesn't have to care about all the consumers. It only cares about consumer three, because if consumer three has finished with an item in the ring buffer the other two will already have processed it. So if C3 has moved on, that slot in the ring buffer is available.

To manage the dependencies between the consumers you need two consumer barriers. The first just talks to the ring buffer and consumers one and two ask it for the next available item. The second consumer barrier knows about consumers one and two, and it will return the lowest sequence number processed by both consumers.

How consumer dependencies work in the Disruptor
Hmm. I can see I'm going to need an example.

We're joining the party halfway through the story: the producer has filled the ring buffer up to sequence number 22; consumer one has read and processed everything up to 21; consumer two has processed everything up to sequence 18; consumer three, which is dependent upon the other consumers, has only made it as far as 15.

The producer can't write anything more to the ring buffer because sequence 15 is taking up the slot where we'd want to put sequence 23.

(I'm sorry, I really did try to find an alternative to red and green, but everything else was just as ambiguous).

The first consumer barrier lets consumers one and two know they can grab anything up to sequence 22, the highest sequence number in the ring buffer. The second consumer barrier checks the ring buffer sequence, but it also checks the sequences on the other two consumers and returns the lowest value. So consumer three is told it can get anything up to sequence 18 from the ring buffer.

Note that the consumers are still reading the entries directly from the ring buffer - consumers one and two are not taking the entries off the ring buffer and then passing them on to consumer three. Instead, the second consumer barrier is letting consumer three know which entry in the ring buffer it's safe to process.

This raises a question - if everything comes directly off the ring buffer, how is consumer three going to find out about anything the first two consumers have done? If all consumer three cares about is that the earlier consumers have done their job (e.g. replicating the data to somewhere else) then everything's fine - when consumer three is told the job is done, it's happy. If, however, consumer three needs the results of an earlier consumer's processing, where does it get that from?

Modifying entries
The secret is to write them to the ring buffer Entry itself. This way, when consumer three grabs the entry off the ring buffer, it will have been populated with all the information consumer three needs to do the job. The really important part of this is that for each field on the Entry only one consumer is allowed to write to it. This prevents any write-contention which will slow the whole thing down.

You can see this in DiamondPath1P3CPerfTest - FizzBuzzEntry has two fields as well as the value: fizz and buzz. If the consumer is a Fizz consumer, it writes to fizz. If it's a Buzz consumer, it writes to buzz. The third consumer, FizzBuzz, will read both of these fields but not write to either, since reading is fine and won't cause contention.

Some actual Java code
All this looks more complicated than the queue implementation. And yes, it does involve a bit more coordination. But this is hidden from the consumers and producers, they just talk to the barriers. The trick is in the configuration. The diamond graph in the example above would be created using something like the following:

ConsumerBarrier consumerBarrier1 = ringBuffer.createConsumerBarrier();



BatchConsumer consumer1 = new BatchConsumer(consumerBarrier1, handler1);

BatchConsumer consumer2 = new BatchConsumer(consumerBarrier1, handler2);



ConsumerBarrier consumerBarrier2 = 

    ringBuffer.createConsumerBarrier(consumer1, consumer2);



BatchConsumer consumer3 = new BatchConsumer(consumerBarrier2, handler3);



ProducerBarrier producerBarrier = 

    ringBuffer.createProducerBarrier(consumer3);

In summary
So there you have it - how to wire up the Disruptor with multiple consumers that are dependent on each other. The key points:

Use multiple consumer barriers to manage dependencies between consumers.
Have the producer barrier watch the last consumer in the graph.
Allow only one consumer to write to an individual field in an Entry.

EDIT: Adrian has written a nice DSL to make wiring up the Disruptor much easier.

EDIT 2: Note that version 2.0 of the Disruptor uses different names to the ones in this article. Please see my summary of the changes if you are confused about class names. Also Adrian's DSL is now part of the main Disruptor code base.

Dissecting the Disruptor: Writing to the ring buffer

2011-07-04T15:27:00.003+01:00

This is the missing piece in the end-to-end view of the Disruptor. Brace yourselves, it's quite long. But I decided to keep it in a single blog so you could have the context in one place.

The important areas are: not wrapping the ring; informing the consumers; batching for producers; and how multiple producers work.

ProducerBarriers
The Disruptor code has interfaces and helper classes for the Consumers, but there's no interface for your producer, the thing that writes to the ring buffer. That's because nothing else needs to access your producer, only you need to know about it. However, like the consuming side, a ProducerBarrier is created by the ring buffer and your producer will use this to write to it.

Writing to the ring buffer involves a two-phase commit. First, your producer has to claim the next slot on the buffer. Then, when the producer has finished writing to the slot, it will call commit on the ProducerBarrier.

So let's look at the first bit. It sounds easy - "get me the next slot on the ring buffer". Well, from your producer's point of view it is easy. You simply call nextEntry() on the ProducerBarrier. This will return you an Entry object which is basically the next slot in the ring buffer.

The ProducerBarrier makes sure the ring buffer doesn't wrap
Under the covers, the ProducerBarrier is doing all the negotiation to figure out what the next slot is, and if you're allowed to write to it yet.

(I'm not convinced the shiny new graphics tablet is helping the clarity of my pictures, but it's fun to use).

For this illustration, we're going to assume there's only one producer writing to the ring buffer. We will deal with the intricacies of multiple producers later.

The ConsumerTrackingProducerBarrier has a list of all the Consumers that are accessing the ring buffer. Now to me this seemed a bit odd - I wouldn't expect the ProducerBarrier to know anything about the consuming side. But wait, there is a reason. Because we don't want the "conflation of concerns" a queue has (it has to track the head and tail which are sometimes the same point), our consumers are responsible for knowing which sequence number they're up to, not the ring buffer. So, if we want to make sure we don't wrap the buffer, we need to check where the consumers have got to.

In the diagram above, one Consumer is happily at the same point as the highest sequence number (12, highlighted in red/pink). The second Consumer is a bit behind - maybe it's doing I/O operations or something - and it's at sequence number 3. Therefore consumer 2 has the whole length of the buffer to go before it catches up with consumer 1.

The producer wants to write to the slot on the ring buffer currently occupied by sequence 3, because this slot is the one after the current ring buffer cursor. But the ProducerBarrier knows it can't write here because a Consumer is using it. So the ProducerBarrier sits and spins, waiting, until the consumers move on.

Claiming the next slot
Now imagine consumer 2 has finished that batch of entries, and moves its sequence number on. Maybe it got as far as sequence 9 (in real life I expect it will make it as far as 12 because of the way consumer batching works, but that doesn't make the example as interesting).

The diagram above shows what happens when consumer 2 updates to sequence number 9. I've slimmed down the ConsumerBarrier in this picture because it takes no active part in this scene.

The ProducerBarrier sees that the next slot, the one that had sequence number 3, is now available. It grabs the Entry that sits in this slot (I've not talked specifically about the Entry class, but it's basically a bucket for stuff you want to put into the ring buffer slot which has a sequence number), sets the sequence number on the Entry to the next sequence number (13) and returns this entry to your producer. The producer can then write whatever value it wants into this Entry.

Committing the new value
The second phase of the two-stage commit is, well, the commit.

The green represents our newly updated Entry with sequence 13 - yeah, I'm sorry, I'm red-green colour-blind too. But other colours were even more rubbish.

When the producer has finished writing stuff into the entry it tells the ProducerBarrier to commit it.

The ProducerBarrier waits for the ring buffer cursor to catch up to where we are (for a single producer this will always be a bit pointless - e.g. we know the cursor is already at 12, nothing else is writing to the ring buffer). Then the ProducerBarrier updates the ring buffer cursor to the sequence number on the updated Entry - 13 in our case. Next, the ProducerBarrier lets the consumers know there's something new in the buffer. It does this by poking the WaitStrategy on the ConsumerBarrier - "Oi, wake up! Something happened!" (note - different WaitStrategy implementations deal with this in different ways, depending upon whether it's blocking or not).

Now consumer 1 can get entry 13, consumer 2 can get everything up to and including 13, and they all live happily ever after.

ProducerBarrier batching
Interestingly the disruptor can batch on the producer side as well as on the Consumer side. Remember when consumer 2 finally got with the programme and found itself at sequence 9? There is a very cunning thing the ProducerBarrier can do here - it knows the size of the buffer, and it knows where the slowest Consumer is. So it can figure out which slots are now available.

If the ProducerBarrier knows the ring buffer cursor is at 12, and the slowest Consumer is at 9, it can let producers write to slots 3, 4, 5, 6, 7 and 8 before it needs to check where the consumers are.

Multiple producers
You thought I was done, but there's more.

I slightly lied in some of the above drawings. I implied that the sequence number the ProducerBarrier deals with comes directly from the ring buffer's cursor. However, if you look at the code you'll see that it uses the ClaimStrategy to get this. I skipped this to simplify the diagrams, it's not so important in the single-producer case.

With multiple producers, you need yet another thing tracking a sequence number. This is the sequence that is available for writing to. Note that this is not the same as ring-buffer-cursor-plus-one - if you have more than one producer writing to the buffer, it's possible there are entries in the process of being written that haven't been committed yet.

Let's revisit claiming a slot. Each producer asks the ClaimStrategy for the next available slot. Producer 1 gets sequence 13, like in the single producer case above. Producer 2 gets sequence 14, even though the ring buffer cursor is still only pointing to 12, because the ClaimSequence is dishing out the numbers and has been keeping track of what's been allocated.

So each producer has its own slot with a shiny new sequence number.

I'm going colour producer 1 and its slot in green, and producer 2 and its slot in a suspiciously pink-looking purple.

Now imaging producer 1 is away with the fairies, and hasn't got around to committing for whatever reason. Producer 2 is ready to commit, and asks the ProducerBarrier to do so.

As we saw in the earlier commit diagram, the ProducerBarrier is only going to commit when the ring buffer cursor reaches the slot behind the one it wants to commit into. In this case, the cursor needs to reach 13 so that we can commit 14. But we can't, because producer 1 is staring at something shiny and hasn't committed yet. So the ClaimStrategy sits there spinning until the ring buffer cursor gets to where it should be.

Now producer 1 wakes up from its coma and asks to commit entry 13 (green arrows are sparked by the request from producer 1). The ProducerBarrier tells the ClaimStrategy to wait for the ring buffer cursor to get to 12, which it already had of course. So the ring buffer cursor is incremented to 13, and the ProducerBarrier pokes the WaitStrategy to let everything know the ring buffer was updated. Now the ProducerBarrier can finish the request from producer 2, increment the ring buffer cursor to 14, and let everyone know that we're done.

You'll see that the ring buffer retains the ordering implied by the order of the initial nextEntry() calls, even if the producers finish writing at different times. It also means that if a producer is causing a pause in writing to the ring buffer, when it unblocks any other pending commits can happen immediately.

Phew. And I managed to describe all that without mentioning a memory barrier once.

EDIT: The most recent version of the RingBuffer hides away the Producer Barrier. If you can't see a ProducerBarrier in the code you're looking at, then assume where I say "producer barrier" I mean "ring buffer"

EDIT 2: Note that version 2.0 of the Disruptor uses different names to the ones in this article. Please see my summary of the changes if you are confused about class names.

Dissecting the Disruptor: How do I read from the ring buffer?

2011-06-28T19:57:00.005+01:00

The next in the series of understanding the Disruptor pattern developed at LMAX.

After the last post we all understand ring buffers and how awesome they are. Unfortunately for you, I have not said anything about how to actually populate them or read from them when you're using the Disruptor.

ConsumerBarriers and Consumers
I'm going to approach this slightly backwards, because it's probably easier to understand in the long run. Assuming that some magic has populated it: how do you read something from the ring buffer?

(OK, I'm starting to regret using Paint/Gimp. Although it's an excellent excuse to purchase a graphics tablet if I do continue down this road. Also UML gurus are probably cursing my name right now.)

Your Consumer is the thread that wants to get something off the buffer. It has access to a ConsumerBarrier, which is created by the RingBuffer and interacts with it on behalf of the Consumer. While the ring buffer obviously needs a sequence number to figure out what the next available slot is, the consumer also needs to know which sequence number it's up to - each consumer needs to be able to figure out which sequence number it's expecting to see next. So in the case above, the consumer has dealt with everything in the ring buffer up to and including 8, so it's expecting to see 9 next.

The consumer calls waitFor on the ConsumerBarrier with the sequence number it wants next

    final long availableSeq = consumerBarrier.waitFor(nextSequence);

and the ConsumerBarrier returns the highest sequence number available in the ring buffer - in the example above, 12. The ConsumerBarrier has a WaitStrategy which it uses to decide how to wait for this sequence number - I won't go into details of that right now, the code has comments in outlining the advantages and disadvantages of each.

Now what?
So the consumer has been hanging around waiting for more stuff to get written to the ring buffer, and it's been told what has been written - entries 9, 10, 11 and 12. Now they're there, the consumer can ask the ConsumerBarrier to fetch them.

As it's fetching them, the Consumer is updating its own cursor.

You should start to get a feel for how this helps to smooth latency spikes - instead of asking "Can I have the next one yet? How about now? Now?" for every individual item, the Consumer simply says "Let me know when you've got more than this number", and is told in return how many more entries it can grab. Because these new entries have definitely been written (the ring buffer's sequence has been updated), and because the only things trying to get to these entries can only read them and not write to them, this can be done without locks. Which is nice. Not only is it safer and easier to code against, it's much faster not to use a lock.

And the added bonus - you can have multiple Consumers reading off the same RingBuffer, with no need for locks and no need for additional queues to coordinate between the different threads. So you can really run your processing in parallel with the Disruptor coordinating the effort.

The BatchConsumer is an example of consumer code, and if you implement the BatchHandler you can get the BatchConsumer to do the heavy lifting I've outlined above. Then it's easy to deal with the whole batch of entries processed (e.g. from 9-12 above) without having to fetch each one individually.

EDIT: Note that version 2.0 of the Disruptor uses different names to the ones in this article. Please see my summary of the changes if you are confused about class names.

Dissecting the Disruptor: What's so special about a ring buffer?

2011-06-22T16:01:00.000+01:00

Recently we open sourced the LMAX Disruptor, the key to what makes our exchange so fast. Why did we open source it? Well, we've realised that conventional wisdom around high performance programming is... a bit wrong. We've come up with a better, faster way to share data between threads, and it would be selfish not to share it with the world. Plus it makes us look dead clever.

On the site you can download a technical article explaining what the Disruptor is and why it's so clever and fast. I even get a writing credit on it, which is gratifying when all I really did is insert commas and re-phrase sentences I didn't understand.

However I find the whole thing a bit much to digest all at once, so I'm going to explain it in smaller pieces, as suits my NADD audience.

First up - the ring buffer. Initially I was under the impression the Disruptor was just the ring buffer. But I've come to realise that while this data structure is at the heart of the pattern, the clever bit about the Disruptor is controlling access to it.

What on earth is a ring buffer?
Well, it does what it says on the tin - it's a ring (it's circular and wraps), and you use it as a buffer to pass stuff from one context (one thread) to another:

(OK, I drew it in Paint. I'm experimenting with sketch styles and hoping my OCD doesn't kick in and demand perfect circles and straight lines at precise angles).

So basically it's an array with a pointer to the next available slot.

As you keep filling up the buffer (and presumable reading from it too), the sequence keeps incrementing, wrapping around the ring:

To find the slot in the array that the current sequence points to you use a mod operation:

sequence mod array length = array index

So for the above ring buffer (using Java mod syntax): 12 % 10 = 2. Easy.

Actually it was a total accident that the picture had ten slots. Powers of two work better because computers think in binary.

So what?
If you look at Wikipedia's entry on Circular Buffers, you'll see one major difference to the way we've implemented ours - we don't have a pointer to the end. We only have the next available sequence number. This is deliberate - the original reason we chose a ring buffer was so we could support reliable messaging. We needed a store of the messages the service had sent, so when another service sent a nak to say they hadn't received some messages, it would be able to resend them.

The ring buffer seems ideal for this. It stores the sequence to show where the end of the buffer is, and if it gets a nak it can replay everything from that point to the current sequence:

The difference between the ring buffer as we've implemented it, and the queues we had traditionally been using, is that we don't consume the items in the buffer - they stay there until they get over-written. Which is why we don't need the "end" pointer you see in the Wikipedia version. Deciding whether it's OK to wrap or not is managed outside of the data structure itself (this is part of the producer and consumer behaviour - if you can't wait for me to get round to blogging about it, check out the Disruptor site).

And it's so great because...?
So we use this data structure because it gives us some nice behaviour for reliable messaging. It turns out though that it has some other nice characteristics.

Firstly, it's faster than something like a linked list because it's an array, and has a predictable pattern of access. This is nice and CPU-cache-friendly - at the hardware level the entries can be pre-loaded, so the machine is not constantly going back to main memory to load the next item in the ring.

Secondly, it's an array and you can pre-allocate it up front, making the objects effectively immortal. This means the garbage collector has pretty much nothing to do here. Again, unlike a linked list which creates objects for every item added to the list - these then all need to be cleaned up when the item is no longer in the list.

The missing pieces
I haven't talked about how to prevent the ring wrapping, or specifics around how to write stuff to and read things from the ring buffer. You'll also notice I've been comparing it to a data structure like a linked list, which I don't think anyone believes is the answer to the world's problems.

The interesting part comes when you compare the Disruptor with an implementation like a queue. Queues usually take care of all the stuff like the start and end of the queue, adding and consuming items, and so forth. All the stuff I haven't really touched on with the ring buffer. That's because the ring buffer itself isn't responsible for these things, we've moved these concerns outside of the data structure.

For more details you're just going to have to read the paper or check out the code. Or watch Mike and Martin at QCon San Francisco last year. Or wait for me to have a spare five minutes to get my head around the rest of it.

A chance to see some of my actual code (even if it is C#)

2011-06-20T09:28:00.002+01:00

Remember I posted about having to write .NET?

Well, the code and the tutorial are available for you, my lucky readers, to ~~rip to pieces~~ view.

I am not the only person responsible for this code though, so be kind.

Vote for the LJC

2011-06-14T16:39:00.001+01:00

I nominated LMAX for a couple of JAX Innovation Awards, but unfortunately we did not get shortlisted :(

However, the London Java Community did! So if you have a second please vote for the LJC for Top Java Ambassador

STAC London Summit

2011-06-12T20:55:00.001+01:00

On Wednesday I tagged along to the STAC London Summit to provide backup for Mike, who was on the "The Future of Messaging Middleware" panel.

The panel consisted of two messaging providers, one hardware (Solace Systems) and one software (29West/Informatica), and two "users", Citihub and LMAX. Obviously both providers were arguing that theirs was the best solution. But what I found interesting is that I came away with the impression that everyone was really on the same side - everyone wants to use or to provide the best system, but there are different approaches. Which one you adopt is likely to be influenced by how your team work and the hardware you have (or can obtain).

Mike touched on how we as developers need to do more than simply rely on fast messaging to provide our high performance. At LMAX, we keep banging on about mechanical sympathy and clean, well designed code to make sure we make the most of the infrastructure. He also got a dig in at JMS, which I don't think anyone disagreed with.

The main point I took away, however, is that although speed is very important in ultra high performance trading (of course), control is becoming almost more important: specifically configuration and monitoring. Because it's all well and good having a super-fast messaging infrastructure, but if you can't get it to do what you want, or you can't see what it's doing, where the bottlenecks are, or even if you're using it properly, it's a massive waste of cash.

Throughout later presentations and panels, and some chat afterwards, I picked up the configuration/monitoring theme a few more times. Fast is one thing, high availability is another, which should not be ignored simply for speed of execution.

Something else I heard a lot is how Java is totally unsuitable for high performance systems. Well... we'd like to disprove that. I guess we need need to get out there and start talking about why this is a myth.

I was impressed with the event actually. It was such a contrast to TradeTech, which was all vendors and boys in suits who couldn't wait to get to the pub. This summit hit our sweet spot - technology and trading. The presentations were aimed at people with both deep technical knowledge and a clear understanding of the business domain. It was somewhere we could talk quite comfortably about what we do, with a good mix of attendees who were seriously interested in the field.

Something I particularly liked was how the vendor pitches were kept to lightning talks - five minutes per pitch. This was an excellent idea. You got enough of a flavour to decide to find out more if it looked like something useful, but not so much you were bored or felt sold to.

The event was also a really good size, it seemed to encourage networking and chatting. People mingled more easily than at any of the other events I've been to recently, and not necessarily because they already knew each other. Mike and I were approached by a lot of people who were either curious to find out what LMAX did, or had already heard of us through some other channel. I even gave out a bunch of business cards, which finally justified the long, hard battle I had getting them ("Developers don't need business cards" apparently - but what if I meet a cute guy? How am I supposed to give him my number?).

The only disappointment was not delivering on promises. The agenda distinctly mentions cocktails. But instead there was simply wine and beer. I forgave them because the wine was decent and there was plenty of it.

In conclusion, I was impressed and definitely want to go to more of these events. We'd love to get more involved at presenting at some too.

My first public appearance

2011-05-30T21:18:00.000+01:00

I'm finally moving up from working behind the scenes to actually doing a (short) presentation for the LJC. I'm going to be giving a lightning talk on Wednesday at the AWS Elastic Beanstalk event, on the JCP - what it is and what our election to the executive committee means. Ben and Martin's post gives a little more background on the subject.

Another LMAX LJC member Mike will also be giving a lightning talk, on Project Coin.

Now all I have to do is write it...

Getting around a bit

2011-05-23T08:28:00.000+01:00

I'm honoured to now be listed on three aggregated blog feeds:

The new and somewhat embryonic blogs.lmax.com.
The London Java Community Aggrity.
ThoughtWorks Alumni, along with a whole host of distinguished names.

The pressure's on to try and write useful stuff. Oh OK, I'll settle for "entertaining".

Why Java developers hate .NET

2011-05-20T18:22:00.001+01:00

I have been struggling with .NET. Actually, I have been fighting pitched battles with it.

All I want to do is take our existing Java client example code and write an equivalent in C#. Easy, right?

Trisha's Guide to Converting Java to C#

Turns out writing the actual C# is relatively straightforward. Putting to one side the question of writing optimal code (these are very basic samples after all), to get the examples to compile and run was a simple process:

1. Find-and-replace the following (only you can't use Ctrl+R like I expect. Sigh.)

final = readonly (but remove from method params)
System.out.printf = Console.WriteLine
Map = Dictionary
BigDecimal = decimal
Set... oh. I have no idea.

2. When using callbacks, replace anonymous inner classes with delegates

Java

something.doSomething(new SomethingRequest(),
  new SomethingCallBack()
  {
    public void onSuccess()
    {
      System.out.println("Action successful");
    }
  
    public void onFailure()
    {
      System.err.println("Action failed");
    }
  });

private void foo ()
{
  _something.DoSomething(new SomethingRequest(), 
                         SomethingSuccess, 
                         SomethingFailure);
}

private void SomethingSuccess()
{
  Console.WriteLine("Action successful");
}

private void SomethingFailure()
{
  Console.Error.WriteLine("Action failed");
}

I rather like this pattern actually. You can't really tell in the noddy example above, but the C# code is generally shorter and more reusable.

3. Replace getters and setters with properties

Java

private class MyClass
{
  private BigDecimal myField = new BigDecimal("-1.0");

  public BigDecimal getMyField()
  {
    return myField;
  }

  public void setMyField(BigDecimal instructionId)
  {
    this.myField = myField
  }
}

internal class MyClass
{
  public decimal MyField{ get; set; }
}

What the... where did all my code go??

My Thoughts

I was pleasantly surprised with the language. In general, for what I was doing, the equivalent C# was a lot less code. The fact that the syntax is not wildly different from Java made the transition relatively easy, even if I don't get all the nuances.

I didn't really like the enums - I can see what purpose they serve, but I quite like the way the Java ones are pretty much classes in their own right with properties of their own - it allows you to encapsulate some of your simplest domain objects. But it's a minor point, not a deal-breaker.

The C# capitalisation makes me queasy though. I just can't get my head around it. In Java, if I say:

com.mechanitis.foo.Bar

I know the class is Bar and the rest is the package (or namespace, or whatever). This is more useful when you're using static methods and so forth:

com.mechanitis.foo.Bar.thatThingIWantToDo()

In C#, I know the thing at the end is a method and the thing before that is a class, but it doesn't jump out at me:

Com.Mechanitis.Foo.Bar.ThatThingIWantToDo();

And if you're using a property:

Com.Mechanitis.Foo.Bar.MyProperty;

The whole thing makes me dizzy.

You could argue that all this is redundant with modern tools and IDEs doing all the heavy lifting for you - nice colourisation etc.

Which brings me to The Rant.

Oh My Dear God What Is Wrong With Visual Studio?

C# needs to be a shorter, more succinct language because it takes three billion times longer to do anything in Visual bloody Studio.

I'm coming at this from a Java, IntelliJ point of view, so there's always the possibility it might be lack of familiarity with the tool, rather than the tool itself, which is the problem. It's a long time since I used VS, and that was back in the 90s when I was doing ASP and COM (shhh, don't tell anyone).

But things shouldn't be this hard. I was ready to accept, due to my newbie status, the IDE not helping me. I didn't expect it to actively hinder me.

For example: it took hours of my life that I will never get back to discover that you can't simply run a class that has a main method by right-clicking and selecting "run" (note: I'm not even trying Ctrl+F10). No. I have to select, at a Solution level, which Projects are runnable. Then I have to select at the Project level the class with the main method I actually want to run. Then, it opens up a terminal window and runs it in there, which promptly disappears when the program errors or finishes. What's wrong with outputting in the output window of the IDE? Is that not what it's for?

Finally I worked out how to run the cursed program (seriously, like that's not the first thing everyone wants to do? How do people write "Hello World"?). Now, where are the command line arguments? Of course, they're at the project properties level too, because each project only has one entry point. I seriously had to Google that too because I couldn't work it out from the IDE alone.

The next day, my ReSharper licence had expired. I decided I should attempt to limp on without it, after all hundreds of developers must be surviving with just Visual Studio. How bad could it be?

Very bad, it turns out.

All those helpful little squiggles I was leaning heavily on to convert my Java to C#?

The red to tell you you're utterly wrong.
The orange to tell you could be using less code.
The blue to remind you to stop thinking in Java and helpfully offer corrected naming.
The green to suggest stuff that C# could do differently.

Yeah, all gone.

How do people code like this? Do they really just do a build to check if it's all wrong or not?

Next, I try to find a class. I actually have no idea how to do this, because I can't use Ctrl+N. So I Ctrl

I realise this is a waste of time anyway, because one thing that really annoys me about Visual Studio is that I can't find a way to sync the project tree to the class file I'm looking at. I can't get it to jump to highlight where I am. When I'm using IntelliJ, I find this dead useful when I want to see other stuff in the same package.

Less than ten minutes after attempting to use Visual Studio without ReSharper, I've abandoned the fight and tracked down a licence and installed it.

Documentation isn't a standard function of .NET?

What sort of message does this give developers? Documentation isn't important?

I always thought Javadoc was pretty ugly and clunky. In addition, now our IDEs generate so much, it's frequently meaningless. But it is generated by standard Java tools, and HTML is a standard format that can be read on pretty much any computer with any operating system.

I could not believe how hard it was to get the XML comments out of the C# into something the user can actually read. Thank goodness, some enterprising member of the team had already done that for us. All I needed to do was hack/crowbar the tutorial I'd been working on into the generated documentation, so it ended up in the Windows help files in some fashion.

I know there's a way to get HTML/XML files into the end result using Sandcastle, but hours of Googling only told me it was possible, not how to do it. I still have no idea what the correct question is to ask to find the solution.

Right now, this is an unsolved mystery. Our .NET client users will have to read the plain HTML I'm afraid.

In Conclusion

Are we lowly Java developers spoilt with our shiny IDEs?

Or is there such a fundamentally different approach to development for .NET people that all the functionality is there, I just can't find it?

I'm disappointed if I'm honest. I'm sure the .NET camp used to tout their tools as their superiority. I ended up feeling sorry for the poor NET people. Is there anything they can use that isn't Visual Studio?

In Conclusion: Despite the nasty capitalisation I found myself surprisingly taken with C#. But until they can give me a proper development environment, I won't be tempted by the dark side any time soon.

The London Java Community elected to the JCP SE/EE Executive Committee

2011-05-16T18:20:00.001+01:00

As an associate member of the London Java Community (LJC), I'm very pleased with the news that we won an Open seat on the Java SE/EE executive committee. The results show that we got an astonishing 47.5% of the vote - if an MP got voted in with that percentage the newspapers would probably be using the word "landslide".

It's quite exciting to be one of the two user groups involved. We hope to balance some of the larger corporate organisations, we're the voice of real life Java developers who use the language every day, for enterprise development or open source projects.

You can argue Java is dying, but the community is not. And I think we're exactly the people to guide its future.

PS (Warning: gratuitous plug incoming) If you're at all Java-curious and you like drinking and attempting to be social, join us this Tuesday for our monthly Developer Sessions at the Porterhouse in Covent Garden.

Cyclist tribes

2011-04-26T13:26:00.000+01:00

Living and working in central London, you quickly learn that the fastest way around town is to cycle.

My extensive research into this activity has shown there are a number of different cycling tribes. Of course, I have split them into the two groups that are most appropriate to me: 1) slower than me and 2) faster than me. You can probably tell what sort of a cyclist I am by my attitude to the two groups.

1. Slower than me:

Wicker shopping basket. Doesn't matter what the rest of the bike looks like, or the biker, I will always try to get ahead of these. The extra scary ones are the women in flowing dresses who might be university professors.
Boris Bikes. When there's a tube strike, Avoid At All Costs. These people probably haven't been on a bike since they were in school, and it shows.
Hoody (always a male) on a BMX-style bike with the seat far too low, riding in too low a gear, with baggy jeans that show their... well... everything. Never have lights on their bikes. Always has a satchel / record bag for maximum inappropriately-dressed-for-cycling points. These buggers are a pain because they never obey traffic lights and will join the road from the pavement on either side, cutting you up in the process. Getting past them is easy, keeping them behind you is much harder.
Not wearing a helmet. Probably not a serious cyclist, so probably easy to overtake. A similar category to the hoody, doesn't obey traffic laws and enormously unpredictable. Otherwise known as an organ donor.
Wearing a skirt. Of course, this doesn't apply to me. In the same category: jeans, sandals, high-heeled shoes (not all at once).

2. Faster than me:

Cleats. If you have cleats on the bike I'm going to let you go first from the lights. You'll be fast and possibly suicidal when weaving through traffic.
Lycra, especially on a guy. Even if they're not faster than me, they will always overtake, and always pull in front of me at lights. It's an ego thing. Something about those tight shorts possibly.
Panniers. Generally, but not always, a “proper” cyclist, even if they're on a rubbish bike. These guys have experience.

One to watch: businessman in a suit on a Brompton. You can't trust these guys, they can be deceptively fast. It's always embarrassing to be overtaken by them. How do they not sweat into their Armani?

Who does that leave?

Well, my lot: helmet, high vis jacket, shorts (knee-length with pockets). Usually obeys the lights, quick enough, some unpredictability when over-/under-taking. Most of these guys will weave to some extent, but not suicidally. My tribe is probably one of the biggest, and it leads to lots of subtle negotiation at traffic lights - sizing each other up - checking the bike, the kit, the shoes - to decide whether or not to pull ahead or drop back.

But I mess with people's heads in summer by occasionally wearing a short skirt (with shorts underneath, I'm not out to cause accidents) and wedge sandals, and cycling at 20mph.

I hate to conform to expectations.

TradeTech 2011 - Not like a developer conference

2011-04-18T09:25:00.000+01:00

I attended TradeTech last week, an annual event about Equities and Derivatives trading. I assumed from the title that there would be a reasonable focus on technology, but I found it was more “Trade” and less “Tech”.

The fascinating thing to me was how different this is from the sorts of technology conferences I've been to. For example, I popped into JAX this week (albeit in the evening for drinks). At technology conferences (<gross-generalisation>) people tend to subscribe to a variety of dress codes and fashion clans, usually from jeans through the range of business casual, including your fair share of goths and alternatives. Suits would be unusual (</gross-generalisation>). At this place, people were scarily conformist. A few years back, the suits at least would be different colours – navy, greys and black – and may or may not include pin stripes. On Thuresday, almost everyone was wearing a particular shade of tasteful dark grey.

I was also pretty shocked at the time people snuck off to go to the pub. Don't get me wrong, I'm all in favour of imbibing alcoholic beverages as frequently as possible. And I prefer networking in the pub to poncing around in some conference centre. But I feel it's Bad Form, and I was surprised (and a little bit jealous) that it seemed to be the norm. I felt for all of the later presenters.

Still, I showed my support for them and I turned up to some actual presentations. The most interesting ones to me were Baroness Eliza Manningham-Buller talking about her time as head of MI5, and Richard Peterson going Inside the Trader's Brain.

The Baroness was talking about leadership during times of crisis – she was in charge shortly after 9/11. What I found interesting, and resonated with me, was her focus on her people. An intelligence organisation is all about the people who work for it. She stressed that it was important to bring fun into the work place, especially because it was a particularly traumatic period to be working. She instigated family days and helped the employees show their families what it was they did. I'm not quite sure how much they could show, given the nature of that industry. But I liked that she understood the people were more than just minions, workers in a hive, that they had families and that they wanted to be proud of their work and share it with the significant people in their lives.

She also refused to take credit for anything for herself, but talked about her team, about the people around her and in the organisation. I like leaders who recognise that it's not all about them.

The thing that stuck with me the most is she said that leaders who take themselves too seriously are not taken seriously by their underlings.

Richard Peterson's presentation was about the risk-taking and risk-avoidance areas of the brain. He showed how your risk-taking behaviour is influenced by bias, and how subtle it is. There was a lot of interesting stuff in this, which scratches my random-interest-in-psychology itch, and confirms what I've been reading/hearing about how behaviour can be triggered and changed.

Ultimately he gave some advice for how to reduce the impact the rest of the world might have on your trading strategy, which is applicable to all of us:

Maintain healthy routines
Take time to reflect daily
Letting go
Gratitude

The ulterior motive for me to be at TradeTech was to watch my boss's “How To Do 100,000 Transactions Per Second At Less Than 1 Millisecond Latency?” presentation. This was a cut-down and updated version of the one he and Mike gave at QCon last year. If you are at all interested in concurrency, high performance, or programming generally, it's well worth the hour to watch it. It outlines the architecture we use at LMAX to get very high performance from our exchange without using anything particularly special in terms of hardware. All it takes is good design and something Martin calls mechanical sympathy.

Anyway enough corporate plugging.

Overall I came back from TradeTech with lots of ideas of things I wanted to do at work and ways to help us market the platform in future. I also came back with a certain cynicism for these types of very vendor-heavy events. However, I did meet some interesting people, and it was a different crowd to my usual technical comfort zone.

And it did get me thinking, which is really all these things should do.

CSS for Developers: Horizontal and Vertical Centring

2011-04-12T10:48:00.000+01:00

First, an apology. I will be using the British spelling for "centre", because, well, I'm British. But it gets really confusing because you have to use the American spelling in the code. And doesn't "Centring" just look wrong?

Part Five: Horizontal and Vertical Centring

One of the most common things you want to do with blocks of content is to centre it. In particular, you would think that vertically centring content would be straightforward, but it turns out that in HTML/CSS it just isn't.

5.1 Horizontal Centring
Centring a paragraph of text is clearly easy - all you need is text-align: center. However, sometimes you want to centre a block, something like a div, without having all the text centred as well. This is slightly trickier than you might expect, because the only CSS attributes you have are for centring text.

<html>
<head>
    <title>Horizontal Centering</title>
    <style type="text/css">
        #div1, #div13 {
            background-color: #DDDDDD;
        }

        #div2, #div14 {
            background-color: #BBBBBB;
        }

        #div3, #div15 {
            background-color: #999999;
        }

        #container, #container5 {
            border: 1px solid black;
            margin: 5px;
        }

        #container5 {
            text-align: center;
        }

        #to-center {
            margin-left: auto;
            margin-right: auto;
            width: 200px;
            border: 5px solid red;
        }

        #to-center2 {
            margin-left: auto;
            margin-right: auto;
            width: 200px;
            border: 5px solid red;
            display: block;
            position: relative;
            text-align: left;
        }

    </style>
</head>

<body>
<div id="container">
    <div id="to-center">
        <div id="div1">One</div>
        <div id="div2">Two</div>
        <div id="div3">Three</div>
    </div>
</div>
<div id="container5">
    <div id="to-center2">
        <div id="div13">One</div>
        <div id="div14">Two</div>
        <div id="div15">Three</div>
    </div>
</div>
</body>
</html>

Using margin-left: auto and margin-right: auto on the block you want to centre is a neat trick for doing this. And it works fine in Chrome and Firefox. However, it's not so great in IE 7:

The trick for getting it centred here (the second block) is to set text-align: centre on the div containing the block to centre (container5), then reset the text-align to left on the centred block (to-center2) so the text isn't centred. Yes, a total faff.

However, there is some good news. You can get IE to behave the same way as the more sane browsers by setting it into Strict Mode:

Remember kids: Strict Mode Is Your Friend. And all you need to do is add the following to the top of your HTML file:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

5.2 Vertical Centring

<html>
<head>
    <title>Vertical Centering</title>
    <style type="text/css">
        #div1, #div4, #div7 {
            background-color: #DDDDDD;
        }

        #div3, #div6, #div9 {
            background-color: #999999;
        }

        #div5 {
            height: 40px;
            line-height: 40px;
            background-color: yellow;
        }

        #div2 {
            height: 50px;
            background-color: orange;
            vertical-align: middle;
        }

        #div8 {
            height: 40px;
            line-height: 40px;
            background-color: cyan;
            font-weight: bolder;
        }

        #container1, #container2, #container3 {
            border: 1px solid black;
            margin: 5px;
        }

    </style>
</head>

<body>
<div id="container2">
    <div id="div4">One</div>
    <div id="div5">Two</div>
    <div id="div6">Three</div>
</div>
<div id="container1">
    <div id="div1">One</div>
    <div id="div2">Two</div>
    <div id="div3">Three</div>
</div>
<div id="container3">
    <div id="div7">One</div>
    <div id="div8">Massive line of text that needs to wrap to show the centering totally doesn't work when you have more than one line of text.</div>
    <div id="div9">Three</div>
</div>
</body>
</html>

Given some of the problems with horizontal alignment, it shouldn't come as a surprise to find vertical alignment is not simple at all.

Us straightforward developer types would expect to be able to put vertical-align: middle on a div and expect all content inside that div to be, well, vertically aligned in the middle. However this is not the case - see the orange block above. A quick Google will tell you why this doesn't work, and I don't intend to duplicate the explanation here.

There is a nice hack which works for single lines of text though: if you set the height of the container and the line-height to the same value, the text will be vertically centred within that container (see the yellow panel, div5, above). This works really well for things like buttons or icons.

However, it doesn't work so well for paragraphs of text or sentences that might wrap, line-height is for a single line of text only. See the cyan panel above for what happens if your text wraps.

I'd love to give you an answer on how to get this to work for text that wraps, but I haven't found a satisfactory solution yet. What I usually do is set a fixed height on the container and then set the margin on the text so that it sits in a way that looks vaguely centred. Not a solution I'm happy with, because a) it can sometimes render slightly differently on different browsers b) it's a very fragile solution if you're going to internationalise your page as some languages will have longer or shorter paragraphs and c) it feels like a massive hack.

If anyone has a nice solution for vertically centring paragraphs of text I'd love to hear it.

How to show your employees how much you hate them

2011-04-04T08:17:00.000+01:00

Due to a combination of my restlessness, my consulting experience, and employers that insist on moving offices frequently, I've had the dubious honour of working in a variety of environments.

Today I will teach you, the employer, how to show your staff just how much you hate them.

The Kitchen Is Not For Eating In
Since eating and drinking is unfortunately a fundamental part of being human and staying alive, you will need to provide your staff with a space that pretends to address these needs.

The best example I have seen so far has been a "kitchen" with: no sink; no kettle; no microwave; a tiny under-counter fridge for employee food (for approx 50 employees); nowhere to sit and a maximum capacity of 3 people standing. You're probably wondering how I knew it was a kitchen. Well, it had a counter top. And a coffee machine which also dispensed slightly warmed water. And The Largest Drinking Water Dispenser In The World¹.

The most important thing to remember here is that This Is Not A Communal Space. Heaven forbid that your minions actually talk to each other.

For bonus points: if you really want to show your code monkeys how much you despise them, you can dispense with the coffee machine entirely and supply only Nescafe Gold Blend instant coffee. Honestly, developers don't care what form their caffeine comes in².

The Importance Of The Loo/Bathroom/Restroom
(Note for our North American brethren - there's no bath in there and I certainly don't go there to rest. Can we call them toilets and be done with it?)

If the cubicle door looks like it's already come off the hinges a couple of times and been sellotaped back on, if the cubicles are made of plywood, if there's a genuine chance that someone could get trapped in there by the dodgy door lock, if the loo paper is that tracing paper you used to get in school, perfect. You've managed to convey to your staff just how little they mean to you. If you have been successful in this, your employees will show you exactly how they feel about you by the state they leave the bathrooms in.

For bonus points: don't pay the cleaning staff enough so the paper and towels aren't replaced frequently.

The Office Canteen Is Also Not For Eating In

If you've done your job correctly with the kitchen and the toilets, your employees are probably desperate for somewhere they can congregate. You must not allow this - if they get together, they could have Dangerous Conversations, where they Share Ideas and Collaborate.

A rookie mistake would be to not provide a canteen at all. Do not fall into this trap! If you don't provide food on site, your staff will leave the building, and who knows where they're going to go, what they'll get up to, who they might meet? No, you want to provide them with facilities you control.

However, you want them to go to their miserable little cubicles to eat, so make sure there isn't enough space for them to sit in the canteen. For best results, provide a couple of tables and chairs but ensure they're always filled. That gives them elusive hope that maybe, some day, they will be the ones on that table.

For bonus points: have a separate management restaurant. This should be visible enough that your employees are aware it exists and that it's better (table service, for example), but private enough that it becomes a mythical place. Then you must make sure they know, every day, that they are not allowed to use it.

Go For Tones Of Grey And Brown
Nothing says "your life is worthless" like a 1970s-council-style-office. If it's made of concrete and has laminated mirrored windows, so much the better. To go the extra mile, put up 10 foot high "inspirational" photos of people playing on beaches, in black and white. That way your employees will remember that there is an exciting world out there, but they can't get to it, and they can't even enjoy it by proxy in this miserable, monochromatic office.

For bonus points: your cupboards should all be laminated Formica, in murky brown.

Reduce Natural Light Sources
I used to think that working in a basement was the worst fate that could befall me. After I did it twice, I swore to never again work in an office with no natural light.

However, there is an even more devious way to make your staff miserable. Ensure there are windows in the office, nice big ones. Then build cubicles throughout the floor, so that your employees can see there is a window, but they cannot see out of it, or receive any actual light from it. Watch them pine and fade away, or fight over the desks close to the window.

For bonus points: make sure the people closest to the windows have their monitors angled for maximum screen glare. Then these unfortunates will close the office blinds voluntarily, and really minimise vitamin D production in your minions.

Provide Beds/Bedrooms In The Office
Now, you might be thinking that this is a little cushy for your minions. I can assure you, the drain on morale is worth it. By providing beds, you don't have to shell out for expensive hotels for visiting employees, or for taxis for those who have to work late. It gives your staff the message that they belong to you, you even own their sleeping hours.

For bonus points: put the bedrooms on the Management Floor (you know, that special floor for those who have Made It), so that your lowest-level employees have to walk through this opulent splendour in order to grab a couple of hours of poor quality sleep, before being herded back into their cubicles to put in another 20 hour day.

In Conclusion
It doesn't matter what size company you are, by following some or all of these rules you can successfully communicate to your Peons just how meaningless their little lives are to you. Large companies seem to be particularly good at this, but a determined start-up can also alienate all three of its employees if it tries.

By showing your staff how much you hate them, you are sure to attract and retain the best quality people, and motivate them to work hard and efficiently to realise business value for you.

Oh wait....

¹ It was the size of a wardrobe. All it did was filter and UV "purify" tap water. It also claimed to be smart, it would dispense a cup if you needed one and detect if you didn't. It attempted to determine the size of the container you placed in it and fill it appropriately (and failed every time). It would tell you how many seconds were left until it had finished filling your vessel, but not give you the option to stop it, or to continue for longer. Seriously. A tap would have been fine.

² In case you don't know - they really DO care.

For those who might want to make the leap from Developer to Architect

2011-02-14T21:42:00.002Z

The last two weeks, actual work has conspired to keep me away from the blog. How rude. I miss "the beach" already.

It seems only fair to summarise the lessons I have learnt whilst masquerading as an architect on a short consulting stint with Marc McNeill. Simon Brown at Coding the Architecture is much better at talking about this stuff than I am, but I need to update the blog with something!

1. Ask dumb questions
Someone's called you in because they want your help, and presumably if their problem was simple they would have fixed it already. You're not there to know everything out of the box, you're there to find out what's going on and summarise it. That means asking questions, even the dumb ones. That's something I learnt off my previous boss.

2. Draw lots of pretty pictures
As a developer, I like to think in code, I like to poke around it to find out what's going on. But if you want to get a feel for the bigger picture, not having access to the code, or even the documentation, could be better. It forces you to look beyond the detail. Sketch things out on the whiteboard to help get the picture of the domain and the systems in your head.

Of course, there's always the worry that your pictures aren't the reality. That's why you need to...

3. Check your theories/pictures/numbers with everyone
In the first week of the engagement I made some assumptions based on the information I had gathered so far. Once I'd run those past the architects and developers really working on the code, I found they were only half the story. The feedback from those guys helped evolve the picture of the current state of play, and shaped the future direction.

4. Take notes
Especially of acronyms used and people's names and roles.

This is probably more a "me" thing. My memory works as an index, so I need the detail somewhere - I can remember I wrote something about something, and where I wrote it, but I won't remember the details. I also find that simply writing things down helps to get it straight in my head. I probably didn't use 50% of my notes, but all that information was in my head.

5. Buy your own whiteboard pens!
I've worked in a lot of places, as a consultant and a permanent employee. And one thing you can almost guarantee is that the pens in your meeting room will not work. Or they'll be permanent.

I also bought a board rubber and spray cleaner, but that's probably my OCD....

At the end of an intense two weeks we had delivered:

A picture of the existing architecture
Pictures of three phases of future architecture
An approximate roadmap for delivery
Guide estimates for the stories discovered
...and pages and pages of supporting diagrams and information.

The air in Les Alpes must've helped get the brain moving! Of course, I took my camera on my little jaunt to France.

It was a great first role for me at ThoughtWorks. I worked my socks off and thoroughly enjoyed it.

CSS for Developers: Cross Browser Table Border Behaviour

2011-01-28T10:53:00.001Z

One of the aims of this series is to highlight some stupid gotchas in support for CSS in the different browsers.

Today's gotcha is table borders.

Yes, yes, I said don't use tables. What I means is, don't use tables for layout. But you can use tables for, you know, tabular data. Like, for examples, lists of instruments and their bid and ask prices.

But you should know that even when you use strict mode, Internet Explorer has slightly... eccentric... rendering behaviour for tables. Actually to be specific, it's IE7 only.

<html>
<head>
    <title>Table Borders</title>
    <style type="text/css">
        table, td {
            border: 1px solid black;
        }
        td {
            height: 20px;
            min-width: 5px;
        }
    </style>
</head>

<body>
<table cellpadding="0" cellspacing="0">
    <tr>
        <td>first cell</td>
        <td>second</td>
    </tr>
    <tr>
        <td>
            <div></div>
        </td>
        <td>
            <div></div>
        </td>
    </tr>
</table>
</body>
</html>

The HTML here is a simple table with a border round all the cells (using CSS border, not the deprecated border attribute on the table) - a fairly common situation.

This is how it renders in IE7:

Note the distinct lack of a border around the lower two cells. If a table cell is empty, or contains a div which is empty, IE doesn't render the cell at all.

The cheat to get around this is to add   into every empty cell - either inside the div, if there's a div in there, or inside the td if there's nothing else in there. Then IE wakes up and remembers to render the borders.

My Experiences with Android Development

2011-01-27T09:56:00.001Z

Because I was missing coding, and because my friend and I had an awesome phone app idea at the weekend, I thought I'd try my hand at developing an Android application this week.

I want to give a quick overview of my preliminary thoughts on getting started on this endeavour.

Background: I've got more than 10 years Java experience, but any UI for the applications I've worked on was always a web UI. I am completely new to mobile app development.

Getting Started
I spent maybe a day and a half reading the excellent Android developer documentation and attempting to hack out a quick 'droid app.

I was surprised to find the Application Fundamentals section actually made sense to me. There appears to be a clear architecture with design guidelines laid out for developers to follow. This shouldn't really be a surprise I suppose, but years of hacking around with web UIs with poorly implemented MVC architectures must have left me thinking that all frameworks are less "frame" and more "work".

Setup
I remember the disaster of trying to get my first JDK working on my 486 - what a nightmare! And getting Tomcat 3 installed and running? Forget it. I also remember the last time I made a serious stab at a learning a new technology. I tried develop a Grails/Groovy application in Eclipse. The IS guys had to rescue my laptop from me during that enterprise before I could do it any serious damage.

Installing the SDK on my mac was surprisingly simple, especially bearing in mind I'm new both to OSX and to mobile development. I don't know if it's because Android development has been well thought out and well supported, or if it's a function of both the industry's maturity and my own experience.

The integration with IntelliJ was much slicker than I expected, especially since I'm using the freebie Community edition. I don't remember the exact steps to tell it I wanted to create an Android project, but it must have been ridiculously easy otherwise I would remember the trauma. I do remember a little confusion around installing the Android platform - I hadn't understood the difference between installing the SDK and then installing a specific API for it. But the documentation and the android application got me on the right track in the end. And then when I clicked the "run" button in IntelliJ, hey presto! The emulator appeared and there was my app!

I loved the emulator. I had some confused idea that I would have to plug my own phone into the laptop to see my application. Instead, the emulator looks enough like my actual phone to give me decent feedback on how the app is going to behave. The downside is I was trying to play with the camera, and I couldn't see how that would really work in the emulator, but I got a fair idea.

Did it work?

I managed to get a rudimentary application running, with a button and some descriptive text (it's not about to win any awards). The button was supposed to launch the camera viewer, but my first few attempts just resulted in the crash notification. It didn't take long to figure out how to use logcat to see the stack trace and see I hadn't set the permissions correctly to use the camera, so I rooted through the CameraPreview example in APIDemos to figure out how to set up the AndroidManifest.xml correctly, and rather amazingly it all worked!

Any downsides?

I was surprised (and slightly disappointed) at the amount of XML configuration. I've seen plenty of evil Spring and Ant XML in the enterprise and I thought frameworks were moving away from that. The manifest I can understand I suppose, but it felt a bit weird to be defining the UI in XML. It seemed like a bit of an afterthought tagged on after all the well-defined architecture behind the scenes.

But maybe this will make more sense to me as I develop my application further.

In Summary

I was pleasantly surprised to be able to get an Android application (albeit a very basic one) working in only a few hours.
Development in IntelliJ was much easier than I expected.
The documentation is actually very good.

We'll see how I feel about it when I start trying to do more than a very simple example application.

CSS for Developers: Column Layout Using CSS

2011-01-25T09:08:00.000Z

This is a continuation of my series of CSS hints / tips / cheats for developers (and other technical-but-not-UI people).

The screenshots are in Chrome on a Mac. The originals were on Firefox on Ubuntu so I can tell you the behaviour is identical.

Part Three: Column Layout Using CSS (or: still no excuse to use tables)

Today's example is a simple one, but worth knowing all the same. The aim is, once again, not to use HTML tables to provide any sort of layout. In most cases not only does using a div reduce the size of your DOM (and potentially help improve the performance of your page), it's actually a lot less complicated to organise your layout this way.

3.1 Display Elements or Text in Columns

<html>
<head>
    <title>Column layout</title>
    <style type="text/css">
        #col1 {
            background-color: yellow;
            /**have to know the width **/
            width: 30%;
            float: left;
        }
        #col2 {
            background-color: lightBlue;
            width: 30%;
            float: left;
        }
    </style>
</head>

<body>
<div id="col1">
    <div>1</div>
    <div>2</div>
</div>
<div id="col2">
    <div>3</div>
    <div>4</div>
</div>
</body>
</html>

Again you can see we're using float on the divs to get them to appear side-by side.

The code is much more intuitive organised this way - everything from a single column is grouped together in a single div. If this was done using tables, you'd have the content for a single column scattered in different cells on different rows of the table. Re-arranging the order of the columns in the case of tables is much more of a pain in the neck. With a div, it's a simple move.

On Changing The Image Of Programmers

2011-01-24T09:54:00.000Z

Gah!! This is exactly what I was talking about - it's pink, it mentions shoes, and it's about as patronising as you can get.

Would the chart be different if your possible outcomes were Bill Gates, Steve Jobs, Mark Zuckerberg, and Linus Torvalds? I bet for a start it wouldn't mention Jimmy Choos or choice of handbags. And it probably wouldn't be in baby blue either.

Which leads me nicely onto the next subject I have strong opinions on: Role models. Why do we need them? Do we need them?

If there is any good to be salvaged from that horrific infographic, it's that it gave me what I've been trying to research - some female role models in technology. Unfortunately it hit the other button I was ranting about earlier - they're all very presentable and polished. I don't doubt their value as role models, it's great to have people like that to try and emulate. But surely there must be IT women out there who look like real people? And how many of them started as programmers? I know there's a wider issue around women in technical professions, and women at the top of organisations in any business domain, but I'm trying to keep focused on the issues faced by girl programmers specifically.

Do we need role models?
I feel almost a responsibility to be a role model. I joined ThoughtWorks because I felt it would give me a better platform for greater visibility, so I could show that girls could do this job. I feel passionately that the industry desperately needs excellent role models to overcome the stereotypes kids are absorbing (in our western society) about what it means to be a programmer(/developer/techy).

My friend Mazz feels quite differently. She doesn't see why she should have a greater responsibility to be a role model simply because of her gender. It wouldn't be expected of her co-workers. She suggests that by making a career in programming an option for all, or worse, by targeting specific groups (e.g. women) we're devaluing the industry. Surely we're stronger if we only attract people who are interested in the first place?

During a week long trip to Vegas (it's a hard life), Mazz and I realised we actually agreed on fundamentals:

Mazz doesn't believe we need female role models to tempt women into programming
I believe we need more diverse role models than we currently have.

If Mazz doesn't want to be a role model because she's perfectly happy getting on with doing her job bloody brilliantly, then that's totally cool - after all, if minorities are expected to do stuff which distracts them from their day job, it's going to make them less appealing to employers.

My aim in being a role model was not specifically to get more girls into programming, but to show to the world that we're not all speccy asexual white boys. Some of us are speccy white girls. And this shows the ridiculousness of trying to encourage girls to be role models - you've only changed one dimension. And having a token bisexual black disabled older lady is only going to narrow the field you're appealing to.

So what do we need to change?

Back to the question that started this off - "what do we need to do to encourage the girls?". The answer, it would seem, is not to roll out the girls, dress them up and parade them around. After all, we got here with no female role models. And we may very well have been put off by role models like us - a teenage Mazz and a teenage Trish would probably not identify with the heel-wearing blonde I've become, despite my all-round awesomeness.

When I worked at Ford they used to tell us a story about marketing. They told us that Harley Davidson understood that to market something, you had to market it at the person your customers wanted to be. A Harley is a statement, a lifestyle choice. They focused on promoting that lifestyle, promoting the image of the Harley biker, all leather and macho attitude. They knew that the majority of their customers were CEOs, lawyers, doctors. Guys who'd made it in life and had the cash to spend. But if they'd marketed Harley Davidson directly to the stereotypes of these guys they would have lost their market. These men did not buy a Harley as part of their CEO persona. They bought them because they aspired to be the leather-wearing macho guy.

I don't know how true that story is, but I do know Harley Davidson revitalised their failing business by focusing on creating a community around their brand.

So back to the question: How do we get more girls into programming?

And the answer is: We're asking the wrong question.

The real question is: How do we attract more than just the "typical" geeks into programming?

And when you ask that question, you realise it's absurd to assume that attractive female role models and women-centered events are going to fix the problem, or even make any significant headway on it. You're narrowing your field of appeal instead of broadening it. You're being exclusive instead of inclusive.

Where can we find appropriate role models to represent us?

We have diversity amongst geeks. We've got diversity along the typical dimensions (age/race/sexuality/gender etc etc). But in addition we're all individuals and we're going to appeal to other individuals. I might appeal to someone who likes shoes. I might appeal to someone who likes photography. I might appeal to someone who thinks Java developers should give a toss about the user experience. I might appeal to someone who is massively OCD about the names of their variables.

We shouldn't care what little boxes those people tick on the dimensions that make absolutely no difference to their ability to program. In fact, if we focus less on this and more on our general awesomeness as geeks, we might find so-called minorities are happier to represent us.

Even with diverse role models we might have trouble getting the media to let go of their stereotype of the geek programming in their bedroom. But we might not - I did a search for "geek" on The Sun's website, and I found a lot more references to geek chic, and celebrities claiming to be geeks, than to stories of the lonely computer programmer who went crazy and killed everyone.

It is the time of the geek. Let's ride the wave and bring other people to the party.

So who should our role models be?

Everyone.

All of us.

You.

GWT: Why VerticalPanel is Evil

2011-01-21T11:10:00.000Z

At LMAX we adopted Google Web Toolkit pretty early on. One of the motivations for using it was so we only had to worry about recruiting Java guys, and then we could all work on every part of the application including the web UI. Sure, you can learn a bunch of different skills if you want to, but it reduced context-switching and kept the skill set we were hiring for to a nice short list.

The problem is that GWT does a very nice job of pretending to be Java whilst actually compiling down to HTML and JavaScript. If you don't have some understanding of the end result (the DOM the browser is going to be rendering) it's going to be hard to get the performance you need from a low-latency trading application.

My number one bug-bear with GWT is VerticalPanel. To the uninitiated developer, this seems like the sort of thing that will be useful everywhere. You often want stuff stacked on top of each other - think menus, lists, the layout of a dialog. What is not obvious is that it uses tables for layout under the covers, and I've mentioned in the past that Tables Should Not Be Used For Layout.

A much less obvious way of getting the same result with (usually) no extra effort is to use FlowPanel. This is rendered as a div, and most of the time the elements that get inserted into it will render in a vertical stack.

VerticalPanel Code

VerticalPanel panel = new VerticalPanel(); panel.add(/* your widget */); panel.add(/* your second widget */);

VerticalPanel Rendered As HTML

<table>
  <tbody>
    <tr>
      <td>
        <!-- your widget here -->
      </td>
     <tr>
    <tr>
      <td>
        <!-- your second widget here -->
      </td>
     <tr>
  </tbody>
<table>

FlowPanel Code

FlowPanel panel = new FlowPanel(); panel.add(/* your widget */); panel.add(/* your second widget */);

FlowPanel Rendered As HTML

<div>
  <!-- your widget here -->
  <!-- your second widget here -->
</div>

You can see that the DOM generated for a very similar-looking 3 lines of code is much much smaller for FlowPanel.

Who Cares?
Right, but we're only talking about a few more elements, and browsers are pretty smart about optimising these things. Right?

Maybe. But if you use VerticalPanel for all your containers, for every box which needs to be a slightly different colour, for every place you want to change the alignment slightly, things get very big very fast. This is an example of real code from an early prototype, where we had several nested panels (not unheard of if you've got a complex dialog box with lots of elements in it. Like, say, a deal ticket). And I've stripped out a lot of the table attributes that made this even more heinous:

<table>
  <tbody>
    <tr>
      <td align="left">
        <table id="panel1">
          <tbody>
            <tr>
              <td align="left" style="vertical-align: top;">
                <table class="orders-input">
                  <tbody>
                    <tr>
                      <td align="left">
                        <table class="row">
                          <tbody>
                            <tr>
                              <td align="left">
                                <table id="container">
                                  <tbody>
                                    <tr>
                                      <table id="panel2">
                                        <tbody>
                                          <tr>
                                            <td align="left">
                                              <table class="controls">
                                                <tbody>
                                                  <tr>
                                                    <td align="left">
                                                      <!-- widget -->

For every table element and associated elements (tbody, tr, td), you would get a single div element instead if you simply replace every instance of VerticalPanel in this stack with a FlowPanel.

<div>
  <div id="panel1">
    <div class="orders-input">
      <div class="row">
        <div id="container">
          <div id="panel2">
            <div class="controls">
              <!-- widget -->

See? Much nicer.

This is exactly what we did do, and we saw a noticeable speed improvement across all browsers - noticeable to a real user, not just some millisecond improvement on a performance test. Mind you, users' brains are amazing things and your system has to react in less than 0.1 seconds for a user to perceive it as instantaneous. So even in a browser, every millisecond counts.

In addition to improved performance, you get a nice bonus: now the layout is no longer controlled by tables, you can really easily shove stuff around and make things look pretty with the clever use of CSS. If you're really lucky, you can chuck that stuff over to your designers and not have to do another GWT compile when someone wants to move things 3 pixels to the left. Which they will.

On How Not To Target Girl Geeks

2011-01-20T09:30:00.000Z

(First, let me say this post contains opinion, stereotyping and sweeping generalisations. But that's sort of the point. Also I don't pretend for one moment to speak for all girl programmers, I can only speak for myself)

When I first started this blog, I wanted to just post "proper" technical information. I wanted to prove that there are girls out there doing "real" programming.

I specifically didn't want to talk about my gender. I wanted to prove by silence that gender is incidental to what I do.

But, it doesn't really work that way, does it?

Firstly because one of the first things I get asked by guys when I meet them in this industry is "why aren't there more girl programmers?" (that's after they ask "do you work in HR?" followed by "are you a real programmer?" - I'm not joking, this happened this week).

And secondly because I'm pretty passionate about the gender issue. To be specific: I'm passionate about diversity. It's just that I'm more qualified to bang on about gender rather than something like race, sexuality, age etc.

What's started you off again this time?
The London Java Community got me thinking by asking "Is there anything we can do to attract more girls to the events?"

The thing is, the reason people (boys) keep asking this question is because they want more girls in the industry / at events. They want them to feel involved and included. I've said it before, but I mean it - I've never come across malicious sexism at work. Yes there is subconscious sexism. But the boys want the girls to come and play. Why wouldn't they? How many boys really want to work in a team which has 12 developers and only one is a girl?

But think about it: who is the worst person to ask why girls don't like being developers?

Yep. A girl developer.

Because we love it. We're here because we like programming, we like our jobs, we're good at it. We weren't stopped by sexism (assumed or real), by boys clubs, by not having female role models, by... well, any of the myriad of reasons posited as to why girls don't become programmers.

I have no idea why a girl wouldn't want to be a programmer. It's brilliant! It's problem-solving, logical and creative, you're usually surrounded by intelligent people who are striving toward the same goal as you, and you get to meet a lot of boys :-)

So, back to the question at hand: how do we appeal to girls, as a user group and ultimately as an industry?

There are lots and lots of ideas kicking around this area, and I'm going to start by ranting about the things I think we shouldn't be doing. This, of course, is totally my opinion so helpings of salt might be required.

No Pink
I get so angry about this!! As if the pinkification of our little girls wasn't bad enough, "people" (I have no idea who) think that they can inflict this upon grown-ups too!

Why, WHY, would a website that is aimed at professional technical women be branded in childish hues of the hated colour? I didn't even click on a single link, I'm not sure what service it's supposed to provide, because I was so disgusted by the colour palate I closed the browser.

In particular, if your target demographic is the somewhat unusual creature the girl-geek, or at least the lady technologist, what makes you think that ultra-feminine colour is going to appeal to us? Apparently "The November 2009 Times/Lady Geek Female Appeal Study showed that only 9% of women want technology to be feminine, let alone pink."

What do you think, that your average (female) maths graduate is going to decide Computing Is For Me Because It's Pink? Really?

I worry about this: are these sites (phones/consoles/cars) designed by men, and that's what they think women like? Or were they designed by women who really believe that's what ALL women like?

Please. Stop it. Now. It's embarrassing.

Be careful about your role models
Take the gadget show, for example. I don't actually watch it, I'll be honest, because I really don't need someone tempting me to spend money on things I don't require. But as an example of this point it's perfect - just the picture at the top of the page says it all to me: two reasonably attractive women (I know not everyone floats your boat but they're not ugly), token black guy and two white guys who certainly don't float my boat. If only one of them was gay, their diversity tick sheet would be perfect.

I am not for one second suggesting any of these guys don't know their stuff. That is not the point at all. I just wonder - if one of the women looked like someone's mum, would they have got the job? The subconscious message here is that yes, it's totally fine to be a girl and a geek. But you still have to look good too.

And there's another message there - if you're a guy and you're into technology, you don't have to be hot. In fact, the role models we see are definitely on the Not Hot end of the scale. Bill Gates anyone?

So girls get a double-whammy - I have to know what I'm talking about and look good (whilst also trying to prove that girls who look good have brains); and there are no hot guys in the industry.

Hmm, no thanks, I think I'll get a job in marketing.

Don't assume all women are the same
In fact don't assume anything about the girls you want to attract. Actually, assume they're people. Like you. And geeks. Like you.

For example. I actually do like shoes and clothes. But plenty of my fellow girl-geeks are about as bothered about that stuff as their male counter-parts. So trying to appeal to girls with iPhone apps that help you pick you next pair of Jimmy Choos might not be the approach you want to take. You'll attract a subset of women, sure, but they might not be the ones you want.

Imagine if you wanted to get more guys into programming, and you decided to do it by using football as the hook. Yes, you'd get certain guys interested. But I've met more guys who are utterly disinterested in football in IT than I've met girls who dislike it.

We're not all the same. We're interested in all sorts of different stuff.

Be very very careful about women-only events
My personal feelings are that there should be no need for all-girl conferences or all-girl line-ups. To me, it implies that girls want something different to boys, and that girls only listen to other females.

I think there are places for these sorts of things, especially if you're aiming it at girls who might be more uncomfortable with guys around (e.g. some sort of mentoring). So I'm not going to say flat-out they're wrong.

It's just I think it's not the right angle to attack the problem. And you're segregating based on one dimension only, but as I said we're all different and we all have different problems. The issues a non-white (am I allowed to say that?) lady might face could be different to those a middle class white girl like me has to deal with. And do you want all-black conferences, and all-gay conferences, and so on and so forth? Why are we special? Why are we allowed to exclude the boys? It's sexist.

Also, as a girl-geek, I get a bit freaked out when I'm surrounded by women, even if they're all geeks like me. I'm much more comfortable talking to a guy, they tend not to try to read between the lines of everything you say or wonder if you're bitching about them behing their back </gross generalisation>.

Diversity is about being inclusive, not exclusive.

In Conclusion
Lots of the girl-geek, women-in-IT movement often appears to me as if women are "special" and need different treatment. This is not helping our cause at all. It causes resentment amongst our male peers and it puts off women who don't define themselves by their gender - people like the girls who are already in our industry. We like technology, we love programming, and we're good at our jobs.

So. I don't know why there aren't more girls in programming. And I don't have the answers as to what will tempt them in.

But, just for me, next time you're creating an advert or a website or something aimed at geek-girls, can we have more hot guys please?

CSS for Developers: The Joy of Floats

2011-01-19T10:13:00.000Z

As promised, the Long Awaited Follow-Up to CSS for Developers Part One! Well, long-awaited if you're as afflicted with NADD as I am.

Quick recap - the aim of this series is to provide a quick and easy how-to around the magic that is CSS. It's primarily aimed at developers, although I would hope it's comprehensible to a range of tech-savvy people.

(Note: unless otherwise stated, the screenshots are in Chrome on a Mac - given an earlier version of this guide I can tell you the behaviour is identical to Firefox on Ubuntu).

Part Two: The Joy of Floats (or: why they don't do what you think they should)

Last time I stated that using float is a great way to position elements contained in a div. Well, it has its downsides too. Quite a few actually.

So this post documents the ones I ran into and what we did on the LMAX Trader UI to get it to look the way we wanted.

Disclaimer: There might be better ways to do a lot of this stuff - if you locate them via Google or work them out for yourself then well done!

2.1 Starting a New Line Using Floats

<html>
<head>
    <title>Horizontal flow</title>
    <style type="text/css">
        #left {
            background-color: cyan;
            width: 50%;
            float: left;
        }
        #center {
            background-color: yellow;
            width: 50%;
            float: left;
        }
        #right {
            background-color: red;
            width: 50%;
            float: left;
        }
        #next-line {
            background-color: green;
            width: 200px;
            clear: left;
            float: left;
        }
    </style>
</head>

<body>
<div id="container">
    <div id="left">Left</div>
    <div id="center">Center</div>
    <div id="right">Right</div>
    <div id="next-line">Next Line</div>
</div>
</body>
</html>

clear: left will reset any left float from before the div it is applied to. This will cause the div to be shown on a new line, although it can still have a float property as well
clear: right will put the div below any divs with a right float applied
clear: both will do both.

I usually do clear: both if I need to ensure the div will be on a new line.

2.2 Right Aligning Floated Divs

<html>
<head>
    <title>Float Right</title>
    <style type="text/css">
        #left {
            float: right;
            border: 1px solid gray;
        }
        #center {
            float: right;
            border: 1px solid gray;
        }
        #right {
            float: right;
            border: 1px solid gray;
        }
        #container {
            background-color: yellow;
            height: 26px;
        }
        #left2 {
            float: left;
            border: 1px solid gray;
        }
        #center2 {
            float: left;
            border: 1px solid gray;
        }
        #right2 {
            float: left;
            border: 1px solid gray;
        }
        #container2 {
            clear: both;
            float: right;
            background-color: #90ee90;
            height: 26px;
        }
    </style>
</head>

<body>
    <div id="container">
        <div id="left">Left</div>
        <div id="center">Center</div>
        <div id="right">Right</div>
    </div>
    <div id="container2">
        <div id="left2">Left</div>
        <div id="center2">Center</div>
        <div id="right2">Right</div>
    </div>
</body>
</html>

If you want to right-align a number of elements (for example, buttons at the bottom of a dialog), there are two approaches. One is to set float: right on each individual item (see the yellow panel above) - you'll notice that this means the divs are displayed in reverse order, because they're set to float to the right of each other. A better approach is to put the divs you want right-aligned into a container div and float that to the right (see the green panel). This ensures the correct ordering of the items.

2.3 Floating Behaviour to be Aware Of: float left next to float right (cross browser)

<html>
<head>
    <title>Float right next to float left</title>
    <style type="text/css">
        #left {
            background-color: blue;
            width: 50%;
            float: left;
        }
        #center {
            background-color: yellow;
            width: 50%;
            float: left;
        }
        #right {
            background-color: red;
            width: 50%;
            float: left;
        }
        #next-line {
            background-color: green;
            width: 50%;
            clear: left;
            float: left;
        }
        #float-left {
            clear: left;
            background-color: purple;
            float: left;
        }
        #float-right {
            background-color: cyan;
            float: right;
        }
    </style>
</head>

<body>
<div id="container">
    <div id="left">Left</div>
    <div id="center">Center</div>
    <div id="right">Right</div>

    <div id="next-line">Next Line</div>

    <div id="float-left">Floating Left</div>
    <div id="float-right">Floating Right</div>
</div>
</body>
</html>

In Firefox and Chrome (tested under Ubuntu and OS X), if you clear the float on a single div element, that div and all the ones after it will appear underneath all the previous ones. For example, see the "Floating left" (purple) and "Floating right" (cyan) divs above. The two divs appear on the same line, floating side-by-side.

This may even be the same behaviour in IE in strict mode (I don't remember if I tested it). But by default, Internet Explorer renders this quite differently.

(Apologies for some of the inconsistency in screenshots - given my choices of operating systems, getting the cursed screenshots in IE was... challenging).

The point is that in IE the float: right is quite literal - it floats to the right directly underneath the last floated element, regardless of any prior clear commands.

If you want to get the same behaviour across all browsers, you need to be stricter with adding containers for different content areas:


<html>
<head>
    <title>Float right next to float left - correct</title>
    <style type="text/css">
        #left {
            background-color: blue;
            width: 50%;
            float: left;
        }
        #center {
            background-color: yellow;
            width: 50%;
            float: left;
        }
        #right {
            background-color: red;
            width: 50%;
            float: left;
        }
        #next-line {
            background-color: green;
            width: 50%;
            clear: left;
            float: left;
        }
        #float-left {
            background-color: purple;
            float: left;
        }
        #float-right {
            background-color: cyan;
            float: right;
        }
    </style>
</head>

<body>
<div id="container">
    <div id="left">Left</div>
    <div id="center">Center</div>
    <div id="right">Right</div>
    <div id="next-line">Next Line</div>
</div>

<div style="clear: both">
    <div id="float-left">Floating Left</div>
    <div id="float-right">Floating Right</div>
</div>
</body>
</html>

2.4 Floating Behaviour to be Aware Of: parent divs of floated elements do not resize to child

<html>
<head>
    <title>Floats in containers</title>
    <style type="text/css">
        #left {
            border: 1px solid blue;
            float: left;
        }
        #right {
            border: 1px solid red;
            float: right;
        }
        #container {
            border: 1px solid black;
        }
    </style>
</head>

<body>
<div id="container">
    <div id="left">Left</div>
    <div id="right">Right</div>
</div>
</body>
</html>

In the code above, we have a "parent" div, container, with two children, left and right. Both of these children are floating, it doesn't actually matter that one's left and one's right. What you might not be able to see clearly is that the parent, container, has zero height. It's got a black border, you should be able to see that the top and bottom of the border are actually next to each other, showing the div has no height of its own.

However the children have a height, the height shrinks to fit the content, the text.

What I'm trying to get at is that if you want to place something underneath the left and right divs, you can't rely on the browser working out where the bottom is and placing other divs underneath them:

<html>
<head>
    <title>Floats in containers</title>
    <style type="text/css">
        #left {
            border: 1px solid blue;
            float: left;
        }
        #right {
            border: 1px solid red;
            float: right;
        }
        #container {
            border: 1px solid black;
        }
        #container2 {
            border: 1px solid yellow;
        }
        #left2 {
            background-color: green;
            float: left;
        }
        #right2 {
            background-color: purple;
            float: right;
        }
    </style>
</head>

<body>
<div id="container">
    <div id="left">Left</div>
    <div id="right">Right</div>
</div>
<div id="container2">
    <div id="left2">Left</div>
    <div id="right2">Right</div>
</div>
</body>
</html>

(You'll note this is not an article about design! I'm trying to use a combination of colours, outlines etc to make the point clear, not to make it look good)

Basically the floated divs are effectively absolutely positioned, and therefore take up no space on the document (more on this in a later post).

The way I've got round this in the past is to set a specific height on the parent div to force any following elements to appear underneath it. This works, but it can be fragile. In particular, it doesn't allow for wrapping text (more on this later too).

Still to come:

Position and Display: relative, absolute, block, inline... what does it really mean?
Horizontal and Vertical Centring
Strict Mode Is Your Friend
Column layout using CSS
Why "width: 100%" might go off the edge of the page
Cross-browser table border behaviour

Previously:

Horizontal Layout using CSS

FogBugs and Kiln World Tour

2011-01-18T10:57:00.000Z

Last Thursday I was fortunate enough to get a place on the FogBugz and Kiln World Tour. I booked it before I moved jobs, and I'll be honest I had no real interest in the software. I've been reading Joel's books and blogs since my friend Brent bought me Joel on Software and made me read it (he had the foresight to know I'd want to hang on to his copy if he'd lent it to me!). I wanted to see the man in the flesh and hear what he had to say about his software. Because really, do we honestly need yet another bug-tracking / project-management tool?

Who would benefit from FogBugz?
Joel's demo was really good at demonstrating exactly how you might use the software - the processes you might follow, how to raise / update a ticket and chase it, and how you can see what's going on with the projects tracked.

I can actually think of a number of companies I've worked for, or friends have worked for, that would see an improvement in productivity from using FogBugz for bug tracking / project management. When I worked at Touch Clarity (later swallowed by Omniture, which was gobbled by Adobe) I was desperately looking for a product to help us:

Record defects
Capture new feature requests
Assign tasks to developers
Estimate tasks
Track progress - both at a project level and for individual developers
Provide us with a lightweight process which was easy to follow
Generate reports for management.

From the demo I saw, FogBugz will do everything we wanted at that time. We were using Bugzilla back then, and badly. I'd also investigated XPlanner, VersionOne and a bunch of other defect/project management tools, and not really seen anything that did what I wanted (certainly that was cheap enough). But this was back in 2004/5, we were doing a half-hearted version of eXtreme Programming, and we didn't have a lot of cash to burn. It was hard then to find a lightweight, customisable, inexpensive tool.

The things I saw in FogBugz that I thought would be useful were:

Nice UI - usability of these things is so frequently under-valued.
Really easy to track what's going on with a defect, to add and edit comments etc. I actually liked that the edit feature still tracked versions of the comments, I can see how some organisations would need that audit trail.
Evidence-based scheduling - I liked the way that it uses past information to have a good guess at how accurate an estimate will be, and therefore the soonest, likely and latest times a feature might be delivered by.
Visibility over an individual developer's workload.
Visibility over work at a project-level
Loads of charts/reports to let you slice and dice the stuff you have in there.
Dependency management
Neat integration to source control - yes, I know you can get this for loads of management tools now, it doesn't mean it's not useful. It seemed pretty slick here.
It seemed quick. But then it could have been a locally-running instance with about 3 defects in it.

The things I thought would not be so useful in a more Agile environment:

Evidence-based scheduling
Visibility over an individual developer's workload.
Lots of the ways the data can be sliced and diced
Dependency management

So, you like it and you don't like it?

Yeah yeah, I've gone all multiple-personality again. The stuff I liked about the product would be dead useful for the types of projects that work that way - where you assign work to individual developers who estimate the work; where developers are assigned to specific projects; where stories / features might not be broken down into small, independent tasks. These places might be running waterfall, or some agile-ish process, or no process at all. A tool like this will give them much better visibility over what's going on, over which deadlines won't be met, over who's estimates are flaky and who's are generally reliable.

However even before I joined ThoughtWorks, before I joined LMAX, I was sold on Agile as a more natural way to run development teams (this is despite having worked with Touch Clarity's sort-of-XP and A Very Large Media Organisation's ScrumBut). The problems that some of the features in FogBugz tries to address are similar to the problems that Agile (XP/Scrum/Kanban or some hybrid of these) is also supposed to address.

Evidence-based scheduling: I totally agree with getting statistical about this - teams and management should have a good idea how reliable estimates are. But one of the ways to reduce the variation is to have the estimates done by the team. At LMAX, we would have three developers estimate every story. With any luck at least one of those would know enough about it to provide some solid technical guidance on what was involved, but if there wasn't someone in a group of three that had that knowledge, chances were pretty good the team generally were going to be pretty vague on it. Granted, if you're using FogBugz you can enter the team estimate instead of just the individual who is going to implement it and then your evidence-based scheduling will be for team-estimates instead of personal ones. This is totally fine, in fact it's a good thing - I just think we shouldn't use evidence-based scheduling to "fix" the problem that estimates are just that - an estimate, a guess.
Visibility over a developer's workload: If you're doing pair programming (XP), if the team takes ownership of the implementation of features / stories (Scrum), there's no need to look at how busy an individual developer is. Yes, there are lots of organisations that do allocate work to individuals. In many (most?) Agile-practicing teams, this will not be happening. So really you only need visibility over a team or project level.
Reporting: Ah, I love reporting. I love data, statistics, pretty charts. Maybe I'm secretly a project manager. But it's SO easy to get hung up on the stats, on one tiny measurement, rather than the bigger picture - are we getting closer to "done" or not? I think you should be able to get at all that data, but not get carried away micro-optimising for metrics which may be hiding bigger problems.
Dependency management: another thing that is dead important in some types of teams or organisations. But the last few Agile projects I've worked on have not tracked hard-link dependencies at all - each story should stand alone, should be estimated on the basis of just doing that piece of work. Yes, this is idealistic, and even in the projects where we did not officially track dependencies, we'd have a good idea of a very general order things should be done in (or an idea of the order things could be done in to make life easier). But these things can be fluid, if a specific feature needs to be done now, you shouldn't have to do every single story that might have a tiny piece of functionality this story is dependent on - just tackle this story and everything you need for it.

All of those points could be blog posts in their own right, I know it's taken me years to get my head around the way I personally see Agile. But you get the idea, or maybe you don't - that's fine, maybe you're in exactly the sort of place that could use FogBugz to improve your productivity.

FogBugz vs Mingle

I started at ThoughtWorks last week, so I'd better mention that ThoughtWorks Studios have a competitor product, Mingle. I'm reasonably well-qualified to talk about it since I've been using it in anger for the last two years in a maturing agile environment, and I had my Mingle ~~indoctrination~~ induction last week.

To me, the main difference is the angle the two products are taking to approach the same problem: how do you provide a tool that

is easy and lightweight enough to use that people (particularly developers) will keep it up to date;
tracks just the right amount of data that people have visibility over the state of development (What are we doing? Are we going to hit our deadlines? What are our blockers?)

To me, it seems FogBugz is coming from the traditional development model - it might not be anything as formal as waterfall, but it may not be based on short iterations and assumes individuals rather than teams are assigned work. Mingle was developed for the Agile team, e.g. collective responsibility, pair programming, short iterations.

Mingle is highly configurable, and while FogBugz has a number of templates and custom work flows, Mr Spolsky specifically stated at the demo that these really shouldn't be used. That they've worked hard to find a process that works, and we should all follow that.

So, Mingle embraces the differences between teams/processes and FogBugz specifically discourages it.

I reckon these things are actually also the potential downfalls for both products too: Mingle can be abused so badly that it adds no value; FogBugz could be so prescriptive it slows down productivity.

But it's horses for courses, every tool has its advantages and disadvantages. Or should I be pushing Mingle at this point until I pass my probation??

Kiln, and an introduction to DVCS

Good Lord, I've written all that stuff and that's only from the short demo at the start of the day.

Fortunately I have a lot less to say about the latter part. It was an introduction to Distributed Version Control (DVCS), and it was pitched absolutely right for someone like me.

I've never used a DVCS; most recently I've been using Subversion, but I've also used PVCS, ClearCase, VSS and a bunch of others (in fact, I'm pretty sure I've had to learn a new source control system every time I've switched project or company!). I've been introduced to Git over a lunchtime, and I read Martin Fowler's blog post on version control tools. The intro provided by FogCreek was spot on for me. It showed me:

The differences between a DVCS and something like Subversion (OK, specifically svn, which is fine for me);
Advantages of using a distributed source control system;
Some mindsets that you need to change when switching from svn to a DVCS like Mercurial;
The FogCreek way of setting up the repositories.

The last point was particularly useful in giving some real-life examples of how to use a DVCS and why.

Then there was some stuff on why Kiln might give you more than just the freebie Mercurial install.

It was more useful in a general fashion than the FogBugz section. However, like the FogBugz talk, I got a good feel for the types of teams/companies Kiln might be good for, and why you might use it. Personally it convinced me that using a DVCS in general is probably better than Subversion (insert usual disclaimer of different tools being appropriate for different situations). It certainly encourages working practices that will lead to a) less accidental loss of code (after all, that's what source control is for) and b) if well organised, better separation of bugs / features / stories and better integration across versions and branches.

If you want to know what I've been blathering on about in this section, check out Joel's excellent introduction to Mercurial. OK, I admit it, I haven't read it all. But it seems to cover everything that was covered in the conference session, with Joel's usual wit and appeal to the developer mindset.

In Other News

In terms of an education session, the "World Tour" was excellent - succinct, easy to digest, and (to my mind) aimed exactly at the audience.

However. I actually ended the (half) day being slightly disappointed, and not just because these tools don't seem to be ideal for the Agile team.

I didn't get enough of a chance to network. Now, I'm happy to admit this is a problem I regularly have - because, like many developers, I find it difficult to talk to new people in a big room full of people I don't know. However, given that this was a big room full of developers, I wish there had been more of an effort made to help us to mix and network. Before the talks we were on tables in another room having coffee etc, which I liked because it did lead to some conversation in small groups. But I would have been nice if there had been a chance at the end of the talks to chat to people and dissect the session (if there actually was, it was so badly publicised I missed it). I went with a stack of business cards and didn't give a single one out.
The half day didn't seem like enough. But this might be more a reflection of the above point since I got what I wanted from the talks, any more would have been too much info. So maybe I just wanted more time with the attendees and with the FogCreek guys.
I was shocked by how few women there were. I'm no tech newbie, I've been to training sessions, conferences, user groups, seminars, and worked on site at a lot of different types of places. I was very surprised to see that in a room of several hundred people I counted 5 women (myself included). This seems low even for gathering of techies, it seems very low for a presentation on a piece of software that is effectively project management software. I don't have the stats to hand, but in my personal experience any technical event with even a sniff of project management stuff is better represented across both genders. I wouldn't normally comment on it because it's something I'm used to myself, but I've been asked a bunch of times in the last two weeks "what do we need to do to encourage more participation by women?", and I have my eyes open for stuff which might help me answer that.

In Conclusion

A generally good, well-run event, especially as it was free (if I recall correctly).
FogBugz and Kiln are excellent tools for a certain type of organisation / team, and I'm not talking about a small minority of teams here.
If you're Agile, these tools are probably not for you. You can get them to work, and if you're "kind of" agile they're probably better than a lot of your options. But true agile teams running an effective process might find themselves hindered more than helped.
I'm going to download and install a DVCS the very next time I have to write a line of code.

CSS for Developers: Horizontal Layout Using CSS

2011-01-17T11:59:00.000Z

I'm a Java Developer. But I'm also a Web Developer. Web Developers have been so badly maligned over the last decade or so that I always feel wary (and sometimes slightly ashamed) admitting this. There's some sort of assumption that Web Developers (and Front End Developers) aren't real programmers. Similarly, "real" developers don't like to be tainted by coming into contact with that nasty "front end stuff" in case someone mistakes them for a designer.

Trust me, no-one is going to mistake a Java Developer for a designer. For a start, when designers wear geeky glasses it's ironic. Or chic. Or something.

But developers will be forced to do something around the front end at some point in their lives. Even if it's because they're sick of manually kicking off some process and want to give the users a big red button to press instead.

So, as much to compensate for my own goldfish-like brain as anything else, I'm going to make a note of some of the CSS stuff I've used or found helpful during my mad scramblings to get the LMAX Trader user interface to a) look the way we wanted b) perform fast enough so our awesome back end performance wasn't totally invisible to the retail user and c) Not Suck Too Badly in Internet Explorer.

Part One: Horizontal Layout (or: There's No Excuse For Tables Any More)

You may (or may not) have heard that using tables for layout is a Bad Thing. But to be fair, most of us don't care. I've done it myself, it's usually the quickest way to lay stuff out on the page, especially if you're new to HTML / CSS and/or short on time. There are loads of arguments all over the web as to why this is a bad thing, but the reasons I didn't want tables on the LMAX UI was a) we saw the performance improve by a really simple replacement of tables with divs and b) given the amount the UI was mutating, divs positioned with CSS was going to allow us a much quicker turnaround for the umpteenth re-design of the UI (ideally the upshot of this would be letting the designers mess with the CSS when they changed their minds and leave us developers out of it).

Anyway let's assume Tables Are Bad. Tables are only for tabular data, not for layout. In my world.

1.1 Simple Horizontal Layout Using Inline

The most common use of tables for layout is where you put elements side by side - the default behaviour of divs is that they lay out underneath each other.

However it's pretty easy to get divs to behave this way too, and using divs has some advantages over using tables.

<html>
<head>
    <title>Horizontal flow</title>
    <style type="text/css">
        #left {
            background-color: cyan;
            display: inline;
        }
        #center {
            background-color: yellow;
            display: inline;
        }
        #right {
            background-color: red;
            display: inline;
        }
    </style>
</head>

<body>
<div id="container">
    <div id="left">Left</div>
    <div id="center">Center</div>
    <div id="right">Right</div>
</div>
</body>
</html>

The first option is to use display: inline. This will lay div elements next to each other, similar to a span. This is the simplest way to get divs to appear side-by-side.

The disadvantage of this technique, however, is that inline elements can't be sized the same way as standard divs. By default they contract to fit the content.

The screenshot above is from Chrome on the mac - you'll notice by default the elements have some spacing between them. Reducing the margin/borders on the elements doesn't seem to eliminate this, so that's something else you might need to consider if you use this mechanism to display elements side-by-side.

1.2 Simple Horizontal Layout Using Floats


<html>
<head>
    <title>Horizontal flow</title>
    <style type="text/css">
        #left {
            background-color: cyan;
            float: left;
        }
        #center {
            background-color: yellow;
            float: left;
        }
        #right {
            background-color: red;
            float: left;
        }
    </style>
</head>

<body>
<div id="container">
    <div id="left">Left</div>
    <div id="center">Center</div>
    <div id="right">Right</div>
</div>
</body>
</html>

Similar to using inline, floating a div will do the following:

Make it shrink to fit the content
Lay it out side-by-side with any sibling floating divs.

You'll want to apply padding, margins, height, width and whatever else to make it appear less rubbish.

1.3 Wrapping Horizontal Layout


<html>
<head>
    <title>Horizontal flow</title>
    <style type="text/css">
        #left {
            background-color: cyan;
            width: 50%;
            float: left;
        }
        #center {
            background-color: yellow;
            width: 50%;
            float: left;
        }
        #right {
            background-color: red;
            width: 50%;
            float: left;
        }
    </style>
</head>

<body>
<div id="container">
    <div id="left">Left</div>
    <div id="center">Center</div>
    <div id="right">Right</div>
</div>
</body>
</html>

The advantage you have using divs over tables is that you can get the browser to work out how the elements should flow. Tables require you to determine exactly how many cells appear on each row, but with divs you can determine a width for each element and have the browser work out whether to show it on a new line or not. This will work with both percentage and pixel widths.

If you want a more table-like structure where you know exactly how many elements should appear on each line, use a percentage of the screen with.
If you know the width of each element, you should set a pixel width on the elements and have the browser work out how many to show per line.

The next CSS post will go over floating behaviour in a little more detail.

Live at Last

2010-10-31T17:05:00.000Z

We went live with "real" customers this week just gone. It's the culmination of nearly two years work for me personally, and three years for our company.

It's really nice to be live at last, and to have our name out there. It might (in fact, should) change the focus of our work. Without paying customers it's much more difficult to prioritise work based on what they might need or want.

Exciting times for LMAX!

Lean Software and Systems Conference 2010 (Bletchley Park)

2010-07-09T11:28:00.000+01:00

This is just a summary of the points I took from the Lean conference at Bletchley. They all need expanding, this is just the stuff that struck me that I want to record.

A Kanban Multiverse – Karl Scotland
Points from his talk

Meaning = visualise; interact; persist
Kanban provides the translation between communities
Remove columns from the Kanban board - no more chucking things over the wall to people
Flip charts for design models
Dots on cards for every day in dev, crosses for every day in test
Exploration of UI is part of the card

Ideas applicable for my project

Add broken acceptance tests to the Kanban Board?
Start doing task breakdowns again
Add issues and impediments to Kanban board?
Mingle should be updated to reflect the Kanban, at the moment the states are incorrect

Converting a Scrum Team to Kanban - Mattias Skarin

Points from his talk

Moved from releases per iterations to releases per week
Shifted motivation from delivering at end of iteration towards delivering quality
Establish release cadence and team rhythm
Root cause analysis to find problems and target them
Removed the need for estimates

Ideas applicable for my project

Shift to focus on release cadence from iterations?

Product Development in the Land of the Free
Points from their talk

Goal should be to “Delight Customers”
Sitting together decreases waste
Sysadmins belong to the team and rotate
Deliver value fast enough and you don't have to ask for permission

Learn to Lean: Becoming a Lean Startup – Damon Morgan
Points from his talk

Introduce a learning culture: blogs, brown bags, conferences
Scrum introduces a half-day overhead of planning etc.
Scrum implies a handed off release to QA / Ops
Didn't have “QA” but “Developer/Testers” and “Tester/Developers”
Lean = planning on demand.
Not sure when we're supposed to do retrospectives with a pull model?
Definition of Done is not only released to production, but has two possibilities: Generating Value and Not Generating Value
Cards that are “complete” but not released are inventory (and therefore waste)
Need fast smoke tests
Monitoring allows you to reduce errors and see if the release was good. Auto-rollback if not
Releases can be small, feature-specific releases
Have an ideas wall for anyone to contribute
AB Testing very useful to this organisation.
Reduced reliance on estimates
Releases not a big deal – happen daily
Measure outcomes, not activity
Out of 20 ideas, maybe one works. But cost/benefit clear and well understood

Ideas for us

Become more release-focussed
Should we encourage developers to do (more) exploratory testing?
Definition of done should be “released”
Better automated monitoring

Using Kanban to Continuously Improve – Benjamin Mitchel
Points from his talk

Quality First
Flow important
“What wasted your time?” to do root cause analysis
Measure time taken to flow through the board
Even if you show people metrics they still don't believe you

Ideas for us

Thank goodness we're not a big enterprise organisation

Behaviour Driven Development – Liz Keogh
Points from her talk

The term BDD and what it means has solidified over time, but it's nothing new
Concentrate on your riskiest tests first
Write your tests starting “should”
Conversations are around behaviour not tests
Development of stories is focussed on learning

Ideas for us

We're pretty good at BDD

Value Stream Languages – Eric Willeke
Points from his talk

Really just a summary of the day / Lean
We should respect different languages
Break things down into what you need to learn, not what you need to do and how long it will take
Variation comes from time it takes to learn, not time it takes to do
Ask “what do we need to know that we don't know now?”
Break milestones down accordingly – High Learning → High Risk → Core Value → High Value
Standup should be phrased “what did we learn yesterday; what do I need to learn today”
When your acceleration of learning decreases it might be time to stop designing and start doing

Ideas for us

Maybe a shift in thinking about “learning” instead of “doing”

Summary
Points frequently repeated and/or relevant to my project

Aim towards no estimation
Not focussing on iterations but on releases
Releases are part of the definition of done
Our BDD and basic Kanban is pretty good
Visibility allows us to find bottlenecks and target them
Focussing on learning might be a path to improvement
Silos are Bad, mmmkay?

Comments on representations of our industry

2009-05-15T13:22:00.000+01:00

I have not (yet) seen the presentation this post is referring to. But I think many of the comments Ted makes are very valid, and our industry as a whole should occasionally stop and think. I've seen Ted speak at QCon, and I've had a lot of time for his comments ever since.

I'm aware that this blog is rapidly filling with comments about gender and perceptions and people-y stuff, when I originally wanted it to be a purely technical blog. But I guess this other stuff interests me more. And there are less people talking about it than there are talking about pure technical solutions to problems.

Why changing jobs frequently is not necessarily a bad thing...

2009-04-02T10:34:00.000+01:00

...in fact, it's actually a good thing.

Sexism in IT?

2009-03-30T11:44:00.000+01:00

Let's celebrate our IT women

"Everyone" knows that there are more men than women in IT. That it's a "boys" job. Not a lot of people know that the first programmer was a woman. Not a lot of people realise the number of women in IT is DECREASING. And has been since the 80s. In a working world where I honestly believe that *in general* there are more opportunities for women (OK, inline with the other stuff I've been reading I'll caveat this with white, middle-class women), it seems shocking that such a growth industry as IT is actually losing women, and appears unable to determine why, or stop the flow.

I get asked a lot, as a girl programmer, why there aren't more women in IT. This is a complicated issue and one I've been thinking about for years and still don't have any good answers, but I personally think it's more about perception than anything else.

I don't think it's because you get more outright sexism and laddish behaviour in IT than anywhere else. I've worked in half a dozen companies, in a range of industries, including very male industries like manufacturing and banking, I've been a consultant so been onsite at a bunch more companies. And I have to say I don't think I've ever seen the sort of behaviour that is mentioned in the article.

I would go so far as to say IT, certainly in terms of programming or IT support, actually attracts men that are quite the opposite to laddish. So here I will succumb to gross generalisation and stereotypes myself, but the guys I've worked with are highly intelligent and more likely to rate you on your ability than on your colour, sex or background. These are often guys who were actually studying at school rather than absorbing anti-female sentiments in the pub or from The Sun.

I find being a woman in IT both a blessing and a curse. As a girl, you are, I believe, more likely to get through to interview, and since you stand out as different are more likely to be remembered and called back for a second interview. I think once in the organisation, we suffer more with low self-esteem and find ourselves constantly trying to "prove" that we're not just some token bimbo hired by HR. And do you know why? Not because anyone ELSE thinks that, but because WE think that. We are our own worst enemies.

We need to take a leaf from the boys' book and have more faith in ourselves, more confidence. We might not be as good as that person over there at this particular thing, or this other person at something else, but we are good at what we do, otherwise we wouldn't be there. And if we express our insecurities instead of our confidence, other people will assume we're as mediocre as we sometimes think we are.

Some of the very worst culprits for sexism in our industry are us, the girls who are already in it. Yes, it does exist, I am not denying that for a second¹. But the way to overcome it is to reflect it back at them, not to internalise it as our problem, something wrong with us for being in the wrong job. The more we show that it's normal for us to be here, that we belong here, the better we'll feel about ourselves. And maybe we'll attract a few more girls too.

^;1Take, for example, the CEO who interviewed me and said "I'm probably not allowed to say this, but how will you feel working in an environment full of men". To which my answer was, have you read my CV? I went to a boys' school for sixth form, I was one of 6 girls on my degree course (out of approx 150), I worked at Ford for 4 years. Don't you think I would be more freaked out working with girls?

Trisha's Ramblings

Why the customer isn't always right

Upcoming speaking events

Christmas decorations teach me a lesson about troubleshooting

Video: Why we shouldn't target women

How to make your CV Not Suck

Video of our JAX London session

Interview by the Oracle Technology Network at Devoxx

London Java Community Open Conference

Why We Shouldn't Target Women

Devoxx: The story so far

JAX London - I learn stuff and meet people

A NYSE Product Manager and an LMAX Developer walk into a low latency trading seminar...

More videos from Java One 2011

On The Similarities Between Girls And Aliens

Mike and I debut our new Disruptor presentation

JavaOne 2011: Roundup

JavaOne: Initial Observations

JavaOne 2011

First public appearance caught on video

Are you an awesome developer?

What my hangovers can teach you about Agile

Effective Sketches

Disruptor 2.0 - All Change Please

What I Did On My Holidays

Dissecting the Disruptor: Demystifying Memory Barriers

Dissecting the Disruptor: Why it's so fast (part two) - Magic cache line padding

Dissecting the Disruptor: Why it's so fast (part one) - Locks Are Bad

In answer to one of the search terms which led to my blog...

Dissecting the Disruptor: Wiring up the dependencies

Dissecting the Disruptor: Writing to the ring buffer

Dissecting the Disruptor: How do I read from the ring buffer?

Dissecting the Disruptor: What's so special about a ring buffer?

A chance to see some of my actual code (even if it is C#)

Vote for the LJC

STAC London Summit

My first public appearance

Getting around a bit

Why Java developers hate .NET

Trisha's Guide to Converting Java to C#

1. Find-and-replace the following (only you can't use Ctrl+R like I expect. Sigh.)

2. When using callbacks, replace anonymous inner classes with delegates

3. Replace getters and setters with properties

My Thoughts

Oh My Dear God What Is Wrong With Visual Studio?

Documentation isn't a standard function of .NET?

In Conclusion

The London Java Community elected to the JCP SE/EE Executive Committee

Cyclist tribes

TradeTech 2011 - Not like a developer conference

CSS for Developers: Horizontal and Vertical Centring

How to show your employees how much you hate them

For those who might want to make the leap from Developer to Architect

CSS for Developers: Cross Browser Table Border Behaviour

My Experiences with Android Development

CSS for Developers: Column Layout Using CSS

Part Three: Column Layout Using CSS (or: still no excuse to use tables)

3.1 Display Elements or Text in Columns

On Changing The Image Of Programmers

GWT: Why VerticalPanel is Evil

On How Not To Target Girl Geeks

CSS for Developers: The Joy of Floats

Part Two: The Joy of Floats (or: why they don't do what you think they should)

2.1 Starting a New Line Using Floats

2.2 Right Aligning Floated Divs

2.3 Floating Behaviour to be Aware Of: float left next to float right (cross browser)

2.4 Floating Behaviour to be Aware Of: parent divs of floated elements do not resize to child

FogBugs and Kiln World Tour

CSS for Developers: Horizontal Layout Using CSS

Part One: Horizontal Layout (or: There's No Excuse For Tables Any More)

1.1 Simple Horizontal Layout Using Inline

1.2 Simple Horizontal Layout Using Floats

1.3 Wrapping Horizontal Layout

Live at Last

Lean Software and Systems Conference 2010 (Bletchley Park)

Comments on representations of our industry

Why changing jobs frequently is not necessarily a bad thing...

Sexism in IT?