Month: November 2015

Aperture v Photos.app, El Capitan Edition

I have been a very happy user of Apple’s Aperture since 2011. I remember spending a few months using trial versions of both Lightroom and Aperture, before deciding Aperture suited me a little bit better—I think its integrated editing tools were slightly more powerful at the time and it seemed likely that Adobe would be keen not to make the built-in tools so powerful as to compete with their premier product. I was not overly worried when Apple first announced that Aperture would be discontinued because they have a track record of introducing revolutionary new products without every advanced feature in the initial version but then iterating consistently year-on-year until the gap is closed. With that in mind there was much anticipation around this Autumn’s release of OS X El Capitan, and consequently considerable disappointment that support for external editing extensions was the only addition. However it is important to remember that Photos.app was only released six months prior to El Capitan and so this was not a full year of iteration.

Although I had dismissed the initial version of Photos, with the availability of external editors to replace any missing editing tools, perhaps it is time to start thinking about the transition. Photos already has a few features in its favour, for instance it feels faster at navigating between photos, and does not spin for 30 seconds whenever it encounters a video. The advanced tools are comprehensive once you drill down enough to find them, and kudos to Apple for building a textbook example of how to make an interface that provides such a progressive user learning experience. In a taste of what new functionality is being denied Aperture hold outs, the noise reduction in Photos appears much improved over the equivalent in Aperture.

Perhaps the most significant omission is that there is no mechanism to apply an edit to only part of a photo, an equivalent of Aperture’s brushes. This may be a gap that Apple expects editing extensions to fill although I find Apertures’s non-destructive edits much quicker and simpler to use than the layer-mask approach of Photoshop and Pixelmator. There is also no way to display hot/cold regions to see under- and over-exposed areas. Photos.app also has greatly simplified camera-data and EXIF display. These are useful when trying to improve one’s photography “post-mortem” by looking at how the camera was setup for a particular (usually unsuccessful) photograph so their removal is disappointing.

Star ratings are also no longer available. In Aperture each photograph could be assigned a colour and a flag as well as a star rating, so it is easy to see that there were probably too many options for the majority of users who will be much happier with a simple “favourite” function. But when dealing with a large library having different ways to annotate a photograph is useful, a flag can signify a photograph that needs more attention before it is “finished” while star ratings can be used when dealing with many similar photographs of a single subject to distinguish the great from the merely good, and then the 1-star, “bad but captures some unique moment so worth keeping.” Another problem when dealing with multiple exposures of the same subject is that inability to do a side-by-side comparison of two-or-more photos. In Aperture it is possible to bring up all the photographs of a particular subject in a single view and eliminate them one-by-one. This seems to be completely impossible in Photos.app and therefore a complete showstopper for me because I use this feature a great deal when deciding which images from a set to discard and which to publish here.

Which of these missing features Apple will eventually bring to Photos.app is difficult to guess. Star ratings seem the most unlikely to return since only obsessive-compulsive types rate their possessions on a five-point scale, plus Apple already expended the effort to convert the ratings to keywords/tags. I sincerely hope side-by-side comparison returns since that is the raison d’être of both photograph management software and large screens. Brushes require a significantly more complex user interface, especially on an iOS, but are also an ideal use case for Apple’s new iPad Pro Pencil. Or Apple may decide that such advanced editing functionality has no place in a management app, and cede the space to third party developers via the extensions API.

On Software Engineering

I recently read an article in The Atlantic which argues that the iterative process of software development commonly used for, and particularly suited to, Internet based distribution, are not compatible with the rigour and discipline required for its practitioners to be considered “engineers”.

As the article explains, software engineering was invented as an aspirational and not descriptive title. Programming is one activity in the creation and production of software, but even this one small aspect of the activities that may be undertaken by someone with the job title of software developer or engineer can range from largely mechanical to highly creative. The article attempts to address this creative side of software by comparing it to a more colloquial definition of to engineer, meaning “skilfully, artfully, or even deviously contriving an outcome.” and then dismisses it as something no reasonable person would want when building software. Yet the best code if often sincerely described as a work of art, and this is why many people would rather have one good programmer on their team than even three or four mediocre ones.

However a beautiful building must also be functional and not fall down. It is the engineering that ensures that. Similarly while software development can be incredibly creative and fun, it also requires a large number of less exciting activities such as checking the functionality matches what the customer requested or expected and ensuring the product is free of bugs and security flaws. When working on larger projects which require multiple teams it is also necessary to have processes to detect and prevent unwanted functionality, for example malicious back doors and inappropriate hidden “easter eggs” containing adult material. This latter aspect of the job is something that demands the professionalism of a true engineer.

Whether many self-described software engineers are worthy of the title is debatable but what the author fails to realise is that the iterative software methodology he describes as a move away from software engineering is in fact the opposite—it intrinsically requires a high degree of discipline and rigour to execute well—the very thing that he says is lacking. Perhaps as an industry we are on the right path to realise our aspirations after all.