5

Recently I had an interview with dev team in a company. The team uses agile + TDD. The code exercise implements a video rental store which generates statement to calc total rental fee for each type of video (new release, children, etc) for a customer. The existing code use object like:

  • Statement to generate statement and calc fee where big switch statement sits to use enum to determine how to calc rental fee
  • customer holds a list of rentals
  • movie base class and derived class for each type of movie (NEW, CHILDREN, ACTION, etc)

The code originally doesn't compile as the owner was assumed to be hit by a bus. So here is what I did:

  • outlined the improvement over object model to have better responsibility for each class.
  • use strategy pattern to replace switch statement and weave them in config

But the team says it's waste of time because there is no requirement for it and UAT test suite works and is the only guideline goes into architecture decision. The underlying story is just to get pricing feature out and not saying anything about how to do it. So the discussion is focused on why should time be spent on refactor the switch statement.

In my understanding, agile methodology doesn't mean zero design upfront and such code smell should be avoided at the beginning. Also any unit/UAT test suite won't detect such code smell, otherwise sonar, findbugs won't exist.

Here I want to ask:

  1. is there such a thing called agile design in the agile methodology? Just like agile documentation.
  2. how to define agile design upfront? how to know enough is enough? In my understanding, ballpark architecture and data contract among components should be defined before/when starting project, not the details. Am I right?
  3. anyone can explain what the team is really looking for in this kind of setup? is it design aspect or agile aspect?
  4. how to implement minimum viable product concept in the agile process in the real world project? Is it must that you feel embarrassed to be MVP?
4

There are many approaches in the real world about this. You are asking a very broad question so my answer will be a bit general.

  1. Of course there is a concept of design in agile. There is normally no concept of up-front design, but systems are designed as you go and, of course, legacy systems have a design.

  2. Strictly speaking, you should do the bare minimum design that you can afford. It's perfectly possible that a web site starts with a static html page hosted somewhere. In fact, many sites do. Of course, sometimes it's necessary to do a bit of upfront work to have a bare bones design implemented, but we should be talking about days of work at most.

  3. That is a question for your team, but I don't think it's correct to make it an up-front question. Teams don't need anything besides networked computers. All that a team needs is determined by what the team needs to achieve.

  4. MVP is the minimum set of stuff you need to ship in order to have any value. It is typically a "sign up for beta page". After that, the minimum amount of features that will allow your product to work. I would like to stress "minimum" here: take the "no-so-minimum" set of features you are likely to come up with initially, and start stripping away all you can while keeping the core working. The whole point is enabling a feedback cycle with early adopters. An MVP should be an alpha version, not a beta.

2

The important thing with design in an agile process is that it has to be done within the process. One of the first things to produce is a design, otherwise you've got no idea what you're doing. But that design shouldn't take long to produce, and should thereafter be an artefact that is subject to revision through the agile process just as the code is. Don't assume you're going to get it right first off. Don't be afraid to add to it if necessary and to refactor it if it is too complicated.

Try to keep the design to something that will fit on one page (or one slide) so that people can understand where the piece they are working on fits in the overall picture. Sure, that won't cover all cases, but designing up front to cover everything is not an agile practice; that follows naturally from the founding principle that the requirements are not all known up front (and the obvious point that true design follows from requirements).

To know when you've got too much? Frankly, you probably already have too much. The high-level design — the truly useful bit — shouldn't take too long, and the low-level design is just whatever drops out of the backlog. (Hint: if you're thinking about algorithms in the design, you've already almost certainly got too much detail. Well, unless you're doing something so funky that it is impossible without that specific algorithm…)

What's important for the team is that they get something going and check back with the product owner for the next iteration towards understanding the requirements. As with all agile development. (Re the MVP, remember that it might take a few of iterations to get there, and don't be afraid to not make it look good in the first few revs; customers all too often think that having the CSS applied means that the whole service is finished. You know and I know that that's just not true.)

  • 1
    "designing up front to cover everything is not an agile practice": I knew this principle from practice way before I have heard the word "agile": your design should set an overall structure for your code but most of the details are discovered during coding. Isn't this just common-sense? Also in the V-model you can make a prototype to investigate the requirements and the design before you build the real product. So in what sense is agile different from common (common-sense) practices that existed before? – Giorgio Oct 19 '13 at 17:42
  • @Giorgio “Isn't this just common-sense?” Of course. Much of agile methodology is a codification of common sense, though I suspect that the very act of making a “Methodology” drives the common sense out. Don't do Agile because it is Agile; do it because it is largely sensible and produces reasonable results in the face of rapidly-evolving requirements. – Donal Fellows Oct 21 '13 at 8:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.