December 24, 2004

Intellectual Property?

After failing to get a copy-protected CD I bought to play in my car stereo, I feel obliged to have a rant at the music industry, so here goes...

I work in the IT industry, the only output of my work is information, so I don't need anyone to tell me that intellectual 'property' needs to be protected, but I still think that the record industry’s attitude stinks.

The problem is in the language 'intellectual property', 'to own copyright'. The whole concept of ownership is a man-made one which we use to make the world a bit easier to manage. It's a really useful concept for allocating and managing physical resources; if you own a car then it’s yours and it’s wrong for anyone else to do anything to it. But when we talk about intangible things like information, I think we're being misled by talking in terms of ownership.

A thought experiment: Every CD is basically just a very long binary number, there's only a finite number of music CDs that could possible be made. Say you took a computer with a really big hard disk, and created every CD it was possible to make. Does this mean that the next time someone releases a successful CD you could sue them for copyright infringement? It raises the question 'Is information created or discovered?'

The reality is there is no such thing as pure creation. If I write some really good song lyrics, most of the words are probably things I've heard other people say, just changed a bit. Every creative act is inspired by things we see and hear all around us, so to copy those patterns and then try and fence-off that part of our collective culture as being the sole property of one person is an act of theft in itself. Besides, that was never the objective of copyright laws, which are supposed to encourage information sharing by allowing the creator/discover to make a reasonable profit from their work.

I think probably the unfortunate reality for the popular music industry (in it's current form at least) is that it's day has passed. With a modern desktop PC and an internet connection I have everything I need to publish my own music (everything that is, except for any trace of musical talent). The entire physical infrastructure built up by record companies is rapidly depreciating in value and usefulness, and it's much easier to blame piracy than face the fact that your industry is being commoditized, and replaced by a far simpler cheaper alternative.

Compounding this, you have the problem that music is not the dominant media in the same way it was 40 years ago. Every art form reaches a point where there is very little left to be said, and for the last 20 years modern popular music's primary point of reference has been older popular music. Oasis could recreate The Beatles in the mid-90's, but will a future band be able to find anything new to say in 20 years time? Maybe its just my age (just hit 30), but I can't help feeling true creativity in the popular music industry is getting rarer and rarer, and if there is a modern equivalent of the Beatles, then they're working in a different medium (probably making films or writing computer games). The record companies find themselves in what is still a very profitable business, but I think that they're probably fighting a battle which they're destined to lose.

PS. How did I eventually get to listen to the CD in my car? I had to copy the music to my PC (I've never seen any copy protection prevents me ripping tracks to my PC) then burn it on new CD, which worked fine. If the music industry's objective is to discourage CD copying, then that's quite an own-goal.

Posted by timv at 12:09 PM | Comments (1)

December 14, 2004

Concrete and Abstract

We abstract without realising it. For example, "a customer goes into a store". This is an abstract statement. A concrete statement would be that John Smith goes into the Dixon's store on Oxford Street.

Posted by timv at 4:22 PM

Reflections on JBehave

Chris (Chris Matts) and I have been discussing JBehave with Jen Stille, one of the other ThoughtWorks BAs.

Chris explained that for him JBehave supports his view of Business Analysis that is based on Kolb's model of learning. We start with concrete examples from which we create a model. We then add new concrete examples and test our model against them. We reflect on whether the model satisfies the concrete examples or whether we need to upgrade the model. Traditionally, this model is kept and the concrete examples are lost. JBehave captures these concrete examples in the acceptance criteria. The model is of value as it forms the ubiquitous domain language that underpins the JBehave stories.

I think the key objective of JBehave is to help people get TDD (most people don't). I think writing tests in terms of expected bahaviours, while only a very small change from TDD, achieves the same ends in a easier to understand fashion. However, if its going to take-off within the analysis community, the challenge is going to be managing the number of states (or 'givens' in JBehave speak). In a simple system it can definitely work, but so will just about any other analysis technique. In a complex system with a huge statespace, it's success will depend on how effectivley we can manage the list of starting states.

Chris says that one of the powerful aspects of JBehave is that it deals with abstract (model) and concrete. For example,

GIVEN account is overdrawn ( balance = -50 ).

This is unlike traditional modelling which only works on the abstract and "traditional" test based approaches like FIT which on work on the concrete.

Posted by timv at 4:16 PM

December 10, 2004

The Challenge of Emergent Design

You have a team of developers who typically write code at the rate of 1000 lines/week (okay, I know lines of code is a terrible way to measure productivity, but humour me). They're big on XP and evolutionary design, so they reject any up-front design, but spend 50% of their time redesigning existing code.

At the end of week 1 their application is 1000 lines (no existing code to be refactored).

At the end of week 2 their application has 500 extra lines (1500 total), plus 500 lines of existing code (1000 lines) has been refactored (50%)

At the end of week 3 their application has 500 extra lines (2000 total), plus 500 lines of existing code (1500 lines) has been refactored (33%)

...etc...

At the end of week 25 their application has 500 extra lines (13000 total), plus 500 lines of existing code (12500 lines) has been refactored (3%)

This is the big challenge with emergent design. As time passes you rapidly lose your ability to make major changes to it.

This doesn't mean emergent design is a bad idea, just that it needs to be balanced with up-front design. I've met people in the agile community who have an almost religious hatred of anything with 'up-front' in the title. To believe that 100% of a design can emerge is just as naive as to believe that 100% of a design really can be specified in advance.

Posted by timv at 3:04 PM

Unordered Systems

At XP Day I was fortunate enough to hear Dave Snowden speak. One of his topics was the difference between ordered and unordered systems; I think the distinction is very important for software developer.

Developed software is an ordered system. It works in a completely predictive, deterministic way. It's like a factory, raw materials go in one end, flow through a predefined, repeatable process, then the end product arrives at the output. The software development team, however, is an unordered system. You cannot predict how it will behave in advance, and you cannot have a successful unordered system by treating it as if it were an ordered system (this is what I think Agile is really about).

In an ordered system the mechanism is known (or at least knowable) and explicit, so if there’s a problem you can objectively identify the problem, such as ‘a network failure means system 1 cannot communicate with system 2’. However in an unordered system, when you talk about problems, you risk ending up arguing about different perspectives. For example: 'Why did the Titanic sink?

Answer 1: They weren't looking hard enough for icebergs

Answer 2: The hull wasn't strong enough to withstand impact

Answer 3: Civilisation c1900 weren't using enough CFC deodorants, thus the ozone layer was intact, world temperatures were too low, and the icebergs hadn't melted.

Answer 3 might be silly, but objectively they're all valid peices of analysis.

Posted by timv at 3:01 PM