Welcome to the past of software development

I was at an interesting meeting at my local BCS branch tonight ‘Opening The Black Box: An Introduction to Quality Driven Development’  by Tim Hunter. I had heard of TDD and DDD etal. but QDD was new to me.

What we got was a hour framed by the basic premise that ‘Waterfall is good – Agile is bad’ (or progressive methods as the speaker called anything that was not waterfall). As another attendee pointed out in the Q&A, this tone in the presentation tended to cloud the more balanced points, managing to get the backs up of a good few attendees by the speaker’s seeming lack of understanding of god agile practices. He seemed to see agile as developers messing around, no documentation, testing or general engineering discipline. He argued that without waterfall, and specifically quality gates, we could not write quality systems. This is not the Agile I know.

Agile, if adopted properly is very constraining from an engineering point of view. We have detailed specification by example, open reporting practices, regular re-estimation of remaining work, test driven development, pair programming, automated builds, regular potentially shippable products with quality gates to move products between states of publication so we don’t just release everything we build. The list goes on and on; OK no team is going to use it all, but the tools are there in the tool box. A team can set where on the agility spectrum they choose to sit.

I agree with the sessions premise that quality gates are important, but not that waterfall is the only way to enforce them. You can put the whole methodology choice aside and frame the discussion in how do we get staff who take pride in their work and are empowered produce quality products via their working environment. I would argue there is more hope for this in an agile framework where the whole team buys into the ethos of software craftsmanship, as opposed to any methodology where an onerous procedure is imposed, a system must be habitable as Alistair Cockburn puts it.

I felt the session was too pessimistic over the quality of people in our industry. The speaker wanting to make rules because he perceived people were of low quality and had to be forced to do a half way decent job. OK I am a bit pessimistic, not too bad a trait for a developer or tester, but we have to hope for more, to strive for more. This is something I think the agile community does do, they are trying to write better software and become better craftsman everyday. They care.

For me the key question is how can we bring more people along with us. Especially the people who have given up and just turn up to do their IT related job and avoid as much hassle as possible. They are the ones who don’t turn up to the BSC, community conference or any user groups or even read a book or blog on the subject. What can we do for them?

5 Replies to “Welcome to the past of software development”

  1. This is one of the reasons why I feel that the BCS is a dying organisation. Too many members/speakers not open to looking at new methods and practices, trying to cling on to the past as they have no appreciation for progress and improvement :(.

  2. Having read Tim Hunter’s ramblings on the BCS site (http://www.bcs.org/server.php?show=ConBlog.21), the experience above doesn’t surprise me – he seems to have a truly warped and pessimistic view of software development. I attended a BCS Scotland Testing event recently, and during Dorothy Graham’s talk on automated testing, both TDD and Agile System testing were discussed, so I don’t think it’s fair to tar the entire BCS with the same brush, however I think that they have to be careful that they don’t gain a reputation of closed to new process and principles.

  3. As with all organisation the BCS is a mixed bunch, but I do think that as an organisation they are not that up to date. I remember then I joined in the 80s that a LAN was unheard of at meetings, even though most companies were implementing them at pace. I wonder if this is the case with the BCS in London, where the special interest grounds tend to live? Are the branches just a bit behind the curve?

  4. I am disappointed with your comments on my presentation. It’s nonsensical to say that BCS should always feature speakers who always say that everything new is good. If we are unable to criticize new things, then we truly have ‘tyranny by technology’. As I explained in the presentation, some supposedly ‘good’ new things turned out to be ‘turkey’s and we ditched them pronto. Look at ‘End User Computing’. Look at RAD. It’s also nonsensical to expect that the rules for measuring success will constantly alter, they may not do. IT may end up becoming quite stable in that respect. What it all shows is that the insular world of programming (and certainly the techie viewpoint) is the predominant view within the BCS. Such people have no concept of things like UAT which I am heavily involved in. Maybe if we feature more speeches like mine we might get more people from the user community to join. ‘the aims of the Society are to promote the study and practice of computing and to enhance knowledge and education of IT for the benefit of the PUBLIC.’ That includes looking at both sides of the argument, not indoctrinating people with one viewpoint.

  5. I agree with you point that we cannot allow the industry to always be jumping onto a new brand wagon every week, but we cannot be static either. This dilemma is key reason why we cannot easily ‘professionalise’ our industry. This has been a point I have written returned to for a while (http://blogs.blackmarble.co.uk/blogs/bm-bloggers/pages/232.aspx). In my opinion the biggest barrier to our industry moving forward is the lack of a common set of rules we can all agree on as being ‘correct’ (hence this comment thread I suppose). This is far less the case of other engineering professions, there is a lot less argument of how a civil engineer builds a bridge, the rules and practice are well agreed in their mature profession. Ours is young, this has been bought home to me this weekend whist visiting the National Computing Museum (http://www.tnmoc.org/), I am only in my 40s but I have used a good proportion of the equipment they have on show commercially. What I am saying is we are still learning, we try new things. This does not mean we throw out everything from the past, but equally we don’t keep it just because it ‘that the way we always did it’. We should keep what works and discard what has been shown to fail. What I do disagree with is the comment on the ‘insular world of programming’. This at least should be rephrased as ‘insular world of programming, who have no interest in their craft’ If you look at the agenda of the developer community event (conferences, user-group meeting etc.) you will see many sessions on QA and tested related subjects in their various forms. I would go as far as to say that they may actually predominate at the more ‘agile focused’ groups. For example I would draw you attention to the Agile Yorkshire (http://www.agileyorkshire.org) group’s meetings this year: Feburary – Test Driven Development: A practical overview from practitioners March – Test Doubles: An Introduction To Unit Test Patterns May – Exploratory Testing June – Acceptance Testing (or try http://skillsmatter.com/go/agile-testing for another example of similar events across the UK) OK the first two meetings were focused on programming activities (but that is needed too), but the May event was exactly what you were proposing in the QDD session, an independent expert tester, beholden to nobody, as a gate keeper to product release. The June event was focused on explaining why testing was important at the business level and how this subject was best raised and managed with non IT literate business decision makers. I would argue these are key to your QDD argument and suggest these events are a good sign of the maturity of these ‘insular programmers’ trying to educate themselves on how best to interact with people beyond their immediate IT focused co-workers. I don’t mean to appear to be trying to hold an ‘us and them’ argument. I suppose my summary is that there are not two sides to this argument, there is a spectrum with a waterfall process at one end and an agile process at the other. Neither is right for all projects, each has their pros and cons. The key skill for an IT professional is to decided which tools/processes to apply to which projects without being blinded by dogma from either side (or either end of the spectrum if you like). Something I think we are starting see more in the development community; I have seen a number of posts recently on stepping back from blind application of a various Agile processes without a critical review of what is required to make the project a success, any development process (in its widest sense of interaction with a business) should be ‘safe’ i.e. can be relied upon to get the customer what they want in a timely and cost effective manner. You mention the comments on the BCS. What I worry about is the problem that few of the people who attend the development user group sessions show up at the BCS meetings (and on the larger point how many IT people attend neither!). Why don’t they come? Well I think the comments in this post give a good hint, it is the perception of stuffiness of the society (a stuffiness I certainly don’t thinks exists at our local branch). We need to do is get rid of this perception, so I wholly agree that there is a need for more session like yours, they promote debate, and that is vital to the success of the society as it engages interest

Comments are closed.