Uma das consequências da história recente sobre Edward Snowden é uma discussão intensa sobre a importância da privacidade – em particular quando ou se a privacidade deve ser negociada como moeda no combate ao terrorismo. Para pensar sobre isso, precisamos entender porque a privacidade das pessoas é importante para a democracia. Muitas vezes ouvimos declarações como “não tenho nada a esconder”, ou como um amigo meu colocou: “a NSA não se importa com as pessoas insignificantes como você ou eu”. Eu posso cuidar da minha privacidade, mas será que deve o meu desejo pessoal se sobrepor às necessidades da nossa sociedade em geral?

Para muitas pessoas, a privacidade é um direito fundamental – não vêem razão pela qual o governo deve se intrometer nos seus assuntos sem uma razão bem mais específica do que uma busca generalizada por possível terrorismo. Mas, mesmo se você não compartilha o desejo de preservar um pouco sua privacidade dos agentes do governo, você ainda deveria estar preocupado com a privacidade dos outros cidadãos. Isto é porque não é sobre mim, ou meu amigo. O valor da privacidade para nós não é principalmente sobre a nossa privacidade, mas sobre aqueles que desempenham um papel mais ativo na operação de um sistema democrático de governo. Essa atividade envolve muitas vezes incomodar as pessoas que têm poder, e aqueles com poder são propensos a usar o seu poder para suprimir aos que os incomodam. Mas, sem todo esse incômodo, a democracia padece.

Alguns exemplos concretos devem tornar isso mais fácil de ver. O primeiro é o de jornalistas. O jornalismo é uma profissão que, em si, está visivelmente suspeita sob a lei de Sturgeon, mas a frivolidade e descrédito que mancha muito jornalismo não invalida o bom jornalismo quando ele acontece. O bom jornalismo está a ajudar-nos a entender o que está acontecendo no mundo, e tal jornalismo exige muitas vezes fazer perguntas difíceis a quem está no poder, e cavar muito para encontrar as verdades que os poderosos preferem permanecer ocultas. Tal escavação causa uma preocupação considerável a quem está no poder, especialmente quando expõe a corrupção ou incompetência.

Um segundo exemplo é o de ativistas que estão tentando mudar nossa sociedade. Esses ativistas, por sua natureza, estão muitas vezes tentando mudar hábitos de comportamento aceitos. Eles podem estar clamando por direitos dos homossexuais, ou contra o aborto, ou contra a agricultura industrial. Seus protestos e campanhas, muitas vezes, são contra os interesses de quem está no poder, e assim, suas atividades são bastante incômodas – especialmente quando elas ganham tração.

Então, vamos supor que você está no poder, e você está sendo incomodado por jornalistas e ativistas, e você tem acesso aos metadados sobre as ligações telefônicas de todo mundo. Com essas informações você pode descobrir com quem seus algozes estão falando, onde as suas fontes de informação estão, quem está apoiando-os com incentivo e fundos. Você pode agir contra essas pessoas e bloquear seu apoio. Você também pode encontrar coisas sobre seus atormentadores e seus apoiadores que podem ser usadas para desacreditá-las. Um ativista em favor dos direitos dos homossexuais é propenso a conhecer muitas pessoas gays, muitas vezes em lugares onde a homossexualidade é considerada abominável. Essa é uma vulnerabilidade que você pode explorar. Além disso, seus algozes não são susceptíveis a ser santos, já que a maioria das pessoas guarda algo que pode soar mal, especialmente quando você pode usar da sua influência para ampliar a distorção dos fatos. O abuso de drogas de um jornalista pode não impedi-lo de expor a corrupção, mas você pode usá-lo para sabotar seus esforços.

Eu não estou dizendo que a privacidade é uma necessidade absoluta. Frustrar atividades criminais muitas vezes significa violar privacidade – um banco de dados de chamadas telefônicas pode ser uma ferramenta útil para investigar uma rede criminosa. Mas devemos também estar cientes de que tais ferramentas estão sempre susceptíveis a utilização indevida e, portanto, temos de garantir que discutir como projetar controles que reduzam esse desvio ao mínimo possível.

