Archive for May, 2006

Parallels between Social Engineering and Development

Friday, May 26th, 2006

As a software developer I don’t make claims to change society, however in both software development and social engineering the actor is peturbing a complex system made up of empirical processes and that means that lessons in one area may apply to the other.

In The Open Society and its Enemies Karl Popper wrote that “the piecemeal engineer will adopt the method of searching for, and fighting against, the greatest and most urgent evil of society, rather than searching for, and fighting for, its greatest ultimate good.”

In many (most?) areas of software development the developers are implementing a continous stream of new requirements and fixes to existing or emerging problems. The process is never “finished”.

So it came as a pleasant surprise when I found the following table in Conservative Political Philosophy and the Strategy of Economic Transition, by Peter Murrel and I couldn’t resist the parallels between this and a comparison between “traditional” and “agile” software project management methods.

Characteristics of Utopian and Piecemeal Approaches to Policy

Utopian Piecemeal
End point driven. Choice of initial policy determined by the goal for the final outcome of the process. Focus on Immediate Problem. Identifies worst problems, trying to solve them largely ignoring the effects of today’s decisions on some long run equilibrium.
Clean the Slate. Emphasizes the inter-relatedness of society’s problems and therefore the need to make a decisive break with the past, with the necessity of institutional destruction in the first stages. Use Existing Institutions. Recognizes that new structures can be created only slowly and accepts that existing institutions are usually better than either none or hastily constructed alternatives.
Large Leaps. To make a decisive break from the constraints of the past, advocates bold policy steps that involve packages of many new institutions. Small Steps. Emphasizes the risks from going too fast and the impossibility of successfully creating a network of inter-related institutions anew.
Faith in the New. Willingness to trust in theoretical reasoning as the primary input for the design of society’s new arrangements. Skepticism. Search for existing models and methods to help in the formulation of institutional changes.
Irreversibility. In the weak form, willingness to accept large irreversible changes. In the strong form, emphasizes the need for them. Reversibility. Advocates policies that facilitate feedback on their effects and that can be stopped or even reversed.
Design and Theory. The most important intellectual resource for policy-makers is the knowledge held by theoreticians and technocrats. Judgment and Practice. The most important intellectual resource is the practical experience accumulated in the context of a particular set of institutional arrangements.

Note on empirical processes: Process control theory states that a defined process is predictable; it performs the same every time while an empirical process does not. Empirical Processes are chaotic (in the sense of being extremely sensitive to initial conditions) and effectively unrepeatable, requiring constant monitoring and frequent intervention to ensure the desired result.

How many people are doing SOA ?

Tuesday, May 9th, 2006

I recently attended a presentation in the City of London on a high powered infrastructure component and architecture.  The attendes were the usual bunch of attendees, IT guys at the geekier end of middling to senior management, early adopters of various technologies.

During one of the sessions the presenter was explaining how this technology could enable Service oriented architectures:

“I guess most of you are implmenting SOA now.  In fact, how many of you are implementing SOA right now?”

Of the forty attendees one hand was tentatively raised.

Agility and Feedback

Friday, May 5th, 2006

For me the crucial difference differentiator of an Agile approach is the obsessive desire for feedback. Basically, if your reaction to an issue is to work out how you can get more, objective feedback faster then you are going towards the agile end of the spectrum; if it isn’t you are not.I will go out on a limb and suggest that the vast majority of system development failures are due to the lack of feedback at various phases of the development process.

This isn’t a new thought, it is as old as Kent Beck’s driving story from the earliest days of XP. It does get lost in all the talk of principles’ and ‘practices’ and ‘levels’ though.