This week: Amazon AWS's pros & cons, an iOS developer's time at Google, and the self-similarity of late software projects.
Upsides and downsides of AWS: a startup's view
Laurie Voss posted on the awe.sm blog about the company's experience with using various Amazon AWS services. The startup has been hosted on AWS since its beginnings 3 years ago -- long enough to have formulated an internal set of best practices for using AWS to best advantage.
The nub of awe.sm's advice is to exploit AWS EC2 and S3 to the maximum extent possible, and to avoid any other AWS value-added service. They have come to believe that Amazon's well-publicized major failures mostly trace back to its Elastic Block Store (EBS). And several other AWS services are built on top of EBS, so they will fail too when EBS does -- "Elastic Load Balancer (ELB), Relational Database Service (RDS), Elastic Beanstalk, and others," according to the blog post.
This advice goes against Amazon's own expectations about how customers will make use of EC2. According to Voss,
EBS is fundamental to the way AWS expects you to use EC2: it wants you to host all your data on EBS volumes, and when instances fail, you can switch the EBS volume over to the new hardware... It wants you to use EBS snapshots for database backup and restoration. It wants you to host the operating system itself on EBS...
The problem, besides EBS's tendency to cause region-wide failures, is that EBS storage doesn't perform well, and its nature (a network drive masquerading as a block device) can cause severe problems on Ubuntu because it breaks the prevailing storage abstraction.
Read Voss's post and think carefully about how you can best make use of Amazon's undeniably magical AWS service.
All late projects are the same
This classic article (PDF) summarizes Tom DeMarco's thinking over a 50-year career about how software projects fail. (The article is from 2011 but seems timeless.) DeMarco makes the case that software teams often take the fall for mistakes that occur in other areas before a software project is even initiated. Almost all projects run late because they didn't start early enough, DeMarco claims, and then explains why this is not merely the tautology it seems at first glance. Starting the project on the date it would need to start in order to get done on the required end date would mean acknowledging how expensive the development would actually be. Most departments in most corporations are allergic to any such acknowledgment, regardless of the project's expected payoff.
A vector codec
This research out of the University of Bath could portend large changes in the web, mobile, TV, video, and numerous other areas. Researchers there have developed a codec that encodes or decodes a digital video stream in vector format, and intelligently shades the areas between vector lines in order to recover the full fidelity of the original. Here are the abstract and the journal article, Constructing and Rendering Vectorised Photographic Images (PDF), slated for an upcoming edition of the the Journal of Virtual Reality and Broadcasting. The team has put together an intriguing but somewhat mysterious video of how the software renders color images. The researchers are working with Root6 Technology, Smoke & Mirrors, and Ovation Data Services on applications in video post-production. They are actively seeking industry partners to explore other areas such as the web, tablets, and mobile.
An iOS developer at Google
Chris Hulbert spent three months doing iOS development at Google Australia, and he pulls back the covers on some of the development methodology in use there. He discusses workflow, the tools in use, and the place of design in the scheme of things at Google. I did wonder whether Hulbert had signed a non-disclosure agreement and whether he might be sailing a bit close to the wind with this post.
The Friday Four gives a hat tip each week to Ron Miller, whose collection of five links for developers and IT pros runs weekly on Ness.com.