Would you hire an open source developer?

January 3, 2018

This blog post of mine was initially published by Computerworld UK in 2010.

As open source comes of age and becomes mainstream, more and more job postings include “open source skills” in their requirements.

But do you really want to hire someone who spends their time exchanging flames with members of their own community in public forums? Someone who greets newcomers with “I have forwarded your question to /dev/null, thanks” and other RTFM answers?

Luckily, open source communities are not just about being rude and unwelcoming to strangers. Most of them are not like that at all, and the skills you learn in an open source community can make a big difference in a corporate environment as well.

One very important skill that you learn or improve in an open source community is to express yourself clearly in written form. The mailing lists or forums that we use are very limited compared to in-person communications, and extra care is required to get your message through. Being concise and complete, disagreeing respectfully, avoiding personal attacks and coping with what you perceive as personal attacks are all extremely useful skills on the job. Useful skills for your whole life actually.

Once you master asynchronous written discussions as a way to build group consensus, doing the same in a face to face meeting can be much easier. But the basic skills are the same, so what you learn in an open source community definitely helps.

Travel improves the mind, and although being active in open source can help one travel more, even without traveling you’ll be exposed to people from different cultures, different opinions, people who communicate in their second or third language, and that helps “improve your mind” by making you more tolerant and understanding of people who think differently.

Not to mention people who perceive what you say in a different way than you expected – this happens all the time in our communities, due in part to the weak communications channels that we have to use. So you learn to be extra careful with jokes and sneaky comments, which might work when combined with the right body language, but can cause big misunderstandings on our mailing lists. Like when you travel to places with a different culture.

Resilience to criticism and self-confidence is also something that you’ll often develop in an open source community. Even if not rude, criticism in public can hurt your ego at first. After a while you just get used to it, take care of fixing your actual mistakes if any, and start ignoring unwarranted negative comments. You learn to avoid feeding the troll, as we say. Once your work starts to produce useful results that are visible to the whole community, you don’t really care if someone thinks you’re not doing a good job.

The technical benefits or working in open source communities are also extremely valuable. Being exposed to the work and way of thinking of many extremely bright developers, and quite a few geniuses, definitely helps you raise the bar on what you consider good software. I remember how my listening skills improved when I attended a full-time music school for one year in my youth: just listening to great teachers and fellow students play made me unconsciously raise the bar on what I consider good music.

Open source communities, by exposing you to good and clever software, can have the same effect. And being exposed to people who are much better than you at certain things (which is bound to happen for anybody in an open source project) also helps make you more humble and realistic about your strengths and weaknesses. Like in soccer, the team is most efficient when all players are very clear about their own and other players’ strengths and weaknesses.

You’ll know to whom you should pass or not pass the ball in a given situation.

To summarise, actively participating in a balanced open source community will make you a better communicator, a more resilient and self-confident person, improve your technical skills and make you humbler and more realistic about your strengths and weaknesses.


Great software is like a great music teacher

January 3, 2018

This blog post of mine was initially published by Computerworld UK in 2010.

I’m amazed at how many so-called “enterprise software systems” do not embrace the Web model in 2010, making them way much harder and much less fun to use than they should be.

I have recently started making parallels between this and music teachers, and the analogy seems to work. Don’t ask where the parallel comes from…weird connections in my brain I guess.

Say you want to learn to play the guitar. Someone recommended Joe, who’s teaching in his downtown studio.

You get there almost on time. Traffic. You find Joe’s studio and here he is, dressed in a neat and simple casual outfit. Smiling at you.

Joe: Hey welcome! So you wanna learn to play?

You: Yes. I brought my guitar, got it from my uncle. It’s a bit worn out as you can see.

Joe: I see…well, you might want to get a better one if you continue past the first few lessons, but for now that will do! Do you have something that you would like to play to get started?

You: “Smoke on the water”, of course. The opening line.

Joe: Let’s try that then, I’ll show you! Just plug your guitar in this amplifier, and let me setup some nice effects so you get a cool sound.

Joe plays the first few bars a few times, shows you how that works and you give it a try. Ten minutes later you start sounding half-decent and you’re having loads of fun playing together with Joe.

Joe: Okay, you’re doing good! I’ll show you my rough course plan so you know what’s up next. I’m quite flexible when it comes to the curriculum – as long as you’re having fun and progressing we’ll be fine.

