TMD Process Tools

The TMD Process Tools

The TMD Process Tools represent the core principles of The Modern Developer (TMD) philosophy.

**The processes that are represented within the TMD Toolbox Process Drawer are:**

The goal for the TMD Process Tools is to demonstrate how the integration of the Development Processes (3) within the Agile Sprint Iterations (1) can be used to create the Semantic Model Architecture (2).

The delivered products created by the Development Processes (3) should comply with the Code Standards (4) and Design Principles (5) that are based on the Business Transformation Processes (6).

TMD Agile Method

The “Agile Methodology”, for the Modern Developer, is a set of proven processes, business and delivery guidelines, development models and best practices.

It is based on the contributions of Robert Martin and other members in a 2001 development conference in Utah as an alternative to the traditional “Waterfall” process.

This baseline for business technology solution development implementing the Agile concept was first introduced in 2002 through the publication:

Agile Software Development: Principles, Patterns, and Practices

There are Countless Ways

… of Achieving Positive Results using Agile Methodologies

…. TMD Agile is One of those Ways, but not the Only Way

TMD Agile’s processes and guidelines are always designed to the specific culture, climate and requirements of each Client’s business requirements.

TMD Agile Is Not a Template Boilerplate Model
It is a Road Map for Business Technology Success

The Agile Series – An In-depth Fulfillment Methodology

TMD Semantic Model

What is a “Semantic” in Web n-Tier Architecture?

The TMD definition of an Architectural Semantic is:

“The Representation of a Domain Entity rather than the Domain Entity Itself”

The “Semantic” of a concrete implementation is generally non-temporal but the implementation of the universal idea, the Semantic, will change over time.

By designing to a set of Universal Business Domain Semantics rather than Business Domain Requirements, that are defined in a single point in space and time, we are able to manage the delivered results dynamically over time.

This concept was spawned by the study of how HTML 5 was developed.

Tens of thousands of existing Web sites were studied for their structure and delivery framework.

The result of that study was that even though the sites were radically different in their mission and delivery mechanisms the overall structure could be defined with just a handful of common “HTML 5 Semantics“.

These semantics could define the implementation of almost any modern Web page through a Logical Semantic Web Page Flow Chart.

The Modern Developer’s Semantic Web n-Tier Architecture is a paradigm shift in design.

It is based on the concept of defining the functionality of the architecture in terms of a Business Vertical’s Domain as Industries Common Semantics and not by the information the solution processes at any given point in space and time.

This concept is not the Software Development Industry’s “Semantic Web” as defined by the W3C in 2001 and updated in 2004.

Semantic Design Series – Transforming the Modern Web

TMD Development Process

The Modern Developer’s Sprint Code Development Process enables the Scrum Master to ensure that the product developed produces the highest value to the Client at the lowest Total Cost of Ownership (TCO).

The highest level of quality is accomplished with a Three Stage Code Review Process.

The first stage validates the high level Design Objectives defined by the Acceptance Criteria.

The second stage validates that the Development Team is using the TDD Process with Mocked or Stubbed Dependencies and are complying with Code Standards and Best Practice Design Principles.

The third stage partners the QA Testers with the Development Team to validate that the developed code meets the Acceptance Criteria based on the QA established QA Objective.

The Three Development Code Reviews:

Sprint Architecture

The Internal Design Review – Validates the understanding if the requirements of the Sprint User Story after it has been decomposed into Sprint tasks.

This review looks at risks to legacy code and exposures to possible integration issues along with defining dependencies and database requirements that are known at the time.

The Delivery Review – Validates the initial Code Development in the Development Environment.

The code is validated within the Test Assembly as true Test Driven Development (TDD) code.

The tests are true Unit Tests that consume Mock and Stub dependencies.

The code have “Happy” and “Sad” path unit tests that validate all know error conditions and exception possibilities.

The code have moved through the RED, GREEN and YELLOW stages of TDD.

The Code complies will all Code Standards, Design Principles and Project Design Patterns as the YELLOW stage of TDD.

The Integration Review – Validates the developed Code development in the QA Environment.

The Unit Tests are copied and placed in a Code Region with the “IGNORE” attribute to prevent them from executing during Continuous Integration builds and Smoke Tests.

