Agile Software Development

In traditional software development the design phase happens in the beginning of the project, takes quite a long no-coding or little-coding time. At the end of the phase, the design is considered being more-or less frozen. It might sound logical to plan ahead in a detail, however, in the case of software only the final source code is the real design - any diagrams or descriptions can at best be the higher level design abstractions. Therefore attempts to fix the design well in advance often lead to the wrong assumption and sub-optimal solutions.

Incremental Design is one of the core values of the XP. Many favor to have a "rough up-front design" rather than the "big up-front design". The days when the Design is a single long term process is gone (as in waterfall or v-model) and developers are embracing the design as an integrated daily process.

Software development has taught us to know that the "requirements change" and we need to live with it. When requirements change, the design too changes. We often hear that "the design need to be flexible enough", but not practical in all cases. The software design is often a function of the designer's technical and system/business knowledge. Its very difficult to predict and assume some of the changing requirements in advance.

Agile software development methods are sometimes criticized for the inability to rely on. Agile project managers are unable to produce the fixed upfront effort-time-costs estimation. Sometimes it is even the core argument of the waterfall process proponents.

In fact agile manifesto principles "Customer collaboration over contract negotiation" and "Responding to change over following a plan" do not state that contracts and plans are useless. Agile community recognizes the value of contracts and plans, it is just so, that the agile developers value collaboration and responding to change more. If there is a possibility to create the upfront time and costs estimation, the agile team

During the last Agile SW Development Practices Seminar in Vantaa the participants shared a set of stories about how the switching to the agile development methods proceeded in their companies. A reasonable amount stories included a mention about that without the agreed definition of "done", nothing was completely done.

Own experience

Few weeks ago, when starting a new project, our team decided to try figuring out what our 'done' means. It was a total surprise to discover that within a small and rather coherent team of five persons we had three different points of view.

Anssi Piirainen raises the idea about the need to be good at being wrong in order to create good software. The core idea is good - you have to be ready that the first implementations might later look not very well. However, Anssi also presents the micro case study describing the problems with the "just-in-time design" approach. The changes required appeared to be unexpectedly difficult to not that experienced programmers.

Just-in-time design is not a silver bullet. It is just yet another good tool that can be rather useless until it is used with the correct support practices.

I can recall several cases, when a seemingly clean'n'simple class appeared to be a huge and difficult to debug entity with loads of underlying asynchronous logic. The simple and small public interface hides the implementation details and according to the good Object-Oriented style all the underlying details are private. Or is it a good style to hide the implementation details into many private methods?

As it often happens, the problem comes from a good idea overused to the extent, where it inhibits another good idea. The encapsulation makes it easy to use your classes or systems externally, but it should not make you forget the internal structure of the class. As Michael Feathers tells

It often means that there's some other abstraction hidden away inside the class that might be useful to pull out.

I don't care how good you think your design is. If I can't walk in and write a test for an arbitrary method of yours in five minutes its not as good as you think it is, and whether you know it or not, you're paying a price for it. (Michael Feathers)

If you practice a lot of unit testing, test-driven-development of whatever method that includes a lot of testing, you have to spend a lot of time on it. And most of time you have to do the testing-related work before the problem happens and before anyone is affected. Certainly it is good to capture the bug early, before it hurts anybody, but the need to do the "extra" work in advice introduces the temptation to "just tweak this small feature and test it if the problem arises later".