Category: design

Upfront planning in agile

January 4, 2007 by Artem

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

Definition of 'Done'

May 1, 2006 by Artem

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.

We have to be good at being wrong. Architects can help

April 28, 2006 by Artem

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.

Good design ghosts

April 24, 2006 by Artem

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.

Testability as the design metric

March 26, 2006 by Artem

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".