Engineering design for business value

We can observe that the economic cost of the use of the product or service of a technology business exists or has effect in terms of the client's time, money, choice, convenience, or effort.

Likewise we can observe that a change to the product or service of a technology company has (at least) qualifiable economic costs.

And so this is how we know the economic relation between design and value.

Constraints are an element of design. Some constraints are selected as precursors to the process of the development of a design, these are design requirements. Some constraints are selected during the design process as necessary to the implementation of a design. And then some constraints are implied by or effects of design or development choices.

Generally constraints restrict degrees of freedom for the future use or development of a product or service. Positive constraints contribute to the client's benefit from using the product or service. Negative constraints contribute to the client's economic cost of using the product or service, and are a debt to value.

One of the murkiest sources of negative constraints is design or development complexity. A failure to realize the simplest possible solution (to a design or development problem) is to install known or implied negative constraints, present or future economic costs to the use of the product or service.

Negative constraints are debits to the fundamental multipliers of business growth and sustenance. We know this to be true because we know the client's economic costs of use are the determinants of acceptance and productivity.

Minimizing design complexity is maximizing business value.

The process of Qualifying engineering design complexity is like the process of Quantifying computational complexity. First we need abstractions to capture significance. More explicit expressions of complexity are available at the small end of the domain, while comparative complexity is practical throughout most of the domain.

We also need to identify internal and external elements of technical design complexity, implementation versus interface, how they are distinct and how they are not. Internal issues may be independent of external ones, and thereby not immediately relevant.

When we master these processes for the recognition, identification and clarification of design constraints we master the processes for delivering technological growth and sustenance to the business.

An algebra of HTTP

A description of HTTP in an integral algebra serves as yet another tool for reasoning about principles.

The response is a point in the domain that is HTTP. A GET request is an identity relation on that point. A function from the domain of the request into the domain of the response exists, whether explicit or implied. The function is implied when a resource is created but not returned in the response.

Therefore the expression

  GET /index.html

identifies a point in the domain of HTTP. And likewise the expressions

  PUT /index.html
  DELETE /index.html

are operations on the same point.

Compare this to arithmetic. The identity expression is

  1 = 1

and operational expressions include

  1 + 1
  1 - 1

.

The equivalent algebraic identity expression would read as

  "GET /index.html" = "response entity body data"

.

When we can see this algebra, then we have new eyes.

On the science of computing

Is there science among the following bytes?

  GET /index.html HTTP/1.0
  Host: www.syntelos.com

Syntax and semantics are perhaps the principle areas of science in computing, at least from the perspective that dominates my world. They invent and describe the tools we employ for manipulating bits, bytes and words into increasingly more interesting interactions.

The more subtle the work, whether science or art, the more invisible or transparent it can be. Larger purposes are elusive until illuminated. And greater profundity can have more power.

From here...

Take for example one of the first issues in the latter day web network interface. What's the difference between the following.

  PUT / HTTP/1.0
  PUT /index.html HTTP/1.0

And should

  GET / HTTP/1.0

always respond with

  HTTP/1.0 301 Moved Permanently
  Location: http://www.syntelos.com/index.html

?

Should the server permit

  PUT / HTTP/1.0

is the classic question that recognizes a

  GET / HTTP/1.0

that returns a

  HTTP/1.0 200 OK

as a vanity hack with the cost of implying

  PUT / HTTP/1.0

to the tool that used it on behalf of the user who wanted to edit her home page.

If we make the null PUT work, how will the server deal with content types and file names. What does the null get return when the file was created by the null put?

When the system becomes defined in code where it could have been defined in user data, everyone looses.

What do I need to do to such a system to change the file name returned by or redirected to by a null get?

How do I represent multiple choices for the selection of the product of a null get? Check your terms closely for application to all cases.

Solving for all variables, when we work this little problem, we discover that the null get should redirect to a file name, and the null put should be a bad request.

To there...

Where is the science in the art of delivering more interesting interactions? Is it in the server side software architecture? Is it in the server side systems architecture? Or is it in the server network interface?

It's in the server network interface where all of these issues and more fall onto one simple, clean edge.

java.lang.MemberOf

Wouldn't it be cool if there existed an annotation named java.lang.MemberOf that could tell the compiler that the marked interface is always implemented by a subclass of a described class.

package pkg.io;

@MemberOf(java.io.OutputStream)
public interface OutputStreamInterface {

    public void write(int uint8)
        throws java.io.IOException;

    public void write(byte[] buf, int ofs, int len)
        throws java.io.IOException;

    public void flush()
        throws java.io.IOException;

    public void close()
        throws java.io.IOException;
}

So that the name pkg.io.OutputStreamInterface could then be used in any way that the name java.io.OutputStream can be used?

Any implementor of an interface marked MemberOf would derive from the described class, in the example java.io.OutputStream.

Aside from creating a syntactic meta class, the compiler would need to inject CAST instructions in support of the MemberOf annotation.