Read LeakyAbstractions if you're not familiar with that concept.
If you have a difficult time grasping how changes in abstraction layers can bite a schedule in the arse, here's an example from a team I worked on:
The prior version of a handheld application the team was working on knew how to trigger the camera on the device to capture an image. No big deal.
Then a newer model of the device was selected by management to be deployed to end users and the technical team eventually got one of the new devices to try the software with. When they did, they discovered the application could no longer trigger the camera on the new device. Why? The device manufacturer had decided to change the interface (the key abstraction here) to the camera, and utilize a new API provided by the manufacturer of the OS.
Unfortunately, this all went down during a stressful time of the project and apparently some executives complained that the technical team should have known about this change in the device and accounted for the day and a half they lost to figuring out how to accommodate this unforeseen change.
The technical team was initially proud of the fact they'd been thrown such a curve ball and had still hit the ball. Any complaints may have quickly stomped out that fire by having an unreasonable expectation for being able to predict the future.
The problem is it's way too easy to use hindsight to connect the dots and think they should have been connected. Reality is things take time to get to. On reflection, the technical team couldn't get the new device any faster, because the newness of the device had restricted inventory and the manufacturer was delayed in getting the team the device.
Go read EmergentAngst for another take on ‘shouldas’.
tags: ComputersAndTechnology
