‘Questioning XP’ Category Archives

1
Dec

The Source Code is the Design?

by Tony in Questioning XP

Small teams need generalists who can take a project from start to finish in a very small time. Passing information from one person to another makes no real sense, because the time it takes to communicate all the necessary details just slows down the process. In the old days, the coding work would have been handed off, because programming used to be very slow. With a modern object-oriented programming language, and a good development environment, the coding can be fast enough that a handoff is no longer necessary. In the time it would take to write a detailed program specification, the designer can have the program written and tested.

XP teams tackle larger projects, so it makes sense to specialize and have some handoffs. The choice that XP makes is to keep as many as possible of the design-related activities concentrated in one role – the programmer. It then makes the customer responsible for capturing the requirements and handing them off to the programmers and the testers, who are responsible for automating the acceptance tests. In this way, XP tries to function as much as possible like a very small team.

— Pete McBreen, Questioning Extreme Programming, Chapter 11

30
Nov

Specialisation in Software Development

by Tony in Questioning XP

One very interesting aspect of XP is its lack of specialisation among the developers. Indeed, XP actively encourages a level of cross-training that is unheard of in most other approaches. This can be very useful because it lessens the risk that progress will be slowed as a result of having to wait for one key individual to perform a task.

XP is a good counterexample to the idea that role specialisation is useful in software development. Although there are strong arguments in favour of specialisation for mechanical tasks, the arguments for efficiency through specialisation are inconclusive for intellectual tasks. By making the programmers responsible for doing their own design, XP avoids the inefficiencies and miscommunications that can arise when design ideas are passed from a designer to an implementer.

— Pete McBreen, Questioning Extreme Programming, Chapter 10

29
Nov

Pair Programming

by Tony in Questioning XP

Pair programming is a very controversial part of XP, and some programmers are going to be unwilling to even try the practice. True, most who try it for long enough report liking it, but there are some who are vehemently opposed to pair programming. Although there is some evidence that pair programming is more effective that working alone, more studies need to be done with experienced practitioners.

Interestingly, many of the objections to Pair Programming come from the mistaken idea that software development is a mechanical task. Hence, the assumption is that two people working on one task are inefficient and slow. It is an open question as to when this type of mechanical metaphor will cease to dominate thinking about software development.

— Pete McBreen, Questioning Extreme Programming, Chapter 9

27
Nov

Test First Development

by Tony in Questioning XP

Of all the practices of XP, Test First Development is the most counterintuitive of them all. It is probably also the most powerful of them all for promoting the necessary paradigm shift for understanding and benefiting from XP. The idea behind Test First Development is very simple: before you change the behaviour of the production code you must have a failing test.

A failing test is immensely useful because it tells you when you are done. By shifting the traditional sequence of development around so that the test are the first things that are created, developers get feedback about whether their code is correct within seconds of writing the code.

This has a very dramatic effect on the feel of programming and goes a long way toward addressing concerns about the defect rate.

Test First Development feels exceedingly strange for programmers when they first encounter it. In the old days, programmers used to pride themselves on the fact that they could write an entire program and have it compile error free the first time. Now they are expected to get lots of errors deliberately every day. Although this feels really natural for XP developers, getting developers even to attempt this style can be difficult.

— Pete McBreen, Questioning Extreme Programming, Chapter 8

26
Nov

Truly Incremental Development

by Tony in Questioning XP

The really extreme part of XP is the way it insists on incremental development. XP attempts to minimize the elapsed time from when a user describes some functionality in detail to when that functionality is ready for the user to test and use. The speed at which the team can turn a conversation about a feature into tested, running code is the corner-stone of XP. All the practices are geared toward making this as fast and reliable as possible. XP is different because it does not use a phased approach to software development. Everything is done concurrently and incrementally. Requirements identification and capture, estimating, planning, designing, coding, and testing are all done incrementally.

This supports the planning strategy of working in short, timeboxed iterations by making it possible to deliver functionality quickly.

— Pete McBreen, Questioning Extreme Programming, Chapter 7

25
Nov

Success With The Planning Game

by Tony in Questioning XP

Success with the planning game relies on a shift in organizational behaviour so that the organization accepts the estimates given by the programmers. How likely is it that command and control-style organizations can successfully delegate responsibility for estimating down to the programmers? Many organizations seem to prefer the idea of stretch targets – the idea that if the manager reduces the time available, the team will work harder to meet this new target. Imposed estimates are such an endemic problem in software development that I suspect that few organizations will be able to use the planning game successfully.

