Finally, I have a legitimate excuse for my obsession with sci-fi and post-apocalyptic literature. Apparently it’s going to make me a better designer. I’ll take it! Rebecca J. Rosen explains Why Today’s Inventors Need to Read More Science Fiction:

Once any sort of technology has users, it becomes extremely difficult to change it — even if you know it should or must be changed. […] How is that affecting our social structure and values? How is that changing the way we view ourselves and even the way we understand our own mental functioning? […]

Reading science fiction is like an ethics class for inventors, and engineers and designers should be trying to think like science fiction authors when they approach their own work. […] I feel with great urgency that we need to very thoughtfully consider what we build as well as encourage that same thoughtfulness out in the world.

So much has been written about the disastrous launch of healthcare.gov. But Sheryl Solberg and Michael Shear’s Inside the Race to Rescue a Health Care Site, and Obama hit especially close to home. Much of it reads like any number of software development projects I’ve been involved in over the years:

In Herndon, as engineers tried to come to grips with repeated crashes, a host of problems were becoming apparent: inadequate capacity in its data center and sloppy computer code, partly the result of rushed work amid the rapidly changing specifications issued by the government. […]

The website had barely been tested before it went live, so a large number of software and hardware defects had not been uncovered. Fixing the account creation software simply exposed other problems; people still could not register to buy insurance. A system intended to handle 50,000 simultaneous users was fundamentally unstable, unable to handle even a tiny fraction of that. As few as 500 users crippled it, according to people involved.

Rushed work amid rapidly changing specifications… No testing before going live…

Let him who has never experienced issues like that on a project cast the first negative blog post.

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.