It’s easy to imagine the bad teacher version of this story:

  • Unwelcoming
  • Complains because you’re three minutes late.
  • Wears a boring old-fashioned suit, and not willing to let you play that crappy old guitar.
  • Boring you with tons of scales before you can start playing a song.
  • Not giving you an overview of what comes next.
  • Not ready to compromise on His Mighty Standard Teaching Program.
  • Making you feel stupid about how bad a player you are.

Bad software is like that bad teacher:

  • Hard to get started with.
  • Requires tons of specific client software of just the right version.
  • Requires you to enter loads of useless information before doing anything useful or fun.
  • Not willing to let you explore and do your own mistakes, and making sure you feel stupid when mistakes occur.

The Web model is the way to go, of course.

  • Ubiquitous access.
  • Welcoming to various types of client software.
  • Easy to point to by way of permanent URLs.
  • Doing its best (fail whales anyone?) to keep you informed and avoid making you feel stupid when something goes wrong.
  • Letting you explore its universe with simple web-based navigation, and rewarding your efforts with new discoveries.

This is 2010, and this is the Web. Don’t let any useless software stand between you and the information and services that you need.


Microservices? Nah…Federated Services!

March 17, 2016

As much as I like the microservices concept (*) the name does not really make sense to me.

Why would decoupled services necessarily need to be micro?

Focusing on a service’s size is the wrong crusade for me, I’m happy as long as a service does one thing and one thing well – but that thing might be too large for a micro service.

We had good discussions about this with my colleagues and on Twitter recently, and after some virtual brainstorming it’s my good Apache friend Santi Gala who came up with the Federated Services term (worth a drink-of-your-choice Santi of course, next time we meet!).

I think this describes what we are after much better. Rightsizing makes much more sense than necessarily making things very small.

So here we go, with a Twitter-compatible less-than-140-characters definition:

Federated Services are independently deployable, scalable and swarm-friendly software components with language agnostic interfaces.

That’s it. I don’t think we need more than that to define those services.

WDYT?

(*) I’m working on a blog post about some elements the history of service oriented systems with another good Apache Friend. Stay tuned!


It’s just a Web server – a plea for simplicity

June 16, 2014

I’m currently working on my keynote for next week’s Connect – Web Experience 2014 conference in Basel and very much looking forward to it! Last year’s conference was excellent, and this year’s schedule looks very exciting.

My keynote is about the value of simplicity in software – including a few tales from the trenches.

We like to think of what we build with AEM as large enterprise systems, with complex requirements. Intricate workflows. Rocket science.

However, when you think about it, our systems are “just” HTTP request processors, that manipulate atomic pieces of content in a content repository.

What if you wanted to manage the Whole World Wide Web with a single system? The architecture of that 4WCMS might be quite similar to what Apache Sling provides for AEM: mostly independent dynamic HTTP request processors, selected by path and resource type, that render and/or process resources from a huge tree of content.

If our architecture works for that 4WCMS, the systems that we are actually working on are just peanuts compared to that. Managing a single site, or just a small federation of a hundred thousand sites? Easy. Yes I’m being provocative – it’s a keynote!

The inherently scalable architecture of the Web, combined with the natural decoupling that HTTP and REST (and OSGi) provide, should allow us to keep our systems simple, transparent, robust and adaptable. Yet, much too often, we fall into the “entrprisey” trap and start designing complex machinery where something simple would do – if only someone had the guts to challenge the status quo.

I have a few examples in mind, from past projects, where simplicity provided huge wins, even though it required convincing customers that had different, usually more complex ideas. My goal is to demonstrate how valuable simplicity is, and how expensive it can be to create initially. Like the story of those 28 lines of code that took three months to create, in 1999, and still live happily in production with Zero Bugs.

We shouldn’t give up – creating simple things is a lot of work, but the rewards are huge.

To paraphrase Blaise Pascal, if your system is complicated it usually means you didn’t work hard enough to make it simpler. Or maybe you have a really complex problem, but that’s not very common. And maybe that complex problem is the wrong one to solve anyway.

I hope to see you next week in Basel and until then – keep things simple!


Sony Bridge for Mac, a perfect example of second-system effect #fail!

April 3, 2014

I’m sorry to be ranting here instead of writing about more creative things, but here’s a perfect example of the “second-system effect” – replacing simple software that works perfectly well with something supposedly more powerful…that doesn’t work.

My Sony Xperia V phone used to upgrade over the air. Get a notification, wait until you have a good Internet connection, start the upgrade, wait a few minutes and you’re done. Who needs more than that?

Sony apparently thinks that’s too simple. Or maybe they have other reasons to start forcing users to use their brand new shiny Sony Bridge desktop software for updates. Reminds me of my first Samsung Galaxy, years ago…I hope Samsung’s over that by now – but I digress.

