Leading Request
Leading Request
When a (usually well-meaning) user makes a request for new functionality, it can be common for them to phrase the request only in terms of an exact implementation of what they want, rather than the problem they are trying to solve. Often, this can blind development teams to considering other approaches to the problem, force them to make a simple system unnecessarily complicated, or both. The Leading Request can be insidious, because it is often the case that the request comes from someone who is supposed to be suggesting implementations or who has a good track record of suggesting good ideas.
This is probably best illustrated by an example: the dev team produces a product used by another division within the company. One of the product's functions is to produce a file with certain information in it (say, about apples). A request comes in from this other division saying "you know, we'd really like information about oranges in that file". This seems a reasonable request, but it causes a great deal of discussion among the development team. Oranges are not apples, after all, and it turns out that getting them both into a single file is tricky. Not only that, but to do it, an entire subsystem for getting information about oranges has to be adapted to provide information that the file is supposed to provide. After about three weeks of planning and some initial work, the other division asks about progress, incredulous that it as taken so long. The team explains the technical difficulties and are about to spell out the design of the new file when the person who made the request says "we just want to have information about oranges. We don't care if it is in the same file or not. We just thought it would be easy to drop into the file."
Had the initial request said only "we want information about oranges", the team would have just built another simple system for dumping out whatever information they had on oranges. Because the request was a leading one, saying "in the file", it lead the unquestioning developers to waste a huge amount of time and effort.
General Form
A feature request occurs without clear indication of what problem the request intends to correct. The team builds to the request literally, wasting time and effort.
Symptoms And Consequences
This pattern can be a tough one to detect in time, which makes it hard to stop. Once detected, the solution is usually immediately evident. Thus, solutions revolve around detection. Unfortunately, the best antidote to this anti-pattern is developer experience. Typically, seasoned developers learn to "smell" this kind of request and get clarification before beginning. Training developers to ask "Why do they need this?" before any feature request can help.
A more process-oriented solution might be to require information about why the feature is needed in a request form, but this is not guaranteed to solve the problem.
AskWhy. It will help you SimplifyTheRequirements (the latter page gives a rather nasty example of a LeadingRequest).
Variations
A common variant of a Leading Request is a Leading Defect Report. This is where the person who discovers a bug reports it in a way that suggests the problem is in one area, whereas it is really in another.
This is by far considered a BestPractice rather than an AntiPattern by clients who are strongly interested in the graphic design of the project. This can easily be caused by a marketing firm or some other kind of middleman participating in the work. The pattern here comes usually in the form of a large set of Photoshop or PDF files containing screen layouts, which are considered all the programmer (or project team) needs to implement the site.
Sadly, the client is perenially impressed by the attention to detail shown by asking what the buttons on the screen actually do. "Ooh, good call! I'll find that out." --JesseMillikan
And things get event better when the screen layouts doesn't match the multiplicity of the undelying model (See WidgetsRepresentRelationshipsInTheModel) and you are asked to use a grid for a ToOneRelationship?... or a ComboBox for a ToManyRelationship?... or a TreeView for something that is not a HierarchicalRelationship?... or two GridView acting as MasterDetail? for 2 entities that are not related that way... and it becomes really hard to explain to the GraphicsDesigner? and the Client why the screen layout just doesn't fit the DomainModel, and it is a better idea to redesign it from scratch.
Another big problem is when you want to take advantage of a particular WidgetFramework? that doesnt allow for a particular "look & feel" feature that the GraphicsDesigner? believes is key for the good looks of the application and you end up reinventing a component just to get rid of a margin, or to add an icon of a particular size in a particular place... and then after all that effort the Clients says "you know, now that I see this with data and everything... I really don't like that icon there"
Are you the one behind that plant? Come out of there, you're scaring me.
Much of this belongs on its own AntiPattern page; does anyone have a suggestion? I would say it belongs under the topic of LeadingRequest, but it's a very recognizable situation. Other common problems are the misuse of graphic design elements (tabs, for instance) and all kinds of "enterprisey" language in menu items and other text. PlainEnglish just seems improfessional, I suppose. --JesseMillikan
EditText of this page
(last edited December 21, 2014)
or FindPage with title or text search