Eu não sou um jornalista engajado, nem ativista, então por que deveria me preocupar com tudo isso? Sem bons jornalistas não consigo entender o que está realmente está acontecendo e, portanto, meu voto fica menos significativo. Corrupção florescente sufoca a atividade econômica e do progresso. Ativistas que parecem estar distantes agora podem nos levar a mudanças que serão auto-evidentes em algumas gerações (houve assédio
considerável àqueles que lutaram contra a escravidão ou a favor do sufrágio feminino, por exemplo). Em suma, se não podemos proteger a privacidade das pessoas que incomodam os poderosos, perderemos um pilar vital de nossa sociedade democrática.

When setting up an automated continuous delivery pipeline for our current project, we decided to use RPMs and Yum – the native packaging and software updates platform of our staging, UAT and production environments – instead of more Ruby-esque solutions like Capistrano.

There were several reasons behind that, but by far the most important was the affinity we noticed the operations staff already had with RPMs and Yum: all of the system packages were being taken care of using it, with some deal of auditing thrown in: has this file changed since we installed the package? Why?

Making a decent RPM out of a Rails (or Sinatra) project wasn’t very hard: a bit of head-scratching and a few passes through Maximum RPM later, we had something we could work with.

The main headaches were working out which packages were necessary to build the RPM (the BuildRequires part), figuring out how to reliably install all of the gem dependencies from bundler into the packaged RPM (bundle install --deployment helped), and which changes needed to be made to the application to rely solely on environment variables set by /etc/default/[app]. This way, we wouldn’t have any configuration that could vary across environments coming from the package itself.

The next step was setting up a marathon of tests for those RPMs. They already contained unit tested code, and we built more obstacles: functional and integration tests, performance micro-benchmarks, metrics analysis and some manual inspection in UAT. With each step weeding out bad candidates, only truly excellent builds can get to production.

To be able to easily visualize how excellent our builds were, we came up with a simple and effective naming scheme, in time for the Olympics: precious metals.

A unit tested RPM would start out in the “tin” repository. Another step in the pipeline gets triggered and deploys it to a smoke test machine. If that works, it gets promoted to the “bronze” repository. Functional and integration tests cause it to be promoted to “silver”, and so on through “gold” (ready to go) and “platinum” (in production already).

To the operations staff, this makes a lot of sense: the production machines are fetch updates from “gold”, UAT environments look at “silver” and so on. It’s trivial to configure Yum to do that – chances are you alraedy did it when setting up your distribution –, and its output is very easy to read and understand when something goes wrong.

Looking back at the Capistrano days, my only regret is not having done this sooner!

Your logs are part of the UI. They are streams of interesting and actionable events that will be consumed by both machines and humans.

The most useful practice I’ve followed so far is to keep that in mind and act accordingly: understand the computer systems parsing, filtering and analyzing logs and talk to all the people who will be notified when something of interest happens. Watch what they do, and ask yourself “how could the output of my application be more helpful in this scenario?”

The parties interested in your application’s logs are usually at a conflict: what’s interesting and actionable to developers and testers isn’t so important to production support engineers, and your SQL timing statements are probably seen as junk to the analytics tool looking for security issues.

In order to minimize that, whatever logging framework you’re using should be able to direct those streams of events with pre-defined (and hopefully, easily configurable) filters, and each type of environment or user should be able to have its own configuration.

Here’s a few examples to illustrate the point:

During development, it makes sense to have every debug statement relevant to the module being worked on going to the same stream, while telling the framework to take it easy with all other modules. Events from other modules may be interesting, but they should be filtered out if they’re not actionable, as you’re not going to do anything with them. Changing the filter so you can look at different modules should take no more than a few seconds of work (but may require bouncing a server or two).

While running unit tests on a continuous integration set-up, it may make sense to disable verbose logging altogether: if your automated testing environment is sufficiently mature, at least one of the tests will break and you’ll be able to replay the failure on a development workstation to get at the details. In that kind of environment, not only you want to be mindful of disk usage, the events themselves are usually not very actionable anyways.

In production, leave that configuration to people experienced with support: talk to engineers who will get paged at 3am and rushed into a cab if a particular type of error happens, and get their input. They will tell you exactly what kinds of errors they’re interested in on your application in particular. Remember this is probably specific to the domain you’re working on, and that support engineers usually take care of more than one application, and more than one server.