They are available for bug resolution and new feature / functionality requests but do not add redundant overhead to the Automated Testing process.

The original Unit Tests dependencies are replaced by System dependencies such as Databases, Data Services and Cloud Services.

The tests are striped of any “Asserts” that validate the creation and initialization of the Act result as to prevent validation of the Objects ability to be consumed as the Unit Tests already validated that.

The criteria for acceptance of the code base is the successful execution of the QA Objective.

This objective consists of the QA Teams Test Suite, Test Cases and Test Data just as they will be validating it when passed to QA within the Agile Sprint Work Flow.

This process guarantees that the number of senseless bugs are found by the Development Team before QA as to allow the QA Team to spend its time and the Client’s money on finding issues that neither team thought of during development and QA planning.

Quality Management – The Code Review Process

TMD Code Standards

The Art of Software Development allows us to be expressive in our development.

As with any professional creative effort a level of freedom is important.

If the result of that expression is solely the responsibility of the creator, then the creator accepts all responsibility for the outcome.

When the outcome of the creative activity becomes a component of other creative works the creator’s expressive development should become a harmonious part of the whole creative result.

You have a responsibility as the Modern Developer to be consistent in your Development efforts.

To that congruent end is the intent of development coding conventions.

Coding Standards present a uniform approach so that a development team can feel comfortable in refactoring, when required to do so.

TMD Code Standards – Managing Cost with Standards

TMD Design Principles

Design Principles act as guidelines for communication of the intent of the developer to create software solutions that will benefit from decades of failed and successful projects.

By learning, accepting, promoting and complying with a collection of accepted premises, the developer enriches the entire Technology community.

The solutions he provides to his Clients will have a lowered Total Cost of Ownership (TCO).

New feature and change requests will be less expensive to implement.

The cost of Development and Maintenance will be significantly lowered.

The Design Principles Creates a New “Paradigm of Thought”

TMD Design Principles Categories:

Core – The Seven Principles of Thought

Code – The Five Principles of Actions

TMD Design Principles – A Road Map to World Class

TMD Business Transformation Processes

Supporting the “Winds of Change”

A company makes decisions to change direction generally to adjust to market demands and the global evolution in their key vertical markets.

The loss of market shares or the inability to capitalize on emerging opportunities drives the very difficult decision to make the move to a new paradigm.

Of the three primary areas affected by the paradigm shift, technology, new business processes and the financial impact, the greatest impact to the success of the shift is the impact on the company’s human resources: “The Human Element”.

Culture Change

Organizational Change Process

Change in one’s environment affects us as human beings.

All too often a company does not understand that as human beings the psychological effect of change plays a critical role in our ability to accept the changes that are coming.

Planning for Change from a Psychological Perspective

… Does NOT Constitute “Pop Psychology”

…… It Minimize the Adverse Effects of Change

All business transformations involve
people and people mostly react in predictable ways

Changes in one’s working environment can trigger the same grieving process that the loss of a family member or friend.

Hopefully the process of passing through the stages is less painful and more rapid than a family loss but the stages have been proven very similar.

It has been said:

“Grief is the process that allows us to let go of that which was and be ready for that which is to come.”

**In order to be ready for that which is to come one must pass through the stages of grief.**

+The Five Stages of Grief

1 – Denial – The Denial stage includes feelings of shock, numbness, and disbelief. When change first realized, some people have a hard time believing “this is really happening.”

2 – Anger – Anger can be expressed in a variety of ways. Anger at your co-workers, towards family members, at God for letting this happen at the worst time. The anger can even be expressed towards yourself for letting you be put in this situation.

3 – Bargaining – Taking actions that you believe will prevent or minimize the effect of the change will have on you personally. This can begin even before the change is formally introduced.

4 – Depression – A level of depression can set in if one feels helpless. If you feel that you have no choice but to accept the change then a natural reaction is some form of sadness that could reach the level of depression.

5 – Acceptance – The experience of “depression” is what leads to “acceptance”. Some people think that “acceptance” means we are “cured” or “all right” with the change. But this isn’t the case at all. Acceptance simply means we are ready to try the new changes and move on. This allows us to accommodate ourselves to this new way of doing things in a manageable fashion.

Holistic Change Series – Understanding Business Change

In Conclusion