Specify Nothing

In some organizations, written specifications are seen as overly constricting and downright evil. To rectify this imagined problem, project leadership may promote, directly or indirectly, use of this AntiPattern. SpecifyNothing assumes that all elements of a system in flux can be most easily managed if they only exist in the developers' heads. This can work to some extent in a very tightly-knit crew, but quickly becomes unmanageable as the organization grows, or developers leave and are replaced.

I imagine proponents of ExtremeProgramming and those who agree with TheMythicalManMonth would have wildly different opinions on this subject.

I have a sample of those organizations with a particularity: SpecifyNothing with a variant that would be ArchitectureNothing?. As the organization does not have any architect and the architecture role is taken in charge by default by junior project managers not familiar with IT, the architecture is done by non IT guys that do not document it. The verbal requirement goes to various development teams and ends up in QA where QA teams are gathering the pieces trying to figure out what the architecture can be. For each part of software to integrate, there was a SpecifyNothing or almost. This is real verbal tradition, and usually it works quite badly when you try to integrate. You can face problems such as client and server not talking the same protocol (huhu).

The solution is to go back to the standards and push for the company to realize that IT can be a real job with architecture and functional competences required. OlivierRey

True Olivier, but few IT managers have the TopMind necessary to teach top corporate managers about IT. In my humble opinion, for that to occur, an outside consultant or influential book will be required. --EdwinEarlRoss

''True also Edwin, sure that without some kind of introduction to IT, most managers are lost and cannot find their way in the jungle of fakes and real stuff. --OlivierRey

Your lips to God's ear, Edwin. This has become dramatically evident in the embedded world where I work. I have seen far and away too many firms with projects that weren't properly specified by someone with the authority to make a set of requirements stick. One project comes unbidden to mind: my very last captive job about 17 years ago involved creating banking equipment. Mostly teller machines that would generate and/or process checks, sign them, etc. These guys wanted a new teller box that could be used with any language (including Arabic, Farsi, Korean, Japanese, Mandarin...) and a fairly wide variety of paper check sizes. A whole raft of other features were supposed to be added to this thing to make it more attractive on the international market.

The problem with this new box was the lack of a cohesive specification defining the path of development. In Engineering we wanted to make use of some of the legacy products and the knowledge accumulated over many years of handling paper, judging offsets, imprinting, yada yada. This approach made a lot of sense for a feature based machine that would have limited flexibility but a lot of built-in know-how.

The Marketing and Sales folk wanted an application-based machine that could do all kinds of stuff that we'd never even anticipated a teller machine being able to do. Flexible report formats, network capable, graphic display, yada yada. You can see where this is going.

As a result, I had in my possession fourteen separate documents all purporting to contain partial or complete specifications for this product. Needless to say, there were plenty of conflicts in addition to the obvious overlap. We were using a couple of consultants (this was just before I became one myself) and I was responsible for handing out work and getting the results integrated. Because I was answering non-stop questions about which "document" contained the actual requirements I eventually put a stop to the work and issued a memo saying that work was at a standstill until we had a single, accurate, and complete set of specifications for the new box.

Oh, boy.

The Marketing and Sales boys went into a tailspin but emerged a week later with what they called their revised, complete, up-to-date, and final specification. This turd read like a Stephen King fantasy with delusions of grandeur. It was a new product.

Anyway, that project died, the job died, and the firm died soon afterward. I went into consulting full time.

Fast forward to year before last. A consultant buddy of mine got called in to a gig helping a large water handling product company get their corporate technology center in Milwaukeeland sorted out. They were trying to do the right things with object-oriented design and code, modular construction, yada yada. They couldn't figure out why stuff just wasn't working out for them. My buddy called me in to help him get this client squared away.

One of the important things we did for this client was to identify what the minimum set of documents was that they could use and still end up with a real product. We also identified the content of each of these documents, where it came from, and how it was structured. We helped them analyze their object design so that they could model the right objects instead of just turning electronic widgets into the system's "objects" in the code. And we helped them get a lot of their regulatory and certification documents tightened up prior to submission.

The thing is, there are a lot of firms out there that are trying to be smart about developing products in the new age, but they don't know what they don't know. They need help just becoming aware of their own ignorance. Once some of these deficiencies are pointed out to them then they are often quite willing to do what it takes to fill these holes in their understanding. I guess now I'm gonna go after this kind of work whenever I can get it. Heh.

-- MartySchrader

CategoryAntiPattern