A very common mistake I see (looking at you, JBoss!) is to treat errors that developers should see as important (a NullPointerException, for example) and that production support people can’t do a thing about. Don’t wake them up unless there is something they can do to fix the problem, or risk crying wolf too many times and having them filtering out important, actionable notifications, like OutOfMemory errors, low disk space, etc.

[This is a translation of the previous post into Brazilian Portuguese.]

Tenho um amigo cuja esposa adora cozinhar, e ele foi incumbido de ajudá-la numa noite dessas.

Ele estava sem muita paciência, e resolveu pegar uns atalhos para acabar com a tarefa o mais rápido possível e voltar ao seu código, videogame, ou seja lá o for que lhe chamava a atenção no momento.

Em vez de trabalhar rápido e em pequenos lotes – ou lentamente, mas em grandes lotes – ele jogou todos os ovos, farinha e leite juntos de uma vez só. Misturou tudo muito rápido, enquanto mexia muito pouco. Formaram-se pelotas e, eventualmente, uma bacia inteira de massa com uma aparência terrível tinha que ser jogada fora.

O segredo, aparentemente, é misturar os ingredientes secos e molhados com muito cuidado: se você sabe que vai adicionar mais do que a mistura vai aguentar, é melhor peneirar os ingredientes secos antes, cruzar os dedos e, em seguida, misturar e mexer tudo como louco: quanto mais desequilibrada a proporção de seco vs. molhado, maior o esforço necessário para manter tudo homogêneo.

É um equilíbrio delicado, se você está lidando com uma nova receita ou utensílios desconhecidos. Na verdade, uma mudança de altitude ou a umidade do ar pode ser suficiente para mudar as probabilidades em favor de bolos medíocres.

Enquanto meu amigo me contava essa história, de repente eu percebi que a mesma coisa funciona para equipes, também: ao adicionar muitas pessoas ao mesmo tempo sem que que haja espaço para que todos absorvam e compartilhem seus pontos de vista, você está caminhando para a formação de pelotas de conhecimento e cultura, que são realmente difíceis de dissolver. Novos domínios, tecnologias e processos são variáveis a mais, tornando-se muito difícil prever se você vai acertar ou não, e que jogam as probablilidades em favor de resultados medíocres.

Mas e se você tivesse que fazê-lo? Ou, em vez disso: se você decidisse que, dadas limitações atuais, a coisa mais sensata e desejável a se fazer seria acrescentar um monte de gente numa equipe em um período de tempo muito curto? O que você faria para mantê-la livre de “pelotas”?

I have a friend whose wife loves baking, and he was tasked with helping her out one of these evenings. He was keen to cut corners and get it over with as soon as possible, so he could go back to his code, videogame or whatever it was that caught his fancy at the time.

Instead of working fast in small batches – or slowly in big ones – he mixed all the eggs, flour and milk together. Too fast, while stirring too little. It formed clumps, and eventually a whole bowl of terrible-looking dough had to be thrown away.

It turns out, the secret is to mix wet and dry ingredients really carefully: if you know you’re going to add more than the mixture will take, you better sift the dry stuff first, hope for the best and then whisk and stir like mad. It’s a delicate balance if you’re dealing with a new recipe or unfamiliar tools. In fact, a change in altitude or air humidity could be enough to tip the odds in favour of mediocre cake.

As my friend told me this story, I suddenly realized the same thing works for teams, too: add too many people at once and, unless there’s room for everybody to absorb and share their points of view, you’re going to get knowledge and culture “clumps” that are really hard to dissolve. New domains, technologies and processes: more variables, making it really hard to predict whether you’ll get it right or not, and they all tip the scales towards mediocre outcomes.

But what if you had to? Or, instead: what if you decided that, given other constraints, it’d be desirable to add lots of people to a team in a very short time span? What would you do to keep it from “clumping”?

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

Right before starting the efforts to go set up the physical space of the new ThoughtWorks Brazil office, we hit a snag: the new building where we would be located wasn’t ready yet, so we got to borrow some space from the University temporarily.

When we got there, the sign near the door said “Open Source Labs”. I never found out what happened to the lab once we took their space, but I hope they’re alive and kicking somewhere else in the building. ThoughtWorks contributes a fair deal to OSS projects, and I felt bad for taking over some of that space, even if symbolically.

