In episode 44 of the DrunkAndRetired PodCast the concept of one-way notebooks in Malaysia had been discussed and that in fact this applies also to servers in a certain sense: When the engineer hours for a problem become too expensive, it pays to replace the whole box instead of looking for the true cause.

This is not something new. Google for example (and also Amazon’s S3) runs on cheap, error-prone machines that are allow to fail just to be replaced by an other node. Obviously a cheap machine can be replaced cost-efficiently than an expensive box.

Rollback 20 years. Machines where expensive. Software had been tuned to exploit the machines to the leat CPU-cycle and if any thing was broken it had been fixed, because the ratio between engineering cost and hardware made this imperative.

For most apps today it does not pay to fine-tune the application, adding a bigger or an additional box is less expensive and more stable. As someone said some years ago: Software is called software because it is harder to change than hardware.

So far to the introduction, let’s think about the hard part: Software. Could we do something similar with software? Instead of fixing a bug, just dump it and take a new piece? Well, of course there is a difference between software and hardware: Just installing the software from another CD won’t fix your problem, while replacing a faulty motherboard by a new one will do.

So we have to look into what makes hardware so easy to replace and see if we can find this pattern also in software.

On key thing is standardization. Everyone who assembled a PC her/himself in the last years knows that is not really rocket-science, but it had been in way 10 years ago (I remember being a regular customer of a computer-retailer as I tried to find a memory stick for my computer). With Java we have pretty good APIs for standard components, say if you are not satisfied with Xerces, you’ll plug Saxon and you can continue.

For less low-level stuff you’ll have components. Most components are pretty heavy and require certain implementations of other components (I think one could argue that such component really deserve the name), so you are limited by that and also for some component (like your application) you don’t have much choice if any.

So what we have learned sofar: You components should be independent and must not introduce dependencies (I remember the hard time I had with Glassfish running an Hibernate app (Roller) because of ClassLoader problems with different versions of AntLR). To offer choice the components should be small enough that alternative implementations are feasible.

How to achieve the last point? This is what object-oriented programming is all about: Encapsulation.

If your objects are small and well designed they don’t have to many dependencies (with the use of IoC or DI, via Spring, for example), then you can plug together the full app, easily replace them by different implementations.

This is not feasible, if you let the object grow with every feature you implement. I therefore propose an anti-agile agility: Freeze your components and replace them by copies. If a new feature comes, this will be implemented in an independent component or a “flavour” of a component and the core of the app will configure itself by loading the appropriate components dynamically. If then one component turns out to be broken, you can simply deactivate it. This will cause only a degradation of service rather than a full outage.

Let someone reimplement the component instead of fixing it, in large projects team members change over time or are not available quickly enough, so instead of reverse engineering the code it might be quicker to implement it from scratch (using the latest APIs and best-practices of your app). Perhaps you decide to keep the original implementation, so that you’ll have a repository of implementations so that you can configure a system out of them that does the job (the faulty components are not faulty all the time, in some scope they might be better than the newer ones).

Down the road you could build reduncany into the system where the app reconfigures itself dynamically by replacing components with alternative implementations when it discovers that some might not be reliable in some situations (there is hardware that does the same).

Even in implementation stage you can profit from having multiple implementations: You can create high-level testing environments from comparing different configurations to discover dependencies and invariants that had not been discovered in the specification of the component yet (Finally an application for GAs?). Experimenting with new techniques is less risky, because you can limit the impact, by doing that you’ll become truly agile, while having somehow the “stabilty” of existing code-base (Most customers don’t want you to change code that had been accepted for production, because that yould require them to rerun their internal QA-procedures).

So the one-way stuff is not really one-way, it is recycable. That is actually good news. But as the old saying “the first one is to be thrown away”, they don’t deserve to be improved or fixed all the time. get you customer some spare parts, new or refurbished - they don’t care - as long as you work cost-efficiently.

The core requirements are: The components are either generic of have a simple interface and you have to have an infrastructure in place that can handle the configuration. Linking a dynamic libray or replaceing a jar works for generic components, like DB-drivers and XML-parsers, for business classes you have to provide the possiblity to leverage technologies like DI as a core part of the application.