— Pete McBreen, Questioning Extreme Programming, Chapter 6

23
Nov

Reinterpreting Experience

by Tony in Questioning XP

Reinterpreting your experiences is very important in times of change. As things change, we need to see if what we learned in the past is still applicable and relevant. An example of this is the difficulty of reading source code to understand what a program is supposed to do.

Historically, this has been really hard to do in assembler and low-level languages, so the lesson we learned was that programs need lots of external documentation and that printed diagrams are really useful for understanding the structure of a program. With modern, expressive object-oriented programming languages it might be time to re-evaluate how much external documentation is needed to make the code understandable.

A more appropriate example is possibly the assertion by the Extreme Programming community that the cost-of-change curve is no longer exponential. Although it is probably not flat, it is still useful to question the “get it right the first time” lesson we learned from the exponential curve. It may also be useful to ask what it would take to flatten the curve even further. Maybe the whole concept of “get it right the first time” is obsolete, and what we now need is a “fast failure.”

By getting something out quickly, the users will be able to guide the development team to an appropriate solution.

— Pete McBreen, Questioning Extreme Programming, Chapter 5

22
Nov

What do Software Engineering Projects Consider Important?

by Tony in Questioning XP

Initially it was thought that the reason why projects were experiencing trouble was that the programming part wasn’t being done properly. This gave rise to the era of structured programming, which soon led to the realization that the implementation activities were not the real cause of project failures. Attention then shifted upstream, and a variety of approaches were created that sought to rectify problems in the design activities.

Jackson Structured Design is just one example of this kind of approach that demonstrated that the design activities were not the main cause of the problem either. Shortly afterward, we got some structured analysis or structured analysis and design approaches that demonstrated it wasn’t really an analysis problem either. Shortly after that, depending on how you read history, attention shifted to either the project management aspects of projects or to an integrated, whole life cycle approach to software development.

One remarkable thing about this interpretation of history is that, in all of it, testing never really showed up as an area on which to focus much attention. This is interesting from the viewpoint of the agile methodologies, which place a lot of emphasis on testing. And it is especially interesting from the viewpoint of Extreme Programming, which places a massive emphasis on testing and testability.

— Pete McBreen, Questioning Extreme Programming, Chapter 4

21
Nov

Ignorance and Haste

by Tony in Questioning XP

The disease affecting projects is two headed: ignorance and haste.

Ignorance is difficult to treat because it is hard to admit to our own ignorance. Reframing the problem as “how to be successful with only partial knowledge” makes the conversation more palatable. By talking about partial knowledge environments, we enable a team to talk about the research, investigation of prior art, and learning involved in successfully delivering an application. This is in marked contrast to most teams, which seem to specialize in reinventing wheels and ignoring previous work.

Haste is an endemic problem in the software industry. Project teams are nearly always pressed for time and hence end up ignoring prior work because the team does not take the time to do the necessary research and learning. When teams are under time pressure, the team members make sure that they look busy, even though they know what they really should be doing is taking the time to research and think about what they are doing.

Unfortunately, haste makes the effects of ignorance even worse. When faced with partial knowledge, developers can either make assumptions based on their own experience, or they can ask questions and do research. In all too many organizations, the developers have been trained to make assumptions. True, the training department does not put on a course called “Assumptions 101”, but by word and deed developers are encouraged to keep on working and to ask only really important questions.

— Pete McBreen, Questioning Extreme Programming, Chapter 3

20
Nov

The Roots of XP

by Tony in Questioning XP

Although it is not very evident in much of the Java-centric literature that surrounds XP, it owes most of its heritage to ideas from the Smalltalk world. Even in the 1980s, Smalltalk had powerful, expressive class libraries and a forgiving, flexible, powerful, and productive development environment. The Smalltalk environment encourages developers to be fearless because it is so forgiving. It really encourages incremental design and development because you know there is no way that you can “paint yourself into a corner.”

In sharp contrast to this, I distinctly remember trying to get stuff right the first time when working in C++ in the early 1990s because it was such a pain to change things later. Renaming methods and classes to make them more expressive was not something we consciously thought of because it was so hard to do.

Although XP has grown beyond its roots in the Smalltalk culture, it still embodies the idea that, given good tools, programs are easy to change and that applications can be understood by reading the source code. This is in sharp contrast to the traditional software development experience that programs are notorious hard to change and the code is so convoluted that separate documentation is necessary to make any sense of the application.

— Pete McBreen, Questioning Extreme Programming, Chapter 2