There doesn’t seem to be another option to upgrade my phone this time, so I play nice, downdload and install the latest Sony Bridge V3.7.1(3710) software tool, connect my phone to my computer and start the bridge tool. Oh, by the way: how do you upgrade if you don’t have a computer? What’s with “mobile first”? But I digress.

And here’s the first “fun” result: the tool refuses to upgrade my phone now because the battery charge is less than 80%. Oh my.

IT IS PLUGGED IN, STUPID! How could you talk to it via USB otherwise? Fail. Sony Bridge, I’m starting to hate you. No, really.

Ok, I’m a good boy. I wait until my battery reaches 80% and try again. Hurray! I can get to the upgrade screen this time.

The tool says “Initializing” and “Talking to Update Engine”.

And it stays there.

And time passes.

Fourty-seven minutes now. 47 MINUTES and exactly nothing else happens. No feedback. No progress. No error messages. Did you guys take UX 101 in school? I guess not.

Sony Bridge #fail screenshot

Forget the Cancel button…it doesn’t work.

I tried twice. Had to delete some secret cache files in between both attemps, as on the second time the tool was telling me that my phone is up to date, but it’s not, as the phone itself tells me.

The result of this brilliant software evolution? I am unable to upgrade my phone. That will make it useless soon, I guess, and I didn’t pay a sizeable amount of money to have a non-upgradeable phone.

So here we have a perfect example of what software folks should NEVER do: replace a perfectly working simple system (over-the-air updates) which a new shiny thing that DOESN’T WORK and makes me YELL here which is quite unusual. Ok, maybe you don’t care about me yelling, but if you’re Sony I would expect you to be more clever than that.

So, Sony, I guess I’ll ask for a refund for this now useless phone. What do you think?

But of course, the best by far is just to re-enable over-the-air updates. That used to work very well.

Update: I was finally able to upgrade my phone by running the Sony Bridge train wre^H^H^H^H^H^H^H^H^H software on an old macbook. But still…why?


RESTful services as intelligent websites

March 27, 2012

Thinking of RESTful services as intelligent websites helps drive our architecture decisions towards simplicity, discoverability and maximum use of the HTTP protocol. That should help us design services that are easier to use, debug, evolve and maintain.

In this post I’ll try to address a few important aspects of RESTful services, considering them as intelligent websites. We might need more formal specifications in some cases, but this is hopefully a good start.

Discoverability and service homepage

Having a descriptive homepage for your service helps search engines and people discover it, and the base service URL should “never” change. Service-specific subdomains come to mind.

The service homepage includes all the necessary information such as service owner’s contact information, links to source code, etc.

News about service updates live right here on the service homepage, ideally as full content for the most recent news, but at least as links.

The key idea is that I shouldn’t have to tell you more than the service homepage’s URL for you to be able to use the service.

Even if your service is a company-internal one that’s not meant to become public, having a decent-looking homepage, or at least one that’s well organized and well readable, won’t hurt.

HATEOAS

In my pragmatic view Hypermedia as the Engine of Application State basically means links tell you where to go next.

In a website meant for humans, the meaning of a link is often expressed by logical groups: navigation links at the top left, “more info” links in a smaller font at the bottom of a page, etc.

For machines, adding rel attributes to <link> elements (in HTML, or the equivalents in other formats) tells us what we can do next. A client should be able to first try a link with non-destructive results, and get a response the supplies details about how the specified interaction is supposed to work. If those details are too involved to be expressed in a simple HTTP request/response (which should be a “maybe this is too complex” warning), links to explanations can be provided in the HTML content of our intelligent website.

Self-explaining services

The service documentation, if any is needed, is also provided on the service homepage, or linked from it.

Service interactions are designed to be as obvious as possible to minimize the need for documentation, and readable automated tests (hosted on the service website of course, or linked from it) can help document the details.

HTML forms describe service parameters

HTML forms are best way to document the service parameters: provide a form that humans can use to play with the service, with enough information such as lists and ranges of values so that users can figure out by themselves what the service expects.

The idea is that a human user will play with your service from the HTML form, then move on to implementing a client in the language of their choice.

The action attribute of <form> elements also contributes to HATEOAS – intelligent clients can discover that if needed, and it’s obvious for human users.

And of course, speaking of parameters, be liberal in what you accept, and conservative in what you send.

Speaking in URLs

Like humans, RESTful services need to be precise when they speak about something important.

