The Problem

Fundamental Constraints

A primary difficulty in developing software stems from the fact that project success depends not only on the software developed, but on a greater software system of which humans are an integral part.  By humans, I'm not just referring to end-users—in fact, the creators of the software (the developers, QA people, product managers, etc.), as well as the customers of the system (which may be different fromt the users), play an integral role in the greater software system, and we neglect that to our peril.

Another primary difficulty stems from the fact that the success of this greater software system is dictated by invisible, yet fundamental constraints—highly interdependent and competing limitations, requirements, and goals, all of which are unique to the particular project.  Limitations are the minimal prerequisites for the greater software system functioning in any useful way—below the limitations, software does not run, users cannot perform functions of any kind, and creators cannot do their work.  Goals describe the upper constraints of the system, above which there is nothing better.  They represent theoretical perfection—perfection of the software, the user experience, the implementation, etc.  (Of course, complete attainment of these goals improbable, but they provide an aligning influence that is very important.) Project requirements are found somewhere in between, and they represent the minimal tolerances for success placed on the system.  You can always do better than the requirements and still succeed, but any worse means failure.

These fundamental constraints apply to both functional (or user-oriented) aspects of the system, as well as to the implementation (or creator-oriented) aspects of the system.  So it's useful to think about each constraint separately for both of these aspects.


  Functional (User) Aspects Implementation (Creator) Aspects
Limitations Functional Limitations:
The minimal functional limitation on the system is that there be some functionality.  The user must be able to accomplish something, anything.
Implementation Limitations:
The computer, the compiler, and arguably the operating system define the primary implementation limitations.  Basically, the implementation limitations have been met if the software successfully builds and runs.
Requirements Functional Requirements:
The minimally acceptable set of user functionality that meets the most crucial business, functional, and usability requirements, and which is implementable by the creators.
Implementation Requirements:
The cheapest, minimally working, lowest risk implementation that the creators can actually implement, whose architecture provisions support for the functional requirements.
Goals Functional Goals:
The optimal set of user functionality that is theoretically possible, anticipatory of future business requirements, intuitive and pleasing to use, and realizing an goal balance between power and simplicity.
Implementation Goals:
The best implementation of the functionality that is theoretically possible, being engaging for the creators, elegant in design, anticipatory of future changes, scalable in case of success, redundant in case of failure, secure, robust, etc.


Did you read the text inside the table? Yeah, right.  It's important! Go back and read it.

I'll wait.

Done? Okay, so you're probably wondering where all this is taking us.  Well the interesting thing about these constraints is that we can use them to literally draw a box around project success.  Read on.