The front-end team at Booking.com continues to grow and we are looking for talented UX Designers, Web Designers, Product Owners, and Front End Developers to come help us create the world’s best accommodation platform.

You’ll work at our head office in central Amsterdam which is sandwiched in-between canals, museums and the occasional statue of an old Dutch master (good evening, Mr. Rembrandt). We’ll pay to move you and your family from anywhere in the world; USA, Portugal, New Zealand, Brazil, Japan, just to name a few! We’ll provide short-term accommodation and help you adjust to your new home in Amsterdam. You’ll be given the freedom to make impactful improvements to a website and collection of apps used by millions of people. We also have unique company perks like bicycle reimbursement, on site lunch, monthly parties, and our world class year end party complete with live performances!

Apply today.

Sponsorship by The Syndicate.

Still encoding video with on-premise hardware? Encoding.com is the world’s fastest cloud encoding service. We’ve made proprietary optimizations for ingest, queue times, processing, and egress of your source content that rivals the fastest on-premise equipment, with infinite scalability.

We support nearly every video format imaginable, including a few that only we offer. We can accommodate a number of different transcoding workflows with an easy to use web interface, a flexible watch folder, a desktop uploader, or our robust and mature API. You can even automate basic editing tasks such as video overlays and concatenation programmatically using our API.

Vid.ly is a unique feature of our service that completely takes the guesswork out of your transcoding workflow, combining transcoding, device detection, delivery, and storage into a single short url.

Don’t take our word for it, try our forever free account today, complete with your own API key.

Sponsorship by The Syndicate.

Lucas Rocha talks about the importance of designers and developers working closely together in Mind the Gap:

Iterative design processes that engage designers and engineers very early tend to result in higher UI quality because it provides the necessary flexibility and agility to steer ideas as they are implemented. Sounds obvious but this is much easier said than done. Just see how rare is to find products with outstanding user interfaces.

This is very true, and the power of small, collaborative teams have been proven time and again. But it’s important to take this further. It’s not just about collaboration, it’s also about empathy. If designers and developers collaborate but they don’t understand each other, you’ll still get nowhere.

The main issue is that designers and developers approach their respective crafts from very different perspectives. Design is about composition — how to put things together so that the whole makes sense. Development is about deconstruction — how to break down the whole into pieces that can be implemented effectively. That creates a disconnect that is difficult to overcome if their isn’t empathy between the two groups.

Thomas Petersen describes the ideal situation really well in Developers are from Mars, Designers from Venus:

They are the developers who can design enough to appreciate what good design can do for their product even if it sometimes means having to deviate from the framework and put a little extra effort into customizing certain functionality. […]

And they are the designers who learn how to think like a programmer when they design and develop an aesthetic that is better suited for deconstruction rather than composition.

So, it’s not just about meeting more often. It’s also about meeting in the middle to accomplish a common goal together.

PS. All of this reminds me of this matrix on how designers, developers, and project managers see themselves and each other in most organizations:

Image source: Les développeurs, graphistes et chefs de projets

John Naughton wrote a good summary of the Mythical Man-Month problem (the belief that adding more people to a project will get it done faster) in Why big IT projects always go wrong:

Man-months are a hopeless metric for assessing the size of a complex software project. Why? Basically because a big software project involves two kinds of work: the actual writing of computer code; and co-ordinating the work of the dozens — or maybe hundreds — of programmers working on different parts of the overall system. Co-ordination represents an essential but unproductive overhead: and the more programmers you have, the bigger that overhead becomes. Hence Brooks’s law: adding manpower to a late software project makes it later.

I’ve yet to see a large project where this law doesn’t apply.

Develop Smarter, Simpler and Better Connected Apps with Javascript

Imagine connecting your app to everything with just 2 lines of code — files from all over the web, across cloud storage source, social networks and devices.

Filepicker.io provides a full file system API for your web and mobile applications that allows your app to upload, open, read, write, store, sync and convert files from over 17 sources including Dropbox, Google Docs, Facebook, Skydrive and Box. With the Filepicker.io Javascript API, request a file and receive a simplified URL. Then, upload the URL to your server or serve through your CDN.

Filepicker.io includes a customizable drop-in UI widget and an API library allowing you to send uploaded files directly to your S3. Sign up for Filepicker.io today!

