Django on IronPython

At PyCon 2008 in Chicago earlier this month, the latest release of Django (0.96) was shown running on IronPython.  There’s an interesting post about it here, and there’s some background info here from Dino Viehland.

It’s great to see IronPython supporting Django.   It demonstrates the power and ambition of IronPython, but, more to the point, the combination of Django and the .NET platform is exciting.

What do you mean?

After talking to a few people about my post on the term “technical debt” and reading the comments, I thought some more about how we could come up with a better term. My first thought was that the mismatch here is between intended meaning and received meaning, which reminded me of intentional fallacy.

Intentional fallacy is a term from literary criticism which states that it is a fallacy to consider the author’s intention when analysing a work of literature (the fallacy refers to the intent of the author.) What does that mean if you’re an author? It means that all meaning is contained within the work, what you meant to say has no bearing. The lesson for us is that we should consider ourselves in the same position, that what we mean is what those to whom we speak understand – which may not be what we intended. Of course, part of the issue here is that we may be speaking to differing communities and they may understand the same message in different ways.

My experience to date is that, in general, we can do much better explaining software development and architectural issues to non-technical communities. I’ve frequently seen blame attached to those who “don’t get it.” The lesson of intentional fallacy is that they got the message we delivered.

Family Tech Support Guy

From time to time, I play the role of Tech Support Guy to family members – I’m sure this is a role familiar to everyone who has owned up to having anything at all to do with computers. My services had been booked yesterday to sort out a problem with a personal firewall blocking access to a NAS device (I’d installed the NAS device last time around, but a change of security software in the interim had rather overzealously prevented any access to it.) It turned out to be relatively easy to sort out (adding a new network – a range of IP addresses – and marking it as safe did the trick) and I managed to fix another issue that had come pre-installed and was preventing access to to the Sidebar. My next step is always to ensure that the latest patches are installed and this I duly did (in this case applying SP1 to 2 Vista machines.) Finally, I set up Live Messenger and bookmarked SkyDrive. SkyDrive is a pretty handy service to have and judging from our conversations, I think that adding it was as valuable as unblocking access to the NAS – the NAS is great for backup and sharing files within a household, but SkyDrive gives you a way to share files with family and friends (and the public if you choose.) I think that it’s services like SkyDrive – which increase the usefulness of the computer and broadband connection – that make playing the role of Family Tech Support Guy worthwhile.

The Mashup Spectrum

Having owned a ZX Spectrum and being part of a generation that got into computers as a result (along with owners of the BBC Micro, the Commodore 64 and the like), my attention was drawn to this ZX Spectrum Laptop (via Endgadget.)  In an ideal world – a world unencumbered by constraints – the OS would have been the Spectrum OS.  I wonder what other retro inspired hardware mashups are out there or being built right now.

More on the Architectural Theory of Everything

Yesterday I was wondering about an Architectural Theory of Everything.  Thinking about it some more, I realised that there are (at least) 2 dimensions of the Architectural Continuum.  One scale of the Very Small to the Very Large is the number of systems for which you have architectural responsibility.  The second dimension is the focus – running from domain specific through to Enterprise.  To demonstrate these scales, here’s a chart:

 

The x-axis runs from the Very Small of specific domain focus through to the Very Large of Enterprise focus – remembering that some Enterprises are of global scale and cover multiple domains, these are on the far right of the x-axis.  The y-axis runs from the Very Small of the application specific to the Very Large of multiple application focus.  I’ve put a few roles on the chart to demonstrate where they might fit in.  I’ve assumed that an Enterprise Architect has enterprise focus and focuses on multiple systems, so is at the Very Large end of both scales.  The Application Architect focuses on a specific application in a specific domain, so is at the Very Small end of both scales.  The Solution Architect focusses on multiple applications, but only focusses on a given domain.  The Technical Design Authority focusses on an application or a related set of applications but takes an enterprise perspective.  Of course, these are made up roles to demonstrate the point; your organisation may have different roles and they may be at different points on this chart.

The Architectural Theory of Everything would be patterns and principles that are true across all of this chart.  We know that one size doesn’t fit all, but the shoe can be remade for different size.  Equally important is what doesn’t work across the scale – just as gravity being so weak challenged the physicists, there may be issues that are different across the chart – these are important because an architect can expect to move over their career, so if  you are applying patterns that are successful in the Very Small, you need to know if those same patterns don’t work for the Very Large.  Also, I think that recognising that architecture is a broad discipline is helpful and may increase our ability to respect the differing challenges we face and help us to express more accurate the context in which a pattern should be applied.

I just need to work out where the string goes and how long it should be…

An Architectural Theory of Everything

I was watching a documentary the other night about the work of Stephen Hawking. Much of the documentary was concerned with the Theory of Everything – an attempt to explain all physical phenomena. Apparently, gravity is far weaker than you’d expect (this was demonstrated by showing that a small magnet can pick up a pin despite the gravity of the entire planet pulling in the opposite direction.)

When the narrator explained how the Theory of Everything meant that the physicists of the Very Small could begin to have a dialogue with the physicists of the Very Large, I wondered if there is a similar problem in architecture. There are architects concerned with the Enterprise (let’s call this the Very Large) and those concerned with application and component design (let’s call this the Very Small.) So, are there patterns and principles that apply across the whole architectural continuum? I think that there are, but I’ve not seen too much thought and writing applied to issues across this entire continuum – of course I could be looking in the wrong places. Architectural String Theory anyone?

Test Driven Debate

I ran into this post the other day.  You’ve got to agree that’s an eye catching title for a blog post.  Reading a title like that you might expect an anti unit testing rant, whereas it actually makes the case for a pragmatic approach at the heart of which is testing.  And that’s important – the focus should be on delivering working software, not on making sure you’re doing a before b.I see a lot of value in unit testing and high unit test coverage – I think it encourages better design along with more confidence in the code base (although I’d like to see more capability a la Eiffel built into languages, which would allows us to junk a bunch of the grunt tests and would make the intention of the code clearer.)  I’m less sure about TDD. There’s no doubt it has its passionate followers, but the focus on the how may be at the expense of the why, and that’s a niggling doubt.

Twittering

When I first heard of Twitter, I thought it was ridiculous.  Why on earth would you want to post messages that are shorter than text messages onto the web?  But then in conversation with a colleague a month or so ago, I saw how it could be used to create and maintain a sense of community – and as a result I’ve started my Twitter experiment. As part of this experiment, I followed Mix through Twitter.   I don’t know how it’ll work out, but it’ll be an interesting ride.

If you’re after more thoughts about Twitter, this post is a great place to start.

Mind your metaphors

Metaphors are very powerful. They help us to explain concepts that might otherwise be inexplicable. Pick an unsuitable metaphor, however, and you’ll find that you have failed to communicate. I read this post from Nick Malik and it chimed with something I had been thinking about the term technical debt.

I’ve encountered the use of the term technical debt increasingly frequently over the last few months. And I think it might be a poor choice of metaphor. Here’s why. Those using the term are trying to say that if we do x now, we’ll have to do more work in the long run. But the people who are hearing this metaphor are used to incurring debt – at a personal level, many of us take out mortgages to but houses rather than wait until we have enough capital. The business world understands and uses debt to its advantage. So, this means that the person listening may hear a choice: expensive and slow versus fast and cheap (in the short term – the long term success can be used to service the technical debt incurred.) Which option do you think they’ll pick?

Mix ’08

Want to keep up with what’s going on at Mix ’08 but you’re not attending?

Here’s some help:

Read Tim Sneath’s blog
Follow Scott Hanselman on Twitter
Visit the official site