Given the constraints of constraints: am I deluded?

Given the manifold mix of methodologies that exist within software application development today, it is perhaps no surprise that one camp (let’s say Agile) often thinks of another (ok let’s say Waterfall) as a little misguided at times.

Would ‘deluded’ even be too strong a word to describe how one ideology regards its opponents?

As we know, this mindset goes onward and upward throughout the programming world. You say “version control”, I say “software change and configuration management”. You say “Subversion”, I say “IBM Jazz”. You say “Perforce”, I say “tomato.” You get the idea.

So then to constraint-based programming, where relationships between variables are stated in the form of constraints – this means that prescribed steps for programme execution are not laid out as they might be elsewhere, but that a defined set of properties for the end product can be seen at the outset.

Based around the declarative ‘how’ but not ‘what’ nature of programming in the same way that HTML declares a structure but not necessarily the content, constraint-based programming has not made quite the same number of headlines as say SOA over the last few years.

NB: As anyone with more than a passing of software engineering will know, this is not necessarily a bad thing – some of the less vocal corners of the coding community don’t always do quite as much flag waving as others. At Intel’s EMEA software development conference in Portugal last year I was interested to learn that the huge swathe of cyberspace that is Second Life runs on 2,000 Intel servers (scaleable for up to 10,000) with Debian Linux at its heart.

So why isn’t there a button on the Google Code home page (or choose any of many other examples) for “Constraint-based developer info for developers” then? Could it be because this type of application knowledge usually comes shrink-wrapped in the form of software libraries these days?

The problem (perhaps) is the way we are describing the internal elements of software engineering these days. Let me explain. Quite often I’ll be talking about a techie subject to a developer pal on the phone, OK hands up – on IM. We’ll start talking about a technology and then I’ll say, “so what exactly is it?”

It a language, is it a platform, is it a plug in, is it a component, is it a framework, is it a toolset, is it a model, is it a methodology or it it – god forbid – just a ‘technology’?

Herein lies the problem (I am postulating and asking for feedback, so please) maybe? Constraint-based development is none of the above – it is a paradigm.

So, constraints are embedded in an imperative language like Kaleidoscope. But Kaleidoscope is a constraint-based language (I would argue that it more of an ideology than a language – but let’s press on) that embeds its constraints into an ‘imperative’ framework (oops, sorry, language) – and imperative programming sits on the other side of the ideological fence to the declarative model we first started with for constraint-based development. There’s got to be a twist in there somewhere hasn’t there?

This ecosystem of inter-related tiers and layers is what makes software development so compelling, I hope you’ll agree. Essentially I suppose this is what makes it such a ‘live’ process as so many of these technologies (oops) are organic and still developing. I can’t help trying to put myself in the shoes of an 18-year old student just starting out on a degree course here – where would I turn and who would I believe? Hopefully I’d harbour a healthy dose of scepticism all round. Most senior developers seem to get by pretty well with that approach.