lixo.org

ThoughtWorks Brazil: The First Day

In the next few weeks, I’ll be putting together a few posts that tell a little bit about the stories behind the scenes of opening the ThoughtWorks Brazil office. They’re entirely from my point of view, might contain an embarrassing moment or two and are absolutely not to be taken as the official voice of ThoughtWorks on any of these matters. I’m not a PR person ;)

- Hi Sid! (Sid Pinney, sales guy extraordinnaire)
- Carlos! Heard you’re definitely leaving the UK?
- Yeah, not really happy around here anymore. Personal stuff. I really want to head back to São Paulo. And I really want to stay at ThoughtWorks…

At this point, I had already written my resignation letter from the ThoughtWorks London office. Hadn’t handed it in yet, but I did tell Sid and a few others about it. Sid and I had been chatting for a few years about getting a Brazilian office together, and since then we’ve been trying to make some business contacts and hire more Brazilians to expand our network and reach.

Both turned out really well: at this point we had something like 12 or 13 Brazilians from all over the country working at various ThoughtWorks offices around the globe, and some really interesting prospective business and contacts in some 4 or 5 companies and universities. Sid was in Brazil a month or so before this conversation with a group of Brazilian TWers to meet more those contacts and to attend a couple of conferences in São Paulo and Rio de Janeiro. I tried to help organize it, but the Personal Stuff got in the way. Props go to Danilo, Francisco, Paulo, Phillip and a few others I might be forgetting who stuffed their agendas with interesting trips and talks. They gave me the confidence to leave London without letting go of all the good stuff going on at ThoughtWorks, which I wasn’t that prepared to miss.

I left the UK a few weeks after that (and still don’t know how I survived the leaving drinks!) and went to Louisiana to spend a month cooking, crabbing, drinking and fishing for sharks (!) in the Gulf with some friends who lived there. Meanwhile, Sid was working his magic and we caught up every few days. Talks about salaries, incorporation, general number-crunching, potential clients and what to do in what order and hardly any sleep in the meantime.

- If I got you a 3 to 6 month gig at that last client we were talking about, with you contracting to ThoughtWorks, would you be cool with that?
- Sounds good! Are we incorporating in Brazil later, then?
- Yeah. Need to get you on the ground first, and then we’re hiring a law firm to help us with the incorporation. It’s not too far down the road!

A few days later, Sid emailed me the contracts and I ran off to a public library in the small town of Carencro (population: 7000), where I was told they still had a fax machine. Signed, sent and $1.50 later, I was employee #0 of ThoughtWorks Brazil and a couple of weeks from that, I’d be starting at the client site, in São Paulo.

Don’t Ever Make Me Hit Save

A little usability story: my girlfriend spent a good chunk of last night working on a paper for her Copyright Law class in Microsoft Word. At about 4am I get a desperate call: “Help! How do I unclose a document?”

Whoops.

She had written something like 5,000 words, cited sources, added pictures and diagrams. Being in a hurry, she never bothered to save the document in the beginning. After a few hours, as she was getting more and more sleep deprived and the massive jar of tar-like coffee emptied out, it’s only understandable she didn’t bother to read or reason about the confirmation dialog, which I’m sure at this point read “Are you sure yadda yadda yadda?”, with the options “Just do what I said”, “Go away” and “Whatever”.

There probably is some delicate procedure in Microsoft Office applications to deal with this occasion, and that’s exactly the point I want to make: when this kind of human error happens, it is not a good time to bring out an extensive and meticulous procedure. This kind of error shouldn’t even be possible in the first place.

If I dig out my rusty Olivetti Lettera 22 typewriter from the spare room, put a sheet of paper in it and start typing, I would have to rip out the paper and shred it or burn it in order to make the words vanish. No amount of sleep deprivation will make that happen accidentally. If Word is trying to conform to that usage model, then this crucial part of it should behave like that as well: not that we should be “burning” or “shredding” digital documents, but that it should be really hard to get rid of them by accident.

Instead – and this is 2010, folks – Word offers me a button with the image of a floppy disk, labelled ‘Save’. It’s a little digital dinosaur, fossilized as one of the most important things this application can do, as a reminder of the tough times application developers had to go through back when keeping two different versions of a text document in memory and disk was considered a desirable luxury. Nowadays, when any decent text processor will have built-in version control and infinite steps of undo, is there even a point in having to hit ‘Save’, ever?

What about your application, the one you’re building now? Is there any jurassic ‘Save’ button lying around? If I pick up a form on your web application, do some work on it, go away and come back after lunch, will it rudely tell me I didn’t save my actions?

