This question is usually phrased as which I prefer, or which I believe “guarantees” the “best” results for a development project.

This sort of question assumes that there is a straightforward answer. There isn’t one, of course.

Firstly, I have to clarify what is meant by “Agile” within the context of the organisation. There is a broad range of possibilities between two extremes. On one hand, some consider Agile to be simply not writing requirements or documentation and instead relying on a form of “user stories” that are essentially notes made on the back of an envelope. These are then handed to developers to grind it out as quickly as possible using short deadlines as “sprints” in order to coax as much work out of them as possible as quickly as possible. On the other end of the scale a truly agile company has in place endemic practices of collaboration and appropriate value-chain prioritisation of features incorporated into the psyche of business management and developers alike. It’s a way of life, not just a way of doing a project.

I don’t believe that, realistically, true legacy Waterfall has been practiced for years, at least not outside outsourced contracts. All of the successful development teams I’ve seen have used an “Agile” mindset even when developing in a Waterfall SDLC. Software is developed in phases with clear deliverables per phase, bugs are dealt with as they occur to save rework when having to fix them, deliverables are validated against requirements before phases commence and good business communication is put in place so that the teams are aware if priorities change mid-phase. Of course, phases here may be 3 months rather than 1-4 weeks or whatever, but within those phases, shorter term targets are set and measured against by the teams.

I’ve always practiced an iterative approach to development of systems and software but I don’t believe that Agile methods, in their entirety, need to be adopted for success. My main concerns around extreme Agile are lack of documentation for ongoing support and rework necessary late in the project as design decisions are deferred and technical debt accrued in order to crank out features as quickly as possible in the early sprints.

What about Test Driven Development?

I always practiced TDD in some way, shape or form, even before it was made popular by Kent Beck’s work. I’ve always created test harnesses to exercise the code and retained these as part of the codebase. Of course, now with xUnit frameworks this is made even easier in the most part and allows it to be done in a standard way.

This has influenced how I structure my code too, so my programs are generally written in the form of small functions that are easily tested and understood. These are then assembled into higher-level processes. My low-level functions tend to implement practice, they do one thing, whereas the higher-level functions implement policy, they tell the practice functions when to do their thing.

I don’t necessarily do test-first development, at least not religiously. Why not? I find it breaks my train of thought context-switching between test code and solution code. It depends on the language; in Smalltalk, for example, where there is no compilation delay and objects are live in the workspace, it’s very easy to flip between the two and essentially create the solution code in the debugger on the fly. Something like Java or C++ though, especially if you’re reliant on a lot of library code that has to be linked in, can have a significant overhead in the create-test, fail-test, create-solution, pass-test cycle and, at least for me, it’s not efficient to do this on a micro-scale.

What about Pair Programming?

This seems to be a matter that still concerns quite a few companies.  I believe in the concept (I tend to just call it “helping each other” though) but not the strict practice that some in the Agile world espouse. It makes sense to do for several reasons, but there are reasons too while you might not do it for particular tasks within the project.

Here’s when I don’t think it’s appropriate to do pair programming; when it’s just “grunt work” e.g. setting up configuration files or coding around some well-understood and well-documented feature. Having two sets of eyes on the job might help spot the occasional typo but, in the main, no-one is going to learn much or really benefit from 1:1 help. It’s possible to catch anything that slips through with a code review process which is a better use of time is these cases when the work is fundamentally just “smart data entry”.

In the main though, Pair Programming does help in making the team more cohesive and reduces the code ownership issues that can arise on a project. If people have worked on all the modules in the project then there can be none of that "I can’t fix that, it belongs to X” or “Look what X did to my code? I’ll have to reformat all of it now!” type of conversations. It also helps reduce the “single-man” dependency that can happen – especially in the face of reduced or non-existent documentation. Two people are also more likely to raise a flag and ask questions if they don’t understand a topic or requirement. It’s like having multiple flight computers on an aircraft and having them agree on a decision before taking action. Having a senior person work with a more junior person can also help mitigate some of the “dynamic design” issues that can arise – sometimes they just know when to say, “You know what. You ARE going to need it.” Long-term productivity improves – though it looks as if you’re doubling effort per task you decrease the effort needed in the latter stages of the project and maintainability is generally better.

I’ll generally have the more senior developers take the shotgun seat more often than not. Junior developers can benefit from watching a senior developer work but aren’t likely to jump in to ask questions or point things out, whereas as they are likely to defend and explain their decisions if the senior guy starts making a lot of comments on how they’re structuring things. It’s also helpful to have a domain expert ride shotgun, if the business can spare them (one of the common difficulties in Agile that I see), as the developer has to discuss what they’re doing in business terms and this helps build a common language. This can also simplify some of the program concepts too, as the developer learns more about the problem domain, resulting in a cleaner overall design.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: