Everyone knows the barely clever phrase that, "If you assume you make an 'ass' out of 'u' and 'me.'" Assumptions are particularly toxic in relationships, and costly in finances. They also suck for software development.
There's a recurring theme in all of the software projects I've seen over the last decade or so, where things took too long or outright failed. In every case, too many assumptions were made. The gut instinct of many people involved with building software is that you fix this problem by trying to spec-out and document every last little detail. Really, that makes the problem worse.
I'll give you two examples. First there's the classic super specification situation, where project managers, architects and sometimes executives develop a huge document that describes everything the application will do. On the surface, this sounds like a good idea because it doesn't leave anything to chance for the actual implementation. The problem is that, aside from the ridiculous notion that this worthless stack of paper (or bits) builds consensus, too many assumptions are made about what users actually want to do.
You can never truly know if what you're producing meets the needs of users until you get it in front of them. That's just the way it is. In fact, you can't forget that those needs may evolve too. These massive spec docs, which are intended to be a contract for what is supposed to happen (and don't ever buy that "living document" bullshit... no one wants to maintain it), are only a snapshot of what you assume meets the needs of the user today, and doesn't not account for the future or actual interaction.
Another example is with regard to scenario-driven engineering. Conceptually this means that you figure out what a user needs and expects, and build a rich "picture" or narrative of the user and how they do stuff. That profile drives your decisions. I generally like some parts of this approach, but the problem is that engineering folk too frequently take this to the same level as the super spec. When you do that, again, it makes too many assumptions, sometimes about the user you think you want to serve in the first place, instead of the user best served. (Some people also consider this methodology as having distinct planning and design "phases," which is also wrong, but that's a post for a different day.)
The bottom line is that entirely too much time is spent in software engineering acting on assumptions, and that's wasteful. I'm a big fan of building things and getting them in front of people. If you don't get it right, or I should say, since you won't get it right, you can iterate on the idea and still be closer to usable product. Think about that for a minute. Instead of spending all kinds of time making plans (best guesses) based on assumptions, you can build something on those assumptions and quickly find out what you've got wrong, learn from it, and be closer to the good stuff.
This approach works. I've seen it up close. I've participated in it. It does scale. In a world that is getting away from boxed product and into living, breathing services, the opportunity to deliver value early and often has never been greater. There's no value in massive amounts of documentation and narrative based on too many assumptions. Skip that step, build something, deliver it, iterate.
No comments yet.