The Trip-Packing Dilemma

E d i t o r s : A n d y H u n t a n d D a v e T h o m a s I T h e P r a g m a t i c P r o g r a m m e r s a n d y @ p r a g m a t i c p r o g r a m m e r. c o m I d a v e @ p r a g m a t i c p r o g r a m m e r. c o m A guiding principle behind agile software development is the idea of keeping things simple. The Agile Manifesto defines it this way: " Simplicity—the art of maximizing the amount of work not done—is essential. " We want to actively increase the " amount of work not done. " We do this by only implementing essential features or framework functionality and by taking steps (such as constant refactoring and avoiding " broken windows " 1) to avoid future problems that might require extra work. Making life simpler is an admirable goal, but unfortunately many developers have a knack for making one of two errors: I Oversimplifying something that really is complex I Overcomplicating something that should be easy The first problem is usually readily noticeable as long as a customer or sponsor is involved in the project, as the corresponding lack of func-tionality soon becomes apparent. Even if the problem isn't noticeable at the user level, you might see warning signs in the code: the number of " special cases " needed to handle a particular piece of application functionality starts to grow suddenly. You start to see code that just isn't tractable; pushing on it " here " causes another problem to pop up over " there. " Developers might begin to exhibit that sudden stricken look (like a deer caught in the headlights of a rapidly approaching car) as they proceed further into the requirements, and so on. We'll talk more about this " Whack-a-Mole " style of development in a later column; for now, onto the second problem. Extreme programming attacks overembellish-ment with the YAGNI (you aren't gonna need it) principle. 2 This pithy maxim admonishes us to build today only those features that we truly need today. The notion that …