Overnight, the facilities management at PUCRS cleared the rooms and gave us the OK to put whatever furniture we wanted there.

- Hey Sid…
- Yeah, Carlos?
- The furniture guys just called. We are not going to have it until the middle of next month!
- It’s been delayed again!?
- Yeah… What do we do?
- Can we talk to someone from PUCRS and see if we can borrow some in the meantime?

So we did, and they gracefully gave us access to a storage room right next to ours, full of used chairs and desks. They told us to pick whatever we needed. Most likely, this was where they stored furniture that needed repairs, as most of it was broken, scratched, wobbly or otherwise in need of repair. It took us about an hour to measure everything and pick the items we needed and that were in usable conditions.

The facilities guys didn’t let us help in the move from that point on, which was sort of disappointing. Sid and I came prepared to handle all of the grunt work ourselves that morning – I even wore shoes!

Fast forward about a month, we were ready, settled and cracking on with our first two projects already, even though at this point, our “real” furniture hadn’t arrived yet. The steady growth of the office had us rubbing elbows and bumping into each other, making us push our luck with PUCRS to get another room. They gave us that storage room next door and cleared it out, but it needed a bit of work done. Builders were hired, and after fitting it with AC, ceiling tiles and a few other bits, we moved in.

Meanwhile, the office was still growing like crazy, and we needed another desk for workstations in the new room. Unfortunately, PUCRS didn’t have any we could borrow, but one of our developers did: Lipe Sabella had just moved from São Paulo to Porto Alegre and all his stuff was still in boxes at my apartment while he looked for a place. Frankly, his dinner table propped against a wall wasn’t doing my living room much service, so we arranged to get it delivered to the office, and now we had room for another 6 people!

- We’re going to have to protect it somehow. I’ve managed not to scratch it all these years!
- Some plastic, maybe?

Picture: Luiza, Rubem and Andrea tape down the most horrifying plastic cover we could find at the neaby mall.

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 Carlos!
- Hi Suzi! (Edwards, head of recruiting recruiters and big fan of otters)
- How many emails to the ThoughtWorks Brazil info address did we get so far?
- Too many! I’m swamped at the moment, but looks like we have some good candidates!
- Cool! What do we do now?
- For now, sit tight and wait for me there – I’ll be in Porto Alegre in a couple of weeks.
- Good old short notice, short term travel?
- Exciting, isn’t it? I’ll be over for a month.
- Yay!

Two weeks went by in a blink, and I find myself sitting in the lobby of a hotel in Porto Alegre giving Suzi a big hug for being such a trooper; YYC to POA is not an easy flight, but she didn’t care. The weather lost that minus sign next to the centigrades and really, that’s all she wanted to know. Calgary was hovering around -30 C, and summer in Porto Alegre had just started to kick in, with 28-32 C at lunch time, big tropical showers in the afternoon.

She got to work as soon as the jet leg went away, and soon enough we had invited enough people to join us for a day of breakfast, some presentations about ThoughtWorks and interviews. Honestly, I don’t know how that happened: Suzi landed on a foreign country, didn’t speak a word of Portuguese and yet, a few days later, we had an event with 80 people keen to hear about us.

I was flying back and forth from São Paulo, working at the client during the weekdays and helping out with recruiting and some of the random things that can get thrown at a company trying to establish an office in Brazil. And taking Suzi to the dentist to replace a filling… but that’s another story. I became more and more familiar with the recruiting process, still a good part of the secret sauce of ThoughtWorks. I did so many code reviews I can now recite the Mars Rovers code review problem statement with my eyes closed.

We decided on the first few hires and Suzi asked me to review their offer letters, just in case there was something culturally weird.

- Well, offer letters themselves are culturally weird. It’s usually just a phone call and a “when can you start?” kinda thing.
- Oh, that I’m not doing. I want letters, printed and signed… culturally weird as that might be!
- There’s one more thing about them that’s really weird, too.
- Uh oh…
- We are called ThoughtWorks Brasil Software Ltda, Formerly Known As Oink Participações Ltda!?
- The lawyers had me put that in there. Apparently, we have to use the full name of the company. Which we’re going to change, of course… but that hasn’t been fully approved yet.
- So all the offer letters we’re sending out to this first batch of hires are going to come from ThoughtWorks, Formerly Oink?
- Yes.

