TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> I think what the author (Scott Ambler) meant to say was, "System overviews
> are *often* written towards the end of the development of a release
because
> no one had the skills, experience, or personality required to do things
the
> right way. However, system overviews are *best* written before development
> begins."
No. Agile programming is based on the proposition that the best way to
design something it to build and test a series of prototypes. Software is
developed in a series of controlled iterations that put working software
into the user's hands very early in the process.
The argument is that design is a process of generating information by
experimentation. It follows that you start the design process with very
little information and you generate more and more information as you
proceed. Thus the suggestion that you write the system overview at the end
of the process when you have the most information.
> Is "agile" development haphazard by
> definition?
Not at all. Agile development simply rejects the notion that you should
design the system in detail on paper before any kind of coding begins. The
best design information comes from the process of actually building
something, and from the customer actually using working software. A well run
agile project finishes faster and produces better results than a traditional
project because the agile project learns as it goes along, encountering
problems early and resolving them before they derail the project.
The process used to ensure that the learning is captured and the project
stays on track are quite rigorous. They just don't involve a lot of
documentation. It is a rigorous and disciplined approach, but one that
rejects the notion that rigor and discipline can be measured by the ream.