This speaks to my prejudice in favor of technique over technology. And the concept of agility seems to be just the attitude of any good designer that your best weapon is your critical sense, and your compulsion to discard anything that isn't going to work.To which I would reply:
Sort of ... "agile" is a term of art that refers to a collection of practices aimed at reducing the lag between finding out people want something and giving it to them. Arguably the core of it is "launch and iterate", meaning "put your best guess out there, find out what it still needs, fix the most important stuff and try again".
This is more process than design, but there are definitely some design rules that tend to go with agile development, particularly "YAGNI", short for "You ain't gonna need it", which discourages trying to anticipate a need you don't yet know that you have. In more technical terms, this means not trying to build a general framework for every possible use case, but being prepared to "refactor" later on if you find out that you need to do more than you thought you did. Or, better, designing in such a way that later functionality can be added with minimum disruption to what's already there, often by having less to disrupt to begin with, because ... YAGNI.
Downey refers to "agile" both generally and in the more specific context of "agile vs. waterfall". The "waterfall" design process called for exhaustively gathering all requirements up front, then producing a design to meet those requirements, then implementing the design, then independently testing the implementation against the requirements, fixing any bugs, retesting and eventually delivering a product to the customer. Each step of the process flows into the next, and you only go forward, much like water flowing over a series of cascades. Only the test/fix/retest/... cycle was meant to be iterative, and ideally with as few iterations as possible. Waterfall projects can take months at the least and more typically years to get through all the steps, at which point there's a significant chance that the customer's understanding of what they want has evolved -- but don't worry, we can always gather more requirements, produce an improved design ...
(As an aside, Downey alludes to discussion over whether "customer" is an appropriate term for someone, say, accessing a public data website. A fair point. I'm using "customer" here because in this case this is someone paying money for a the service of producing software. The concept of open source cuts against this, but that's a whole other discussion.)
The waterfall approach can be useful in situations like space missions and avionics. In the first case, when you launch, you're literally launched and there is no "iterate". In the second, the cost of an incomplete or not-fully-vetted implementation is too high to risk. However, there's a strong argument to be made that "launch and iterate" works in more cases than one might think.
In contrast to waterfall approaches, agile methodologies think more in terms of weeks. A series of two-week "sprints", each producing some number of improvements from a list, is a fairly common approach. Some web services go further and use a "push on green" process where anything that passes the tests (generally indicated by a green bar on a test console) goes live immediately. Naturally, part of adding a new feature is adding tests that it has to pass, but that should generally be the case anyway.
Superficially, a series of two-week sprints may seem like a waterfall process on a shorter time scale, but I don't think that's a useful comparison. In a classic waterfall, you talk to your customer up front and then go dark for months, or even a year or more while the magic happens, though the development managers may produce a series of progress reports with an aggregate number of requirements implemented or such. Part of the idea or short sprints, on the other hand, is to stay in contact with your customer in order to get frequent feedback on whether you're doing the right thing. Continuous feedback is one of the hallmarks of a robust control system, whether in software or steam engines.
There are also significant differences in the details of the processes. In an agile process, the list of things to do (often organized by "stories") can and does get updated at any time. The team will generally pick a set of things to implement at the the beginning of a sprint in order to coordinate their efforts, but this is more a tactical decision, and "requirements gathering" is not blocked while the developers are implementing.
Work in agile shops tends to be estimated in relative terms like "small", "medium" or "large", since people are much better at estimating relative sizes, and there's generally an effort to break "large" items into smaller pieces since people are better at estimating them. Since this is done frequently, everyone ends up doing a bunch of fairly small-scale estimates on a regular basis, and hopefully skills improve.
Waterfall estimates are generally done up front by specialists. By the end of the design phase, you should have a firm estimate of how long the rest will take (and, a cynic might add, a firm expectation of putting in serious overtime as the schedule begins to slip).
It's not clear how common a true waterfall process is in practice. I've personally only seen it once up close, and the result was a slow-motion trainwreck the likes of which I hope never to see again. Among other things, the process called for designers to reduce their designs to "pseudocode", which is basically a detailed description of an algorithm using words instead of a formal computer language.
This was to be done in such detail that the actual coder hired to produce the code would not have to make any decisions in translating the pseudocode to actual code. This was explicitly stated in the (extensive) process documentation. But if you can explain something in that much detail, you've essentially coded it and you're just using the coder as an expensive human typewriter, not a good proposition for anyone involved. You've also put a layer of scheduling and paperwork between designing an algorithm and finding out whether it works.
We did, however, produce an impressive volume of paper binders full of documentation. I may still have a couple somewhere. I'm not sure I or anyone else has ever needed to read them.
This is an extreme case, but the mindset behind it is pervasive enough to make "agile vs. waterfall" a real controversy. As with all such controversy at least some of the waterfallish practices actually out there have more merit than the extreme case. The extreme case, even though it does exist in places, functions more as a strawman. Nonetheless, I tend to favor the sort of "admirable impatience" that Downey exemplifies. Like anything else it can be taken too far, but not in the case at hand.
No comments:
Post a Comment