I know, I'm already straying from the stated purpose of Agile Junction. But I simply cannot resist. I have to say it. THE ONLY ARTIFACT THAT MATTERS IS THE SOURCE CODE. The source code, including any dependent artifacts that the source code requires, is far and away the most important artifact. Without the source code, you cannot deliver the system. Any other artifact you produce should be aimed squarely at enabling you to create the highest quality source code possible.

Given that the source code is at the center of a software development project, I don't like the traditional depiction of the software lifecycle and corresponding processes that emphasize traceability, as shown in the following diagram.

No, not even in an iterative environment where the lifecycle is "shrunk" to short and more frequent iterations. The problem lies with the manual synchronization required to maintain traceability throughout the lifecycle. It simply doesn't work. I suppose it would work if we had the time necessary to constantly synchronize all artifacts. But we don't. And if we cannot guarantee that all artifacts represent a true depiction of the current state of the system, then the only artifact that cannot lie to us is the source code.

Instead of emphasizing traceability where the source code is next to last, we need a lifecycle depiction that places source code at the center. It's why I like the lifecycle representation in the following diagram.

The lifecycle is activated, with the source code at the center, driving all else. I feel it more clearly exemplifies how a software development effort must work. Construction is at the center. All other lifecycle activities feed construction. We gather requirements so we might create code that satisfies those requirements. We design so that our system can accommodate change. We test to verify we satisfy needs. We deploy so users, clients, stakeholders and other project members experience the system. But everything, or at least as much as possible, must be "executable" against the source code. A test plan is nice, but it doesn't tell us if the system satisfies the constraints. Executable tests do, and they can be automated. A design model is nice, but it doesn't tell us if the system currently conforms to that design. A robust continuous integration strategy generating design quality metrics and a UML diagram of various system components provides accurate feedback on the current state of our design.

And practices should be in place that help you guard, protect, grow and measure quality source code. You must start writing code early. You must start testing your code early. Functional testing. Performance testing. Usability testing. Failover testing. And more. Most of it can be automated. You must be willing to throw away, or refactor, low quality code. If you start early enough, you'll have time to do this. You must be willing to to nurture your source code. Spend a few weeks, or even months, doing nothing more than simply improving the structure of your code. The goal of any software development effort is delivery of quality software. Such is the intent of agile development...to speed delivery. And the only artifact that is absolutely required for you to deliver software is the source code.

So, maybe I didn't stray to far off topic, after all. Maybe I helped lay the foundation for future discussion. We need to employ practices, use patterns, adopt principles and shift paradigms that emphasize high quality source code. So how do we use a bunch of disparate technologies and techniques to help us accomplish that goal? What practices do you apply?

Comments (0)

Write comment

Show/hide comment form