Greg Crisp

Here’s a test: Take 12 random stills distributed evenly across the span of a movie and give them to someone in a random order. Ask that person to sort them based on their sequence in the movie.

Whether or not someone puts them together in the correct order is essentially random.

Unless… that person has seen some or all of that movie before.

Wireframes:

• High-level user interface designs for a proposed software product.
• Potentially, though not necessarily, sequentially-oriented screen shots of specific parts of a computer system.
• Marketing material

This is the same for software development. Give a software developer some wireframes with maybe a day to review them, plus about 1.5 hours of overview of the material by someone who helped create it. Throw in a rapidly produced requirements specification for good measure. It is likely you will at this point assume a great deal of knowledge on the part of the developer, and expect them to deliver a high-quality product in a predictable time frame.

This seems to be the management practice common today in software production, and it results in problems.

An example of a brick layer seems useful:

A brick layer of any experience will be able to give you a predictable estimate for building a wall, given the length, width, and the height of the proposed wall. It’s a linear problem, and the experienced brick layer has built many a brick wall before in his career.

A software developer can also be highly predictable, provided they’ve done enough of this type of project before. If you come to them with a project with typical requirements for bit-plumbing, that project requires a known technology stack (E.g. Apache, Tomcat, Java, MySql, Hibernate, Spring, and/or Struts), you have the data model largely done, and you know all the use cases, she can probably give you a fairly predictable estimate.

However… throw in requirements to use proprietary and poorly documented frameworks or components, restrict the use of well known technologies, have poorly specified or incomplete user stories, structure your build environment in such a way that builds are slow, long, and recur often, and your project’s predictably drops towards zero.

Worse still, give an inexperienced, junior developer primary responsibility for significant architectural or design decisions. They just haven’t made enough mistakes or had enough decisions blow up in their faces to recognize the bad ones.

“Recognition (re+cognition) is a process that occurs in thinking when some event, process, pattern, or object recurs.” – from The Wikipedia

Prescience: The ability to see and predict the future.

It’s common sense. Prescience is about recognizing patterns and altering your behavior to flow with them. Recognition requires recurrence, and something must occur before it can recur. You have to have experienced the occurrence in order to recognize the recurrence, and the act accordingly to achieve the outcome you desire.

Experience in the business of executing software projects created a higher degree of reliability in estimates and success. Lack of experience produces the opposite.