Visit ManageWithoutThem.com Most recent blog entries Visit ManageWithoutThem.com

Monday, November 15, 2004

 

Truest thing I've read on TechRepublic for a while...

Interesting comments on IT project planning appear here.

And my reply (Here and below):

I agree that software engineering, all the way down to coding, is largely a design activity. In fact, even if we mature enough to be able to construct systems from components that 'construction' will still be largely a design activity.

The interesting thing about design processes are that they aren't actually all about requirements. People tend to miss this. I agree with the idea that software projects should be driven by business needs.

However, I don't agree that IT project management should actually be driven by requirements. The reason IT projects should be defined by business objectives is so that scope changes don't have to be made for every functional requirements change. i.e. you define a project using business objectives so that the project can take responsibility for the proper gathering, management, structuring, and formalisation of requirements.

I'll say that again. You want to take MORE responsibility for functional requirements of the system. It's insane to think that you are reducing risk by demanding a 'detailed' set of requirements before you start an IT project. All you are doing is reducing your control over how business objectives are met by technology. Success will depend on control.

An approach which relies on 'detailed' business requirements also makes it difficult to implement higher order enterprise IT architectures which use leveraged infrastructure and component-based application architectures. Much of the work involved in implementing software solutions is in how components relate to one another across all levels of the solution; it's not all about meeting one business context (this is 'necessary but not sufficient').

Lastly - back to the design focus of software engineering processes. More mature engineering disciplines such as that used for build environment construction have realised that architecting solutions does not just mean meeting requirements.

Christopher Alexander's Oregon Experiment basically concluded that a solution which is isomorphic with requirements is inadequate.

Again, DC_Guy, well put!

Thursday, November 11, 2004

 

You're really better off going to:

http://www.managewithoutthem.com/blog/

 

Anybody think in graphs?

Welkin: A General-Purpose RDF Browser... is yet another meaningless graph-based viewer.

Nobody I know thinks in graphs. My wife reminded me last night that I only really know about 4 people (and to be fair a couple of them might actually think in graphs) but I'm pretty sure *I* don't think in graphs.

What I really want to see is a browser with some sort of 'plug-in's for relationship type visualisations. The basic relationships I would expect to come out of the box are 'Contains', 'Is followed by', 'Below', 'Peer'.

The next feature required is to be able to lock down some visualisations and relationships. For example I might define a framework containing a number of locked down visualisations (say some boxes to put stuff in) and some locked down relationships (give everything with a 'Type' attribute of 'Platform' a 'Contains' relationship joint to the locked down Platform visualisation I have placed on the framework).

The brower could then produce something a little more meaningful. Contradictions within rules could be shown with movement (alternate between the two contradicting relationships and redraw).

In the above example I could throw data at the framework and it could sort it. Then I could overlay the graph-based representation as used by this Welkin thingie. Because items would already be constrained I'd be able to actually get some meaningful information from the damn visualisation!!!