S.A.M. - Sensible Assembly Methodology Bylaws

[ SAM Home ]

Sensible Assembly Methodology (SAM) Manifesto

Sensible Assembly Methodology Bylaws (with descriptions)

Objects are behavioral in nature

Objects are 'intelligent' - they interact with one another

Object model an application's business domain, business rules, and business services prior to development using "object think" principles

The "business domain" consists of all of the objects that must exist in order for the process being modeled to exist and function in the real world
Object Think is based on the practice of object personification - achieved by first-person think (anthropomorphism). It results in localized decision making and data persistence within objects
Object Model a domain by imagining its entities as active, self-aware objects that interact with each other and are capable of performing complex actions
Turn information about a real world entity and the actions performed on it into the responsibilities of the object
The easiest way to scope an object's responsibilities is to become that object in your mind – adopt the 1st person

The idea of central control is against the rules of "object think"

Objects "think for themselves" - they do not require (impersonal) central control
Objects will become dependant on central control when it exists
A central controller is not the same as a central coordinator - an object that coordinates and/or enumerates the actions of several other objects, which is allowed by the rules of object think whenever the business domain dictates that an object of that type is responsible for coordinating or being aware of other objects (see the FAQ for more)

The goal of an object, above all else, is to be composable

Objects can be extended, modified and/or made to interact with other objects in order to achieve goals with little effort
Objects lower in the inheritance taxonomy are always more specialized
Object capabilities do not vary by context - apples are apples and oranges are oranges.
The validity of an objects construction can be measured by how easily one developer can break it down into its various methods and how easily another developer could reassemble those methods

The goal of SAM is for applications to be composable

Applications are made by distributed cooperation and communication between objects
The presentation tier in an application is made up of calls to encapsulated modules that know how to create and/or "talk" to business domain objects
The validity of an applications construction can be measured by how easily a developer can disassemble it into its various components and how easily another developer could reassemble those components or replace them with alternative components

The goal of SAM developers is to transcend formal process

SAM developers achieve a high level of expertise in thinking like objects in a domain - such that it becomes second nature. Ultimately, a one-man development effort or one where all of the team members have mastered anthropomorphism and the business domain at hand, development does not require any diagramming or documentation - what to do is intrinsic "common sense"

SAM does not encourage formal development processes - it encourages aformal development

Applications and objects are evolutionary, not systematic and ordered

Implementing business domain objects should require as little knowledge of their internal workings as possible

All domain object functionality presents itself via an API

Business logic and data that only need to be accessible to other objects are exposed via methods exposed to those objects
Business logic and data that is required for the UI is accessible through an object's API - made up of reusable presentation tier components

Paper Prototyping and Semantic Net Diagrams are the most effective means for modeling and determining objects

Semantic Net diagrams are a brainstorming tool for identifying objects and their relationships. Begin diagramming by writing down everything that may be an object - you can remove objects and refine the diagram afterwards
Use paper prototyping to describe objects (large post-it notes then ultimately index cards):

Who am I (my name)
What is my purpose (my reason for existing in the domain)
What am I aware of (the domain objects and data that I am able to access)
What I am responsible for (what I must do in the domain)

Lifecycle development is an agile process but prior to development, first determine why build, what to build, and how to build

How needs why to define its scope and what needs why to define its purpose. – the how of what is why

Domain expertise is the most valuable asset when deveoping an application

Not understanding the real world environment being modeled results in failure and the creation of unnecessary objects and/or objects that are not an accurate representation of real world domain objects

Programmers are artists and anthropologists - they employ anthropomorphism and creativity when performing their tasks

Better tools are never a replacement for better developers, and great software begins with great developers, not great tools. Creating software means much more than just solving problems; it requires developers to breathe life into their creation. As much as modeling the domain is an essential and fun process of discovery, well-written code is a thing of beauty to the developer who wrote it.

Prior to writing code or modeling the domain, gather requirements and obtain understanding (expertise) of the domain from the client and other domain experts - the architect must understand the business domain as well as the experts who use it on a daily basis

