Test Driven Development provides a very structural way for agile coding. One of the steps in TDD is refactor, and this is when we improve our design, but to what extent can it still be deemed as being agile? To remind myself, I would like to write down the *only* two factors that I think are agile to drive this design step:
1) no duplicated code - if the new code is some sort of duplication of an existing logic, or it is destined to be reused by other developers in the team, I would improve the design to avoid (potential) duplication.
2) no unreadable code - if the new code is hard to read, or it makes the existing file(s) difficult to read (for example, the new code might make it harder to navigate), I would improve the design to achieve readability.
That's it. If I find myself designing due to any factors other than these two, I would feel myself being less agile. It happens a lot, sometimes due to the limitations of the technical platform, sometimes due to the "process", but I would keep reminding myself (and maybe the team) that it's not what I preferred.
On your point "the code is unreadable," I find very few if any of the developers I work with that are able to recognize that characteristic. They wrote it, it makes perfect sense to them, it is even transparently obvious. It takes some person not associated with the development to realize what is or is not readable.
ReplyDeleteYes, readability could be subjective. If you have an agile team structure which does the following, it might help.
ReplyDelete1) reasonably team size (less than 10 pairs)
2) pair programming
3) rotate pair frequently - ideally every developer works on every part of the project
4) all team members sits in the same space so that unreadable code being called out easily
With this structure, developers will gradually gain the understanding on what kind of code can be deemed as readable in this project. I should probably start another blog entry about this.