Wednesday, January 8, 2014
I remember reading the influential book “Future Shock” by Alvin Toffler as listened to a vinyl record of Donna Summers’ “Could it be magic” (Since I am not a vinyl-loving-hipster, feel free to carbon-date me based on that clue). While I have forgotten much of the book, one prediction in particular struck me the most: future technology would enable highly customizable products. One must credit Toffler’s foresight for having predicted, smack in the middle of the ‘everyone-wears-stamped-polyester-shirts’ decade, that there would be a day when, instead of buying mass-manufactured clothing, we would be able to ‘tailor’ our own clothes to very precise specifications and fashion sense.
From my hospitality background I’ve come to use the word ‘bespoke’ to refer to very individualized customization capabilities. While Mr. Toffler’s other predictions have yet to happen, the so-called “nth degree customization” is now a present possibility. Think of how you do searches in Google. Instead of forcing you, the user, to learn predicate logic syntax (e.g. Using wildcards, plus AND, OR, NOT keywords to create a specific query, the way prior search engines such as AltaVista did), Google uses sophisticated algorithms, applying knowledge of your prior searches and click-through activity, to cast a wide search net with results uniquely matched to you.
Bespoke options are now becoming more common in manufacturing and service industries. The much touted 3D printer technology and the low cost availability of ‘design-your-own’ products (t-shirts, mugs, cards), are but forerunners of what is yet to come.
Why has this level of individualization not existed until recently? True, AltaVista did not have the millions of computers now being used in Google farms, but the most fundamental attribute needed to provide complete customizability is the ability to design and implement truly flexible systems in a cost effective basis.
Without flexibility there cannot be bespoke offerings. When I speak of flexibility, I am referring to the underlying infrastructure, hardware, and systems needed to provide highly bespoken outcomes. Fact is the implementation of flexible approaches requires the use of higher-level abstractions, which are invariably very expensive in terms of resources. We’ve had to wait for Moore’s Law to finally make the cost of computing low enough to allow ‘wasteful’, flexible designs to take hold.
Long gone are the days when programmers had to squeeze out complicated algorithms while utilizing only a fraction of RAM, or when the high cost of storage required packing fields the way dates were encoded, resulting in the Y2K brouhaha. Today, you should be able to implement more flexible systems by choosing the most appropriate programming languages, data bases, and systems.
For instance, in the programming language front, there is a trend away from strongly typed languages that force programmers to perform code acrobatics, such as overloading around restrictive cast types imposed by languages, and toward more elastic weak-typed languages/scripts such as PHP, Ruby or Python.
Likewise, the advent of non-relational data bases also reflects a shift away from the very constricting, highly structured schema definitions required by traditional data base designs. After all, expecting a designer to know all the data elements, and their relationships, far in advance of implementation would be just as effective as a Soviet-era five-year plan. Whether by using document-oriented MongoDB or the RDF-based triplestore graphs favored by Semantic Web practitioners, the flexibility with which non-relational entries get constructed, indexed, and then stored, actually accelerates the decentralized view of processing to better facilitate cloud based implementations.
This under-the-hood flexibility ultimately allows deferral of design decisions toward the user. I am speaking not only of the ability to configure the software to the user’s states, but to tailor interaction experiences according to the user’s dynamic preferences. Programmers can now dynamically accommodate different user choices and interaction flows without resorting to tedious design re-factorization exercises.
The diagram below depicts the range of possibilities. If you strive for high performance, low resource implementations, you will most likely choose technologies in the center-left of the diagram. If you seek high customization then you will need to work with technologies on the right.
All in all, we are living in very exciting times whereby ultimate system designs can now accommodate the most innovative approaches. With cheaper processing power and storage, system developers can afford to be a bit freer in how software is designed. While all this flexibility can actually improve the time to market of your transformation initiatives, it does force you to discipline your approaches to prevent chaotic outcomes. As Spiderman’s uncle wisely noted, ‘with great power comes great responsibility’; so this power to be inefficient should be used wisely: to increase flexibility at all levels, rather than to lazily waste resources. A nice mix of common sense and best practices ought to do the trick. For example, if using Python, it becomes even more essential that your team abides by PEP 8 for Python style guide, peer-reviews, and other agile development practices. Also standardization of development tools (IDE) and libraries, plus strict version control and change management, combined with well-defined Q/A standards should be given the focus they deserve. In the end, you will have to rely on high team qualifications and a development culture that incentivizes doing things well.
These days I listen to music from my Spotify playlists that contain only the songs I enjoy. I listen to these virtual LPs in a bespoke fashion, while reading, “The Singularity is Near”, by Ray Kursweil. He predicts that in the near future (2045) computers will exceed humanity’s comprehension abilities. Time to listen to “Could it be Magic” once more. Let’s see how that works out!
 Although they are also referred as NoSQL systems, SQL API’s are in fact available for these.
 OK. Let’s credit Stan Lee from his Amazing Fantasy #15 (August 1962) now classic Spider-Man story.
 Yes, read this as a skeptical remark. A future blog may expand on why I think ‘strong AI’ (Artificial Intelligence reaching human-levels of consciousness) is not really feasible.