Ask them to describe what they want or what the application must do in 1 sentence, then ask them to describe what they want or what the application must do in 4 sentences or less, then ask them to describe what they want or what the application must do in 4 paragraphs or less. Start vague and get more specific from there
Ask them who will use this application and what the application must do for these users - understand what they will use the application for. Speak to these users if at all possible
Determine ideals and limitations regarding the deadline (time) and budget (money)
Ask about any other requirements - try to understand possible future requirements

After the initial requirements gathering, create use cases and stories, prototypes and wireframes... discuss these with the client and other domain experts. Only then can a developer hope to understand the domain

Create use case documents or diagrams with plain text and/or simple UML - it's not important how you represent this information so long as you do so in a way that is easily understood by all
Wireframe on paper or with a wireframing tool - wireframes offer a simple representations of an application UI in order to understand flow. Wireframes do not concern themselves with esthetics
Create prototypes of the UI (HTML, Flash, Flex, etc.) - the finished product will look and behave exactly like the prototype(s) but with code driving the display

Get client sign-off on prototype(s) and wireframe(s) before development

Any change or additional requests during the development lifecycle, if not in the prototype, are made part of the next phase of development
If change/mod requests cannot wait for the current phase to complete, they require contract and requirements modifications and require making adjustments to timelines/deadlines

Business objects do not display the UI

Object methods are data-in and data-out. It's a best practice in most situations for CFCs to not output to the screen. In the event that CFCs are used to generate UI, the methods that output UI elements belong in objects seperate to the business logic tier CFCs which store the data that they require

The presentation modules in an application are encapsulated and parameterized, and are capable of building whatever resources they need that were not passed

User Interface (presentation tier) modules should be completely encapsulated - data and/or objects are passed to them, and they behave/display accordingly.
Presentation tier modules are capable of constructing whatever objects are required but not passed, often times based on other data that was passed.
In a ColdFusion application, Custom Tags are best suited for encapsulating UI components.

Maintenance and extensibility are the developers primary concern

Software maintenance accounts for roughly 80% of software cost. Optimizing application performance via hardware is cheap and modifying a system code base for performance is easy - developing the right objects and functionality the right way is what's more difficult... and is what determines success or failure. It is easy enough, especially in an agile environment and especially with ColdFusion, to address performance concerns later

Writing software is an art - developers that strive to create the best software possible will enlighten their manager(s) about the art and will help them to understand what environment is optimal for their creativity

Creating great software requires a terrific amount of creativity. The conditions, rewards, and environment that make a developers talent and creativity peak differs from developer to developer. The sooner a manager realizes and is sensitive to this, the sooner they will manage the successful creation of software.

SAM developers recognize that the idea of "right" and "best" are relative and that there is always room for improvement. They question all things and strive to improve themselves.

Everything that we, as developers, think and do has been thought and done before. There is almost always at least a half-dozen possible solutions to any problem... and what's right today can easily be wrong tomorrow. Nobody is perfect and SAM developers always look for alternative ideas and methods for accomplishing their goals. We can only get better by questioning everything - especially that which we consider "best practice"

Place functionality as close as possible to the data that it requires to do its job.

If the data that a method requires is not in the same object as that method, the method (or data) is probably in the wrong place.

Encapsulated objects with encapsulated APIs are building blocks upon which any application in any context, can be built with little effort.

Objects that are self-aware, encapsulated, and that have a well-defined and encapsulated API for their use, are able to fill a specific role in any application with little or no refactoring.
Applications created by the interaction of intelligent objects are, by design, easier to maintain and more quick to build.

Do what works.

SAM is a set of guidelines aimed at helping developers create better applications.
There is no core set of files - developers build their own set of core objects and APIs, which they may reuse and/or modify from application to application.
If a rule doesn't work for you, or you have a different preference or idea, by all means do whatever works for you - there is no "wrong" way to use SAM, so long as you create your business domain with intelligent behavioral objects