bliki tagged by: process theory

BuildingArchitect

When people use the term 'software architect' they are using a metaphor from building construction to help people understand the architect's role.Ironically in doing this they misunderstand the actual role of a building architect.

14 August 2003

more ...


CraftmanshipAndTheCrevasse

Dan North's recent blog post on software craftsmanship has unleashed a lot of blog discussions (which I summarize below, if you're interested). There's a lot in there, but one of his themes particularly resonated with me, hence this post.

19 January 2011

more ...


DirectingAttitude

One of two SoftwareDevelopmentAttitudes. The directing attitude says that since most developers aren't that good (it's rumored that almost 50% are below average) we need to direct the way they do things. This direction is to prevent them from causing harm to the system they are working on. Typically this attitude manifests itself in designs and tools that prevent developers from doing certain things, limiting what they can do to keep them away from complex areas.

more ...


FaultyTechniqueDichotomy

My main inspiration in life is trying to capture and improve the way in which we do software development. So I spend a lot of time talking to people about various techniques they've used, which ones work well and which ones suck.

As I do this, I often hear about faulty techniques: "FIT wasn't worth the effort", "never put any logic in stored procedures", "test driven design led to a chaotic mess". The problem with any report of a faulty technique is to figure out if the technique itself is faulty, or whether the application of the technique was faulty.

5 August 2004

more ...


FrequencyReducesDifficulty

One of my favorite soundbites is: if it hurts, do it more often. It has the happy property of seeming nonsensical on the surface, but yielding some valuable meaning when you dig deeper

28 July 2011

more ...


PeopleOriented

One of the most difficult things for many people to understand about agile methods is the people orientation of agile. Those who are interested in agile processes all agree that process is a second-order effect on project success. The first value of the agile manifesto is that Individuals and Interactions are more valuable than Process and Tools.

12 January 2004

more ...


SchoolsOfSoftwareDevelopment

For nth, and I'm sure not last time, I'm sliding into a conversation about defining practices, labeling some of them as "best", and probably the C-word (certification). It's a familiar discussion, and although we've barely started it, I can predict much of where it will go. It's driven by a perfectly reasonable desire to identify who are the better software developers, and how existing developers can improve their abilities.

12 April 2008

more ...


ShuHaRi

Shu-Ha-Ri is a way of thinking about how you learn a technique. The name comes from Aikido, and Alistair Cockburn introduced it as a way of thinking about learning techniques and methodologies for software development.

more ...


SpreadingIncrementalism

From time to time people question whether a particular specialty can be used incremental way: "You can't do (security | user interface design | databases | internationalization | * ) with an agile project because this aspect has to be done up front."

5 January 2005

more ...


UtilityVsStrategicDichotomy

One of the steady themes I've seen throughout my career is that of the nature and importance of software development. Recently a prospect told one of our salespeople that "software is like sewage pipes, I want it to work reliably and I don't want to know about the details". This is the kind of approach that Nicholas Carr talked about in IT Doesn't Matter. On a contrasting note we've done work for many businesses where IT has been a clearer strategic enabler to their business, allowing them to enter new markets or significantly increase their market share. So is IT a utility, like sewage pipes, or a strategic asset?

29 July 2010

more ...

CodeOwnership

There are various schemes of Code Ownership that I've come across. I put them into three broad categories:

12 May 2006

more ...


DesignStaminaHypothesis

Is it worth the effort to design software well?

20 June 2007

more ...


EnablingAttitude

One of two SoftwareDevelopmentAttitudes.The enabling attitude takes the view that developers are responsible professionals and so should be given the freedom to do whatever they need to do. Designs that follow this attitude should make things easy to use well but should assume that developers know what they are doing and thus not try hard to prevent something being used badly. As such these tools can be misused, but take the attitude that users should know better, and if they don't they deserve all they get.

more ...


FeatureDevotion

A common, perhaps dominant, practice of agile methods is to develop a list of features (often called stories) for the software that's being built. These features are tracked with index cards, work queues, burndown charts, backlogs, or whatever your tool of choice is.

2 November 2006

more ...


MetaphoricQuestioning

As regular readers of my work may know, I'm very suspicious of using metaphors of other professions to reason about software development. In particular, I believe the engineering metaphor has done our profession damage - in that it has encouraged the notion of separating design from construction.

As I was hanging around our London office, this issue came up in the context of Lean Manufacturing, a metaphor that's used quite often in agile circles - particularly by the Poppendiecks. If I don't like metaphoric reasoning from civil engineering, do I like it more from lean manufacturing?

16 December 2004

more ...


PreferFunctionalStaffOrganization

For as long as I've been in software there's been a debate between FunctionalStaffOrganization and TechnicalStaffOrganization. The debate occurs within project teams, and across whole IT organizations. It's a constant debate because both sides have good logical arguments to support them, and there's no real way to test which has an advantage in practice.

2 August 2004

more ...


Semat

SEMAT (Software Engineering Method and Theory) is an effort initiated by Ivar Jacobson, Bertrand Meyer, and Richard Soley. Its stated aim is to "refound software engineering based on a solid theory, proven principles and best practices". Like many notorious people in the software world I was invited to participate. Thus far I've declined and feel the need to explain why.

16 April 2010

more ...


SoftwareDevelopmentAttitude

Many debates in software development are underpinned by whether the speaker has a DirectingAttitude or an EnablingAttitude. These different attitudes affect choices over languages, designs, tools, processes, and lots more.

8 March 2004

more ...


Swebok

This is the month for review of the IEEE's Software Engineering Book of Knowledge. This is an attempt to define the body of knowledge of our profession, in a way that can lay the groundwork for a licensed profession.

24 June 2003

more ...


WhatIsFailure

CHAOS report says only 34% of projects succeed.

The Standish Group's CHAOS report has been talking of billions of wasted dollars on IT projects for many years. The 34% success rate is actually a improvement over 2001's figure of 28%. But what do we really mean by 'failure'?

15 May 2003

more ...