The Juice

the juice.png

I was recently asked (paraphrasing) what parts of the work of software engineering do I find “juicy” so I came up with this diagram. Any software engineering task involves both developers (if only me), customers (might be a client), and the processes of design and implementation.

The “external” blue lines are where the customer potentially interacts with the developers, the output of the design, and the implementation phase (you can probably imagine how Agile fits in this.) The “internal” red lines are where the developers interact with the each other and the design and implementation phases.

From a certain perspective, the left side represents the “process” and the right side represents the “results.” Process and results should be balanced – developers may discover they require training in new skills, teams adjust based on where the team is in the process, etc. The process creates results which the developer and customer team review.

The process – results flow iterates with each result. The earlier results are produced, the better for everyone because this is where “education” occurs, for example, the developers learn more about the customer’s requirements, the customer may refine their requirements (or change them!) Both the developers and the customers learn things during iterations which in turn create adjustments in the process.

The list of items within the boxes is basically just all the stuff that I find “juicy” – the more of those items that get checked off for a project, the more excited I typically find myself regarding working on the project.

D-Tier Development

Coining a buzzword (if it hasn’t been coined already), n-tier development is in the past.  D-Tier development is where we’re moving to.  The “D” can mean either “distributed” or, more in line with what I’m thinking, the ‘d’ in the word “multidimensional”, or simply “Dimensional.”

Why?  Because in an n-tier system, we still think of it fairly linearly: back-end, middle tier, and client-side, as one example.  OK, each tier may be implemented on a physically separate system, but doesn’t need to be.

A D-Tier implementation consists of autonomous entities distributed across a variety of physical and virtual platforms and interconnected in multidimensional ways.

Another aspect of D-Tier development is the highly “dynamic” nature of a distributed, autonomous entity architecture.  Entities can come and go, providing a continually changing environment of behavior that is tailored to the user’s needs.

  • Distrubuted
  • Dimensional
  • Dynamic

Start rethinking your application development in the D-Tier paradigm.