- Two Constrasting Existing Approaches
- The 1,000 Lines of Code Rule
- Analyzing the Problem: Task/Message Flow
- Team and Phasing Structure
- A Range of Methodologies
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The 1,000 Lines of Code Rule
So, neither extreme UML modeling nor extreme programming is ideal for this project. But before discussing how I would tackle the problem, let me highlight two points. First, I am not against modeling, per se. I am against taking modeling down to too fine of a level of detail. Programmers have to be given some space. Detailed models are often hard to understand and have errors, just like programs. A particular danger with detailed models is that they strongly deter refactoring because, in addition to changing the code, you must change the model. The rule of thumb that I propose is that models should not descend below the bottom 1,000 lines of code. Any documentation on how the code works at a finer level of detail should be comments in the code itself. By all means, draw diagrams to help write the code, but throw them away after the code is written—they will soon be out-of-date anyway, if they aren't already. But above the 1,000 line code level, models are vital for expressing the complex issues of integration, data modeling, and the relationship between the IT application and the business—and they should be kept up-to-date.
The second point is that objects aren't suitable to all problems. Businesspeople don't think in terms of objects (or rules for that matter); they think in terms of doing things. They are oriented toward actions and deliverables. Information supports the business processes, not the other way round. Thus, you can use objects in the implementation—and, by all means, use objects in data modeling—but, at some point, high-level design must be aligned to the way end users think. I know that this is heresy; I guess you will have to burn me at the stake.
So how would I tackle this problem? I will discuss this in two parts. In the first, I describe the major technique that I would use, which I call task/message flow analysis. In the second, I look at how the project should be organized.