|
I just spent almost an hour watching a video of the keynote presentation of Alistair Cockburn at Agile 2009; someone I have respected for a long time (since his effective use cases work). Normally I do not watch videos, at least not longer than a few minutes. The reason is probably that glancing over a text is much easier, hence it is easier to limit the time to spend on a text document, while getting a fairly good impression over the contents. Anyhow, this video registration of a talk was definitely worth it.
As an aside, this video comes from a great source of information on software development practices: www.infoq.com; one of the great feature of this site is that they showcase many presentations with both a small video of the person speaking, as well as the the slides that are used (not from video, but in large and sharp 'digital' quality). So, please check out this talk, titled "I Come to Bury Agile, Not to Praise It", and do not be scared by the introduction, which I frankly found a bit 'for effect', rather than interesting or entertaining..
Now, from many interesting ideas about software development in that talk, I'd like to point out two:
-
First, Cockburn starts off by characterizing software development as: "developing software consists of people, making ideas concrete, in an economic context". I guess it is easy to understand why I like this a lot; it very closely reflects my personal summary of software engineering as "technology. people. value.". Here, the technology part comes in when we try to make the ideas about a system and its requirements concrete, and value refers to the economic context. In other words; we are in violent agreement about what are the essential concepts of software development.
- Secondly, he states that software development is a cooperative game, and he puts software development in the finite goal-directed quadrant, IT-systems in the open-ended g, and product-lines are comparable to infinite games. Scalable design is exactly about this: it is about open-ended and infinite games, where the problem of managing software development is not just to get the product out (i.e. make the move), but also set up the infrastructure to be able to make the (best possible) next iterations (i.e. think of a strategy and execute it). This infrastructure consists of several dimensions: the organisation, the process, the skills, the platforms, and the software design itself. So, just like you can never win a game of chess without thinking ahead, setting up a strategy, and preparing your later moves, scalable software requires you to think ahead, and plan for the future. On the other hand, if your task fits in the finite goal-direct quadrant (which in hindsight is almost ever the case BTW), the need to spend energy on making the design scalable is limited to ensure reasonable scalability during the development phase itself, but no more.
|
