Many self-respecting software architects have read Christopher Alexander‘s book, ‘A Pattern Language‘ and included it as part of their own ‘must read’ book list. No, I haven’t read it in its entirety, but I’d recommend reading Richard Gabriel’s book, ‘Patterns of Software’ [PDF, 1.2Mb] instead. It contains a very thoughtful analysis of Alexander’s work in the context of software architecture. But the selection and analysis of patterns is just one of many ways to find the desired ‘form’ of software – i.e., the software structure and its expected behaviour. John Gero proposed a generic design process called the ‘Function Structure Behaviour’ (FBS) framework with the following activities:
- Formulation: The translation of design problem into a ‘function’ with ‘expected behaviours’ – a set of desired functions required to solve the ‘problem’.
- Synthesis: The transformation of ‘function’ into a ‘structure’ – or an architecture, as we (software architects) would call it.
- Analysis: The evaluation of the structure to determine its behaviour contrasted with the expected behaviour (e.g., testing).
- Documentation: The various descriptions of function, structure and behaviour elements.
- Reformulation: Based on the analysis, the function, structure or expected behaviours may be changed.
This should look familiar. Most architectural (and technology) frameworks or methodologies have this ‘formulation, synthesise, analyse and refine’ pattern. For more information, I’d suggest reading an article by Philippe Kruchten: ‘Casting Software Design in the Function-Behavior-Structure Framework’ [PDF,
If we assume that function isn’t going to be altered too much (for a given design problem), then the above (iterative) process appears to converge towards a structure governed by function – or ‘form follows function‘ – a phrase coined by (building architect) in 1896 in his article ‘The tall office building artistically considered‘.
The implication is that it doesn’t really matter how you go about developing software – one will eventually end up with the same structure assuming one started with the same (set of) design problem (requirements). A clever guy named Diomidis Spinellis arrived roughly at the same conclusion after a rigorous study of the source code from the FreeBSD, GNU/Linux, Solaris, and Windows operating systems. His findings were published as part of the proceedings from 2008 International Software Engineering Conference – a highly regarded academic conference.
My guess is, that the ‘how‘ will probably determine the amount of effort and time required to arrive at that structure. But if you don’t know the ‘what’ part, i.e., your design problem, then ‘how’ will be very painful . . .