Ever wonder how easy or difficult it would be to create a DIY version of anything?
America has a great DIY culture, so there's a lot of commercial support for kits that allow you to build or fix anything from reading glasses to whole kitchens. This is not how it works in other places where labor is cheaper and the tradespeople build and fix things. In such places, the interfaces (for lack of a better term) that products allow assume expertise on the part of the person using it.
Simple example: the bicycle is largely a recreation vehicle in the US. As such most of its parts are easily adjusted with knobs and such end-user friendly means. For the most part, you'll rarely have to go into a bike shop for a repair. They even have kits to clean your chain! This would be unheard of in a place like India mainly because there're tons of bicycle repair shops and people dont need the user friendly interface.
But I digress. The point I'm trying to make is that designing a product such that it can be broken down by somebody else than the original creator (or somebody skilled in the products innards) requires a different kind of thinking than just producing the product. A DIY robot kit is more difficult to make than a regular one. The key features added are:
Now take that same concept to the world of software. Why do we still not have long promised Software ICs? I think we know the answer to that one: because my concept of component that does logging (to pick a mundane, yet excruciatingly relevant-in-terms-of-my-point example) is not the same as yours :).
But there's more than one way to skin that cat. We dont necessarily need a universal agreement on what constitutes a specific component; we just need to ability to easily take components in and out of the software as often and appropriately as required. There in lies the rub, however. Our current means of doing this in increasing order of cost are:
Is there a solution? I think languages should develop ESB-like capabilities, and allow code change to be applied descriptively instead of as a stream of editor actions.
More on this later.
America has a great DIY culture, so there's a lot of commercial support for kits that allow you to build or fix anything from reading glasses to whole kitchens. This is not how it works in other places where labor is cheaper and the tradespeople build and fix things. In such places, the interfaces (for lack of a better term) that products allow assume expertise on the part of the person using it.
Simple example: the bicycle is largely a recreation vehicle in the US. As such most of its parts are easily adjusted with knobs and such end-user friendly means. For the most part, you'll rarely have to go into a bike shop for a repair. They even have kits to clean your chain! This would be unheard of in a place like India mainly because there're tons of bicycle repair shops and people dont need the user friendly interface.
But I digress. The point I'm trying to make is that designing a product such that it can be broken down by somebody else than the original creator (or somebody skilled in the products innards) requires a different kind of thinking than just producing the product. A DIY robot kit is more difficult to make than a regular one. The key features added are:
- the ability to be broken down into pieces with well defined interfaces
- the ability to integrate with other pieces to form the whole product.
Now take that same concept to the world of software. Why do we still not have long promised Software ICs? I think we know the answer to that one: because my concept of component that does logging (to pick a mundane, yet excruciatingly relevant-in-terms-of-my-point example) is not the same as yours :).
But there's more than one way to skin that cat. We dont necessarily need a universal agreement on what constitutes a specific component; we just need to ability to easily take components in and out of the software as often and appropriately as required. There in lies the rub, however. Our current means of doing this in increasing order of cost are:
- Configuration: which is the hardwired ability to switch between known behaviors of a component
- Code Change: which is the hard ability to change the behavior of a component from the current to the desired. This is the snapshot based development that I've blogged about before.
- Integration: which is the tying together of fairly coarse components with known behavior to realize a larger, compound behavior. The integration itself could be via configuration (better) or code change (not so good)
Is there a solution? I think languages should develop ESB-like capabilities, and allow code change to be applied descriptively instead of as a stream of editor actions.
No comments:
Post a Comment