The ideal picture of iterative software development is that of a small team of developers, designers, artists, etc. working directly with a client with the authority to make decisions and the personal investment to be involved.
There’s a lot of places where this picture doesn’t quite fit:
- Most startups
- Firms developing a product for the public
- Firms developing a product on another firm’s behalf (subcontracting)
When a clear representative of the stakeholders’ needs is no longer available, the role of deciding what’s important ends up devolving upon a member of the team. This doesn’t have to be an official delegation — it simply requires that there be hard decisions to be made and that one person is recognized as being the go-to for resolving hard decisions.
This self-reinforcing, parasitic process is shaped by the day job of the person who makes the decisions. The general types are:
- Who’s going to be developing the thing, anyway?
- Engineers are held in particularly high esteem due to the influences of popular tech culture.
- Early startups are frequently engineer-driven, for reasons of expediency.
- Undercutting the requirements. A lot of programmers will focus on the most difficult part of the problem, seeing related details as best put off to another day. When those deferred ephemera come back up to the queue, it can be tempting to massage them into fitting best in to the Grand Plan.
- Overextending the requirements. This actually can happen at the same time as the above problem, leading to the “you asked for a school bus, I gave you a jet fighter painted yellow” scenario.
- The sheer visual panache and usability everyone associates with programmer-driven projects. See: Hacker News, Slashdot, vim, the command line arguments of find(1), the shallow grave where they disposed of the ‘n’ from umount…
- Well, who’s in charge around here anyway?
- And who’s going to take the blame if things go wrong?
- Ruthless adherence to the release schedule. Managers tend to be personally responsible for their teams turning in work late or underdelivering. This can manifest in half-baked, wobbly releases or in perennially late ones.
- Defensive interpretation of requirements. “It doesn’t say what currencies we need to support. How hard would it be to support… all of them? Now don’t give me that look.”
- It’s a lot easier to get executives and clients alike to sign off on lush, colorful, comprehensible designs than big piles of user stories.
- Design can be very fast, and once you’ve mocked up one screen you have the materials to do 10 more even faster. A proposal with a lot of mockups and a ton of wireframes is going to seem more concrete and credible.
- Pie-in-the-sky expectations. That lovely, concrete picture of a feature that can’t be implemented ends up sitting much too firmly in a client’s head.
- Inflexible requirements. “The VP of so-and-so signed off on that design element, we can’t resize it.” “That bit of the design shows up on ten other screens, it can’t be changed here.”
- Someone who actually gets paid to do it gets to make the unfun decisions.
- Prematurely curdled features. Ones that have spent so long being tweaked and revised and reconsidered that they have long since lost all resemblance to anything the customer needs.
- Balsa-wood requirements. Analysts might have a crisis of authority when serving as an indirect representative of other people’s needs. This can result in a coherent, useful feature being molded into unrecognizable goo by developers, designers, management, the passing nosy sales associate…
- You’re gonna make a ton of sales! For a little while!