« Splagbots | Main | Development Tools used this Semester »

Agile Spaghetti

I personally like Agile development. In fact I've used it agile methodologies before I even heard about Agile.

The strengths that I like include the fast development time, the focus on results over paperwork, and the collaboration between developers and end users.

The danger to Agile techniques is the lack of documentation that is necessary for large organizations. Large organizations often have a correspondingly large IT support staff and when they need to support an application, good documentation is necessary. Because Agile focuses on getting working code to the end user, this documentation is often not done, incomplete or out of date.

Another danger in Agile is the propensity to begin coding too quickly. I think design/coding should only be started after a good understanding of the project and the major components are understood. Even though Agile focuses on iterations of increased functionality, it is important to know how your early iterations will affect later iterations

In our class project, we've had to re-design and re-implement functions from earlier iterations because the early iteration did not anticipate a future need. When you need working code in a short period of time and have to re-do code from an earlier time, the tendency is to create "spaghetti code" where code is strung together in a less than optimum manner.

Spaghetti code is very hard to maintain because it is difficult for other programmers (even the original programmer) to follow the logic when doing maintenance, enhancements or troubleshooting of the system. These type of systems will usually also have less than optimized performance.

When doing an Agile project, you should plan on time for re-factoring code and documenting the system in a way that ensures that the system will perform well and be able to be supported by the end users organization.

Comments (1)

Interesting observation. We asked James Goebel about that. The partial answer is test driven development. At least that keeps you from dropping key functionality. It also documents requirements as you find them.

You're correct on the refactoring end though. Many agile tools really focus on making this easier.

Archives