If your service response says invalid input format for example, it’s not hard to include in that response an URL that points to a description of the correct input format. That makes all the difference between a frustrating and a useful error message, and is part of HATEOAS as well.

Web-friendly responses

Readable response formats will help people make sense of your service. The HTTP protocol does provide standard ways of compressing responses to avoid using more bandwidth than needed, so optimizing the response for wire efficiency does not make much sense unless you’re really expecting measuring huge traffic. And even if you need an optimized binary response format, there’s probably a way to make that optional.

HTTP status codes

Thou shalt not abuse HTTP status codes – or you might be suddenly transformed into a teapot.

Returning a 200 OK status code with content that describes an error is a no-no: if something went wrong, the HTTP status code needs to express that.

Security

Website authentication and authorization mechanisms and secure connections work for machine clients as well, no need to reinvent that wheel.

HTTP sessions are a bad idea in a RESTful context of course, state is driven by hypertext as discussed above.

Character encodings

The issues are the same for human users as for machine clients: you need to play by the HTTP protocol rules when it comes to character encodings, and using UTF-8 as the default is usually the best option.

Stable service URLs

As with good websites, once a service has been published at a given URL, it should continue working in the same way “forever”.

A substantially different new version of the service should get its own different URL – at least a different path containing a version number, or maybe a new subdomain name.

Long-running jobs

Regardless of human or machine clients, you usually don’t want HTTP requests to last more than a few seconds. Long-running jobs should initially create a new resource that describes the job’s progress and lets the client know when the output is available. We’ve had an interesting discussion about this in Apache Stanbol recently, about long-running jobs for semantic reasoners.

Service metadata

Non-trivial services often have interesting metadata to provide, which can have both static and dynamic parts, like configuration values and usage statistics for example.

Here again, the website view helps: that metadata is just made accessible from the service homepage via links, ideally with both human (a href) and machine (link rel) variants.

Coda

Designing your RESTful service as an intelligent website should help people make good use of it, and will probably also help you make its interactions simpler and clearer.

If your service can’t be presented as a website, it might mean that your interaction design is not optimal, or not really RESTful.

I’m happy to see these opinions challenged, of course, if someone has any counter-examples.

Update: I should have mentioned that this post, and especially the “intelligent websites” concept, was inspired by conversations with Roy Fielding, in the early days of Apache Sling. I haven’t asked him to review it, so this doesn’t mean he would endorse the whole thing…I’m giving credit for inspiration but still liable for any mistakes ;-)

Update #2: See also my REST reading list, a regularly updated collection of links to articles that I’ve found useful in understanding and explaining REST..


Turning 42, and why I love my job

August 24, 2011

I’ll be turning 42 in a few months (counting in base 12 of course) and it feels like a good time to reflect on what it is that makes my job enjoyable. My father was a carpenter, and both my brothers started with that as their first job, so I’m kind of the disruptive element of the family (I didn’t say black sheep, ok?).

So, why did I choose to work with cold electronics (my first degree) and computers instead of working with a noble and beautiful living thing like wood?

After some thinking I came up with four key elements.

The first key element is creating cool things. Note that I don’t say creating cool software: I realized that for me the creative process is more important than what exactly is being created. Coolness is obviously a subjective measurement, so it’s hard to define precisely. Lean and maintainable software that people find useful definitely falls into that category for me.

Next is working with bright and fun people. Being active in the Apache Software Foundation, and joining Day in 2007 made me realize how stimulating it is to work with people that impress you every day with their technical and other skills. People who are fun to work with help keep some distance with the Big Problems At Work. Technical and other problems are bound to happen in any job, and that’s when your colleagues’ attitudes make all the difference. Software and work are not always the most important things in life.

Using efficient and fun tools comes next – in my previous life as an independent software developer and architect I sometimes had to put up with lame environments and tools at customer sites, and that can be depressing when you’re aiming for quality and efficiency. My first grade math teacher kept saying that good craftsmen use good tools, and she was right!

The fourth element is keeping a good work-life balance. I tend to engage myself 100% in my work, but for that to happen I need to be able to engage myself 100% in other things at regular intervals. This often means disconnected holidays “away from the grid”. I also decided long ago to never work on Sundays, unless there’s really no other way, which is rare. This has helped me keep my sanity during those phases when the rest of the week is totally crazy.

The fun thing is that those four elements would totally apply to being a carpenter…and I actually did enjoy helping at my father’s shop during school holidays when I was a kid. I’m not planning on going back though – now that my son learned carpentry as well, he’s making fun of me every time I try!