This is actually a follow up article to my last post on Methodology. If you have seen my other posts then you will realise that this site is not so much a blog as a holding pen for articles so that a) I can find them again when the same topic comes up, and b) they might be of value to someone else.

I’ve been reading a good book with the title ‘Dreaming in Code’ about the adventures of Mitch Kapor’s (of Lotus 1-2-3 fame) Open Source Applications Foundation (and before you think geek reflect on why it is that if a lawyer reads books related to her profession then it is assumed as professional but reading about IT and exploring new technologies is regarded as geekish). The book digresses into many recurring issues in the IT industry such as software time (the opposite of Internet time), requirements, and whether software development is an art or a science. This ambiguous state may be regarded as a sign of immaturity. Do you think software development is regarded as a profession by other professions? The reasoning follows that if only we knew more, then the art (uncertainty) can be removed leaving measurable and repeatable processes. If engaging a lawyer are your first thoughts about their process or their ability and track record to win a case (an art)?

I think we should accept that software development is both an art and a science as quantum theory forced the scientific community to reconcile themselves with the wave-particle duality of matter, which really grated against the scientific mind. This raises other characteristics that software development shares with quantum theory such as uncertainty.

I thought of all this when thinking about why so many methodologies have not stemmed the rate of software project disappointment. A focus on form and process alone cannot guarantee success. Software management must grapple with the content. I think I mentioned in my last post that software development is the process (or art) of evolving a model of the system from abstract forms to implementation. A useful methodology provides guidance for enacting this transformation.

It is less important to me whether specifications are called Use Cases, User Stories, Features, etc. than that the right information is defined at the right level of granularity. If done right, a Use Case defines a method on a Domain Object. The Domain Model captures both the behaviour (methods) and structure (object relationships) of the system. Domain object methods are aggregated into Service interfaces for use by the presentation layer. The transition from analysis to design can be traced.

For example, by asking what goal a user is trying to achieve in using the system, a Use Case can be defined at the right level of granularity (a complete business transaction relevant at a human level) and that focuses on the requirement not the implementation (in case there are simpler and more elegant ways to satisfy the requirement). 

While work breakdown structures and role descriptions are useful (some idea of schedule and cost is better than no idea), guidance about the type of questions to ask is helpful to the hapless soul assigned with completing the task. The precise use of words and grammer is also important to facilitate the correct transmission of meaning. Donald Knuth coined the phrase literate programming in a 1984 paper.

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

This topic deserves further follow up for another day.