Sponsorship by The Syndicate.

Jessi Hempel’s The second coming of Facebook is a very interesting profile of the company and where it’s headed. There’s one paragraph in particular that has stuck with me for the past few days:

At Facebook developers choose the projects they want to work on, and product groups compete to woo them. Managers sent out reports highlighting the product teams that were doing a good job. Pretty quickly teams realized that if they wanted to get praised in the weekly memo, they needed to start recruiting mobile developers.

My first thought was that this is a great idea. If you want to get something done at Facebook, your idea has to be interesting and challenging enough to convince developers to work on it, otherwise it just won’t happen. I’m sure this weeds out a lot of ill-conceived project ideas.

But there’s a problem with this approach. If Product Managers have to convince developers to work on their projects, they are going to pitch ideas that have a big chance of being interesting to… developers. Not to Facebook users. So there’s a danger that the product features being pushed out are wild and challenging and extremely interesting, but don’t meet user needs particularly well.

In the example cited in the article, an internal weekly memo effectively changed the company’s entire roadmap by shifting attention to mobile. Not that shifting to mobile is a bad thing, but too much focus on things like who gets praised in an email has the potential to seriously derail a company.

Still, the idea is really appealing: making Product Managers effectively vie for developer attention ensures that the PMs do their homework so that they can sell and defend their ideas to the company and to customers. That’s a worthy cause. It would be great to make some form of user validation part of what happens before projects are pitched, though. I guess I just remain weary of the prevailing myth that we are like our users.

I know I just wrote about coffee, but this one is too good not to link to. In Coffee and the Art of Customer Happiness Mathias Meyer writes about the similarities between making coffee and developing software:

Baristas are geeks, just like we are. They love talking about the latest toys, about which espresso machine is better than the other, they compare paper filters with cloth, and they take detailed notes on the different aromas of coffee when they’re cupping it.

The craft of coffee making is quite fascinating, both from the perspective of precision and customer care.

Mathias discusses familiar topics like metrics, continuous delivery, and custom vs. off-the-shelf software, and what the art of coffee can teach us about each. Great article.

(link via @bb)

Joel Spolsky wrote a great post on some of the hidden costs of software development. From Software Inventory:

The “cost” of code inventory is huge. It might add up to six or twelve months of work that is stuck in the assembly line and not yet in customers’ hands. This could be the difference between having a cutting-edge product (iPhone) or constantly playing catchup (Windows Phone). It’s nearly impossible to get people to buy Windows Phones, even if the iPhone is only six months better. A lot of markets have network effects, and being first has winner-take-all implications. So getting rid of inventory in the development process can make or break a product.

He goes on to propose an alternative to Backlog Grooming — one of the central tenets of Agile development:

The trouble is that 90% of the things in the feature backlog will never get implemented, ever. So every minute you spent writing down, designing, thinking about, or discussing features that are never going to get implemented is just time wasted. When I hear about product teams that regularly have “backlog grooming” sessions, in which they carefully waste a tiny amount of time and mental energy every day or every week thinking about every single feature which will never be implemented, I want to poke my eyes out.

His proposed solution is quite radical from an Agile perspective, and I’m not sure how it would work on large redesign/replatform projects, but it’s certainly worth considering.

Matt Simmons wrote a great post on designing elegant solutions for when users inevitably make mistakes on your system. In Engineering Infrastructures For Humans he uses the example of ash trays in airplanes to make his main point:

You don’t engineer your systems with the belief that none of your computers will ever break. That’s insane; you KNOW they’re going to break. So don’t assume that your users will never break the rules. Build in graceful failure as often as possible, whether you’re designing a user interface or a security policy.

The ash tray story is really interesting, so be sure to click through to his post.

Jeff Atwood starts his article This Is All Your App Is: a Collection of Tiny Details as a post about cat feeders, but stick with it. It’s gold:

Getting the details right is the difference between something that delights, and something customers tolerate.

Your software, your product, is nothing more than a collection of tiny details. If you don’t obsess over all those details, if you think it’s OK to concentrate on the “important” parts and continue to ignore the other umpteen dozen tiny little ways your product annoys the people who use it on a daily basis ”“ you’re not creating great software. Someone else is. I hope for your sake they aren’t your competitor.