Histerical laughter ensued. Fast forward a couple of weeks.

Suzi and I are talking about how exciting having the new hires start all at once and how we’d put a big ribbon in the office door for them to cut, or something silly like that. I remembered this really cool photo set she did with the folks in Calgary, and thought it’d be great to do something like that here, too.

Maybe not with the bear hats, though.


Photo: Suzi stares at a chart, for no reason

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

Since the 2nd Brazilian joined the company there has been a discussion going on at a ThoughtWorks office, somewhere in the world: should we build an office in Brazil? When, where?

Choosing Porto Alegre as the town to build our first office was something unexpected to me. Until the beginning of September last year, I had heard lots of good things about the city, but had never visited it. It came up every now and again as a good IT spot in Brazil and as a generally nice place to live.

Sid, Roy (Singham, founder of ThoughtWorks) and a few others scheduled a visit to Brazil, in October last year, for a quick tour and meetings with a few more potential clients and friends.

I was living in Santo André, my hometown, about 25km away from the client, where I was doing some coaching and whipping a few legacy systems into shape. I took a little break from the client work and joined them in the tour where we were supposed to decide on a few things like incorporation, payment and benefits packages and most importantly, location.

Being from São Paulo (well, Santo André… but if you’ve been there, you know it’s all the same urban sprawl), I’ve backed it quite strongly. For me, it’d be extremely convenient — friends, family, etc. For ThoughtWorks, it wouldn’t be so bad either: it’s not hard to find excellent talent in a city with over 25 million people, especially one where the majority of the IT market is.

Paulo wasn’t so sure. (Paulo Caroli, the second Brazilian to join… or maybe third, I can’t remember). Being from Rio de Janeiro and having a bit of a thing against São Paulo, as all Cariocas jokingly do, he argued the picture wasn’t that clear: alternatives to the high taxes, heavy competition and the cost of living in São Paulo were worth thinking about.

At this point, choosing the place to open the office was becoming more and more of a big deal. The more we did the maths, the less São Paulo looked like a good place to start, even if it seemed like the obvious choice at first. High taxes and cost of living would drive our cost base up quite significantly, nearly killing our chances of competitively offering near-shore projects to our existing clients in North America and Europe. If we wanted to start from São Paulo, we’d have to find enough local work to keep us going (and growing), but the highly competitive market would drive our prices down enough to kill any margins and we would sink. D’oh!

The crew had visited a few cities around Brazil at this point: São Paulo, Rio de Janeiro, Campinas, Salvador, but there was maybe another dozen cities in Brazil where a TW office could thrive. After a lot of digging around and looking up statistics from all sorts of sources, we narrowed down the list of potential cities to two or three, and Porto Alegre was the next one to try out.

We got there and had a couple of meetings with the directors of PUCRS, the Pontifical Catholic University of Rio Grande do Sul… and wow. They have a technology park, TECNOPUC, taking up a good quarter of the (rather large) campus. Companies like HP, Dell, Microsoft and Accenture have a big presence. It looked nothing like I imagined, though: instead of a soul-crushing sea of cubicles in high-rises full of tired people in suits crammed in a corner of the University, I found a really vibrant, open area with a few short buildings scattered between huge leafy trees. It’s the sort of place I’d like to work at; others promptly agreed.

Talks with the directors went really well, and we partnered. ThoughtWorks joined the TECNOPUC community and we started talking about how much office space we’d need, and how much they had available at the time. Meanwhile, Francisco Trindade (developer and lean dude, born in Porto Alegre, based in London at the time) showed us around town. Again, I was impressed with the quiet, nicely kept streets, parks and facilities. There are trees everywhere, a decent public transport system, a good number of restaurants and things to do.

That evening, we flew to Florianópolis to attend Ágiles 2009, where Roy had the closing keynote. We spent most of the time at the conference still trying to figure out tax codes and benefits while Roy worked on the slides.

At the end of the usual politically charged and motivating keynote, Roy announced: ThoughtWorks Brazil is ready to roll, and we’re hiring!

Picture: Roy announcing the opening of ThoughtWorks Brazil at Ágiles 2009

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.

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?