Ain’t superstitious!
Willie Dixon’s great blues song, “I Ain’t Superstitious,” had him saying he ain’t then proving he is, and I think most of us fall into some kind of superstitious thinking; it’s just a matter of accepting something on faith rather than verifying it for yourself. That’s the point of an insightful article in the “Developer Wisdom” series at CIO (thanks to Tim Walker for the link). It’s called “Fighting the Superstitions of Software Development: Questioning the Assumptions,” and it’s about examining your assumptions (and the prerequisite: learning to understand when you’re making assumptions and accepting things on faith without knowing whether they’re verifiably true.
At Social Web Strategies, we’re learning that we’re only better off if we question our assumptions and everybody else’s. The article I’ve linked talks about assumptions as superstitions, “information accepted on faith, without personal knowledge or examination.”
People pass along “everyone knows” data without questioning it, and others repeat the superstition as though it’s undeniably true. Confidence isn’t knowledge; in fact, confidence can prevent knowledge and innovation from happening, because an unquestioned belief means you never measure, never test, never look at alternatives.
Another point from our perspective: we know that, going into a project, there are all sorts of assumptions on our end and on the client’s that could prove incorrect as we get into the project and begin to learn (because every project is a learning experience, and what you thought you were doing is often not what you actually find yourself doing as the project evolves). Projects fail because these assumptions aren’t examined up front, so we make a point of identifying assumptions and listing them in our contract, with the understanding that a busted assumption can have an impact on project cost and duration. This also means that a project begins with real clarity and a true meeting of the minds, something you don’t get if you’re using a boilerplate contract with limited up-front discussion. The lack of clarity at the beginning of web projects leads to failure: even if a functional web site results, the client isn’t satisfied that they got what they wanted or needed. (There are other resons for this, such as a lack of clear strategy behind technology planning, something Brian Massey and I addressed in a presentation a couple of months ago.)