Encoding Detector 1.0 Released

Ever had nasty problems coming from multiple development environments set up differently on your team, with developers accidentally creating files with bad encodings? Are your users complaining about all that mojibake showing up on your internationalised UI?

Well, I had… plenty of times. So I created a tiny little tool to help fight that. Encoding Detector is an aptly named tool (if I do say so myself) that recursively detects the encoding of files in a project directory errors out if anything seems fishy.

I’ve only ever used it with Ant, but it should be a breeze to set up and install on any project. All you need to do is call the main script against a directory, like:

$ python encoding-detector.py src


You’ll need a somewhat recent Python installed — anything that came out in the last 5 years should be OK — and that’s about it. Multiple directories can be passed as arguments, and fixing the errors is sometimes as easy as adding a few UTF-8 characters to boost the detector’s confidence up a bit.

This hack would definitely not be possible without Mark Pilgrim’s amazing chardet library. The code, as always, is on GitHub, and you can also grab a neat little tarball here.

It takes about 5 minutes to set up on your project, and you can thank me later ;)

Speaking in Brazil

As many reading this might know, I’ve moved from London back to São Paulo about a month ago. The timing worked out wonderfully: right before a bunch of really interesting conferences happening over here. Among them, I’m speaking at:

Encontro Ágil, 10-11 October: a quick talk about the spirit of continuous integration and how important it is to stick to it even though it’s easy to get sidetracked choosing between the tools available. I’ll explain some of the pitfalls, patterns and anti-patterns, and hope to please the Demo Gods by showing what a good continuous build, test, integration and deployment cycle looks like in practice.

Rails Summit 13-14 October: another quick talk about the use of Ruby at ThoughtWorks and some of the lessons learned in the 40+ projects we’ve done so far. I’ll try not to make it a total rip-off of Martin’s Ruby at ThoughtWorks work for QCon earlier this year, but I’m making no promises. :)

More to come, I’m sure. It’s good to be home!

A side note: would you, kind reader, get annoyed if I start mixing Brazilian Portuguese and English in future posts? Should I set up a separate blog, category or whatever so the non-lusophones can skip the stuff written in what would make Camões spin in his grave? Any suggestions as to how to do that effectively in Wordpress?

The Tracer Bullet Application

In most projects I have been on as a consultant, getting the right environments together was an incredibly consuming task on several people with too much to worry about already: project management, senior techies and the ones responsible for keeping the legacy environments running.

Recently, the idea of getting an example minimal application deployed as soon as possible during the project lifecycle has been banded about a bit as one of the things that could’ve made my last project run smoother (as always, hindsight is always 20-20). Then, one of my colleagues (either Graham Brooks or Sam Newman, but I could be mistaken) brought up a simple and perfect analogy for it, found in The Pragmatic Programmer: a tracer bullet.

From Wikipedia:

Tracer ammunition (tracers) are special bullets that are modified to accept a small pyrotechnic charge in their base. Ignited upon firing, the composition burns very brightly, making the projectile visible to the naked eye. This enables the shooter to follow the bullet trajectory relative to the target in order to make corrections to his aim.

Tracer bullets are used during the daytime as well, but their importance is heightened severely at night: when shooting in the dark, being able to see the trajectory is crucial, since other clues — such as surrounding objects being hit — are harder to recognize and do not provide quick enough feedback for the shooter to be able to adjust his aim in a timely fashion.

Since most software projects are, in a way or another, shooting in the dark, it makes sense to create a special type of application deployment that increases the visibility of the deployments coming after it.

This application does not need to have any features, besides painting an accurate picture of what the real application (coming up in the next few deployments, hopefully) will behave like. A few interesting things to analyze:

  • System environment: is the PATH set properly? Are the versions of compilers, interpreters and runtimes correct? Is there enough memory and storage space?
  • Library dependencies: are all the dynamically linked libraries available and in the correct versions? What’s the overhead of a particular choice of framework or data mapping strategy in memory consumption and performance?
  • Interactions with other legacy systems: are they available in the correct version? Is the application authorized to talk to them? Can they be contacted reliably and at the performance levels desired, or is there a network issue that needs to be solved?
  • Performance: how many users of the application (once it’s deployed) can we tolerate? What are the expected response times? Under load, what are the bottlenecks?

These questions do not necessarily have to be answered by a monolithic tracer bullet application. In my view, they’re more like deployment spikes: once they answer a question and the team learns from them, they can be thrown away or reused, but there’s no obligation to build on a previous one if doing so adds noise to the measurements.