Archive for the ‘software design’ Category

A call for indie software development

Wednesday, November 4th, 2009

Years of open soruce software development, aimed at perfecting the engineering craft and providing alternative and resources for new developers to learn, though sucessfull mission, have failed to provide side effects that some of us hoped for. The hope was that the open software would enable to the many to express the creativity, and start creating new qualities of software, exploring new territories, and moving the experience of working on building software, from craft to something more closely related to an art.

If we observe the similar process, as happening in music, in the last century, is exactly that by providing tools for creating music available to many - it became possible for many to create new qualities, regardless of their skillset, as long as they can formulate a long-lasting “art” aspect of it. A lot of indie music today is aimed at creating something “new” rather than creating somehting “perfect”. Even though a lot of this would end up on the dumpster, the long-term effect is explosion of the field it that more and more of “new terittories” are being explored, and every once a while a flags have been raised. This makes all of our lives richer and helps us advance, which was the meaning of it all.

Naturally, a call for a similar initiative in software is needed - a call for creating a software aimed at creating something “new” - rather than creating something “better”, “cheaper”  - a call for creating something with art-like qualities to it , with the sense of individual expression and exploration.

… to be continued

Posted in software design | No Comments »

Go game as a paradigm for software design

Monday, September 7th, 2009
GO board

In “low-latency” software development, there is often not much time for designing of the development process, and even less for applying it. Therefore, standard top-down/bottom-up and similar methodologies are abandoned in favor of pure ad-hoc development. However, if the product of development is to be used for a non-zero post-finish time, this is the first tradeoff that one usually regrets.

We propose a idea adding a sort semi-structure to the “ad-hoc” software development process, based on analogy with the famous game of Go, that might help in adding some structure and predictability to the development, while keeping most of the “virtues” of ad-hoc process.

Let’s start by restating the fact that each desing decision is in fact a tradeoff - that is, each feature (represented by white peg) - results in a tradeoff made (represented by black peg). Assuming that in ad-hoc development, there is no real order (at least not in the sense of order in tree-oriented designs), we can model the process as a 2D grid (go board) on which we place features and tradeoffs, and with the “cleverness” of design represented in the placement of a tradeoff (black peg) relative to placement of feature (white peg).

In the setting of Go game - our goal might be striving towards maximum occupancy of game space by white pegs (by being “clever” and eliminating trade-offs over time). However this approach comes with a risk - as, depending on player’s skill, it is more or less possible to have features captured and eliminated by trade-offs made in the process, to the extent of “loosing game” which might even mean demise of entire development effort. Fortunately, in the same setting, there is alternative of making “snake eyes” - a pieces of territory that cannot be captured. This might not contribute to complete “victory” - but provides a sensible alternative for less skilled player in achieving at least some points. In context of software - this might be exactly the solution that we need.

Let’s elaborate a bit on the topic of snake-eye “patterns” and their creation process …

Posted in software design | No Comments »