What's up? Doc! (redux)

The logbook entry from Ricardo Macarron  captures the need for  better documentation and a common language between software developers and their users.  He also lists some consequences of a lack of understanding of the software by the users and the tasks by the software developers.   There is a growing movement in the software development/user community to reach to a common language, a common understanding, usable software and readable and succinct documentation.  Part of that movement is captured well by Eric Evans' book, Domain Driven Design: Tackling complexity in the heart of software, 2004, Addison Wesley, ISBN:0-31-12521-5.

Domain Driven Design also has its own website and you can find it here.   Some of the discussion is certainly controversial, especially Evans' view on architecture, but it addresses important concepts that should help alleviate or at least moderate the problems dealing with software Ricardo describes in the log.  Later!

Ricardo's log:

Back to Software engineering. As an end user and chair of a couple of scientific fora within <my company  and both>resulting in requests for software tools, learning about software engineering is providing an opportunity to reflect on past experience. While designing a new software tool, users know that work processes are evolving and thus demand flexibility. Users always get reassurance from software developers that the new tool will allow for easy adaptation to new processes, but we have rarely to never got this at the end. Why this is so difficult? One problem is lack of common language among both communities (users and software engineers): “customers don’t know what they want” is a catch phrase (or hedging exercise?) used time an again by IT experts. Let’s crack this nut: could it be that the developers and the customers don’t interact enough in the planning phase as to get to understand each others desires and constraints? Prototyping before final specs looks like a win-win solution.
Requirements change because people don’t think as the program (logical steps) and the program doesn’t react to unusual situations as people (flexibility once again, fuzziness, exception handling…). For instance, I often encounter employees in retail struggling to use a program to answer a question or even to input an order without some lamentation or the worst “cannot do it, the program doesn’t allow it”. These “unusual’ situations, or in general unforeseeable combination of factors interplaying while using a software program, are hard to predict in length when programs are being designed. A better science on building up scenarios seems to be needed. It is like if designers/users were poor chess players only predicting one move at a time instead of chess masters seeing hundreds or thousands of options many moves ahead.