The difference between a specification and an implementation

In some ideal world, the two would be the same--you would write a specification, and the computer would build it! However, if that were true, then it would be impossible to create something new. Why? Because if you can’t describe what something is, you can’t build it. Any system that allows the description of a specification with automatic implementation must have a fixed set of terms.

The first time something is done, the step from specification to implementation requires faith. “Let there be light”. What is light? Light has never existed before. So, how can it now exist? Let there be light is a fine specification. But, the implementation cannot be directly derived from the specification. Something has to be added.

Generally, specifications are easy to understand, hard to believe. It’s easy to understand the statement ‘Build a computer that runs at 10 TeraHz’, or ‘Build a spaceship that will fly to the nearest solar system outside of our own.’ It’s hard to believe either can be done.

Implementations are hard to understand, easy to believe—because you’re looking at the thing in action! It’s easy to believe there is light. We are living in the implementation of that specification. Figuring out exactly how light works, on the other hand, that’s hard to understand.

Another example was Bill Gates and Paul Allen. They had a specification to build a BASIC interpreter on the Altair 8800. The specification was simple: Those words, and the BASIC language specification. Easy to understand, hard to believe. Once they completed the implementation, it was easy to believe they had it working.

Now, if you have done something before, then yes, it is possible to join the specification and implementation. You are not really doing anything new, however. You are just doing the same thing over in a modified way. However, if you want to add anything new to the product, specification is again required.

Of course, you can always skip the specification stage, and just write the implementation. This is inefficient. Because you don’t fully understand what you are building, you will undoubtedly make mistakes. Finding mistakes at the specification stage is much cheaper than at the coding staging. Finding mistakes at the coding stage is much cheaper than at the testing stage. Finally, finding mistakes at the testing stage is much cheaper than finding them in the hands of the customer.

Interestingly enough, it should be possible to define a language, and be using it, without thought for what exactly the terms in the language will do. Defining a language should take seconds, not hours, days, or weeks! Creating an implementation (or describing how to create an implementation from a specification), of course, takes time. Again, it’s easy to ‘understand’ a specification. It’s difficult to implement it.

What is needed, then, is a system that allows you to formalize and implement what you have done before, while simultaneously mixing this with specification for what is new in a particular product. Your specification authors, when describing how to display information or what controls exist on a product, will use the formalized specification/implementation language. When describing how the new fangled space travel feature will work, they will use more free-form. The computer consumes the formal parts, and produces code. You, the developer, get to formalize the informal parts, and describe their implementation to the computer. Next time someone needs the space travel feature, they now have a formal language/implementation. Our hope at Precision Software is that we are building exactly that in the language we call Smpl.

I'll close this post with these words: Without faith it is impossible to please God!