Sunday, March 20, 2005

Rapid Convergence

In agile development, the customers decide which features to implement and when to implement those features. In XP the customers organize this information in the form of story cards. Each story card is assigned a priority and reflects a feature with real value to the business. I've found however that ordering features strictly by business priority may cause thrashing in the design of the code. So, while I still consider business priority to be a very important criterion for selecting what to work on, I also have come to think that technical people should be involved in making these kinds of decisions. In particular, I believe that with some thought, feature development can be organized to encourage rapid convergence of the code. In other words, one should try to avoid a situation in which one starts building a particular piece of functionality which stays in the system for a long time and becomes embedded in the design only to introduce something much later which requires that design to be completely overhauled.

Now, that doesn't mean that one should make the mistake of developing a very general kind of design right from the start, the so called Big Design Up Front (BDUF). However, I think that customers and developers can work together to organize stories to maximize convergence. By convergence, I simply mean that the design of the system accomodates new stories so that their introduction is relatively routine and doesn't require a lot of re-design. As an example (without going into detail), the application I am currently working on handles many different "allocation methods." However, only now are we implementing stories that define more complex topological scenarios, i.e. "This thing which used to connect only to one other thing, now connects to many." From my point of view, this kind of situation represents a example of an opportunity to enhance convergence: Develop the application with just one allocation method, but make sure all of the topological issues are handled early on.

In conclusion, iterative development is the best way to develop an application and BDUF in almost all cases is truly a bad idea. The design should indeed continue to evolve as a software development effort continues. However, by judiciously setting priorities on stories, one can encourage the design to crystallize more quickly.

Saturday, March 05, 2005

The KISS Principle

As software development continues its mad pursuit of new ideas and paradigms, whether it's about Design Patterns, Refactoring, Aspect-Oriented programming, or something else, people's tendency to forget about the basics of good programming continues to be a source of constant frustration for me. Of all of the software development principles and heuristics, the one I consider to be the most fundamental is the KISS principle: Keep It Simple, Stupid!

Good programming means keeping functions small. I've learned to adhere to Christian Pekeler's idea that one should try to limit functions to 6 lines of code. In working with this idea together with TDD, I've been surprised at how strong the effect on the design is. It's a simple idea indeed, but a powerful one!

Another basic principle I value highly is to remove duplication. If adding or modifying functionality has you poking around in many different places there's something wrong. Don't wait for it to get worse. Fix it now. It doesn't make sense to allow things to deteriorate to the point where working with the code becomes painful. It's easy to fix problems of duplication early; fixing them once they become truly painful is hard because by then the code has become inflexible. This wonderfully simple and useful idea leads the design patterns emerge naturally in the code rather than forcing them into existence by force of an architect's will.

So, is there anything wrong with Object-Oriented Programming? Design Patterns? Architectural Patterns? Aspect-Oriented Programming, or what have you? All of these ideas are presented by intelligent people genuinely trying to make a contribution, but all too often developers forget about the KISS principle and the basics of good programming.

Agile Developers are dedicated to keeping the design as appropriate and clean as possible. This is not a haphazard or tentative commitment. Agile Developers do not "clean up" the design every few weeks. Rather, they keep the software a clean, simple, and expressive as they possibly can, every day, every hour, and even every minute. They never say, "We'll go back and fix that later." They never let the rot begin. -- Robert C Martin, Agile Software Development.