Wednesday, November 18, 2015

Data Modeling - The True Meaning of Entities

When modeling data an entity refers to a unit that has properties which we are modeling. Some of those properties of the entity are intrinsic (natural properties) and some are extrinsic (externally applied/relative properties). If we model our entities such that the intrinsic properties belong to a root model (Person) and the extrinsic properties belong to subclasses of the root model (Employee) we can establish a proper representation of actual relationships of the entities in our model.

To illustrate, let's take a common example of modeling a person who is an employee at a specific company.

The person has some natural properties: Name, DOB, Gender, etc. These properties describe the entity in its base state. As an employee, the person may have additional properties that relate specifically to their state as an employee: id, email address, extension, location, title, etc. This person will also have some personal properties that may be interesting to model: email(s), phone number(s), address(es), family, etc.

If we are modeling the data as a relational model, none of the columns in the data tables should be nullable. Nullable columns are a clear indicator that the data can be further normalized and that it does not likely represent the entities accurately.

To achieve the goal of creating our model, we need to be able to create the proper relationships:

Person - Email (1:*)
Person - Address (*:*)

These relationships bring up interesting questions (and leave ambiguity in the model).

If someone has more than one address and one primary address is a requirement (assuming we are not modeling homeless), then how does a many-to-many relationship enforce the many-to-one relationship that must exist to model the persons primary residence?  Address may be either of two types: primary xor non-primary. We could set a bit flag to identify primary. In order to enforce the *:1 (an address can be primary for more than one person) constraint with the primary, we would need an FK on the Person table and a reference to the address table. In the *:* relationship above, how can that FK be constrained to the PrimaryAddress type? The answer lay in table-per-type (TPT). We want to get to this:

Person - Address (*:*)
Pesrson - PrimaryAddress (*:1)

To implement the TPT for this model, we would need an Address table a PrimaryAddress table and a AdditionalAddress table. The Address would contain the details of the address and the PK. But each typed table would contain an FK to the Address table which is also its own PK. The Person record would contain a FK ref to the PrimaryAddress. An additional xref table would be needed to link the Address table to the Person table in general, this would be a *:* relationship. This PersonAddress table can better represent the fact that more than one Person can live at the same Address and a Person may have more than one Address. The FK to the PrimaryAddress will enforce and show that the Person must have a PrimaryAddress and the 1:1 relationship between PrimaryAddress and Address will establish which Address is that Person's primary Address.

It is important to recognize the boundaries of the entity since any entity may serve as the root. It is equally important to establish distinctions between different types/classifications of entities. Here are a few examples of these relationships:

Person (base type) -> [Employee, Parent, Volunteer, Student, Teacher] (sub-types)
Contact (base type) -> [Email, Phone -> [Internal], Skype, Signal -> [Tree, Smoke, Call]] (sub-types)
Relationship (base type) -> [Friend -> [Best, Acquaintance], Family -> [Sibling -> [Brother, Sister], Parent -> [Mother, Father], Cousin, ...] (sub-types)

In this way we can establish meaningful relationships in the data model, while accurately representing the entities we are modeling.

Saturday, November 7, 2015

ASP.NET MVC RenderAction, Action

In attempting to render some popup boxes with data driven select lists into a layout (_Layout) I came across an issue. The layout was being called recursively each time the action was being called by RenderAction or Action html helper methods.

I moved them to a partial outside the layout and called RenderPartial from layout. This did not help. Nor did calling the Partial helper. After a bit of research, I found that I was returning a View which uses a layout page according to how the app was configured.

The fix was to return a PartialView from the GetDialog action. For sake of brevity, I set the return type of the method to a PartialViewResult. GetDialog looks like this:

public PartialViewResult GetDialog(string dialogName)

    var dialog = _dialogFactory.GetDialog(dialogName);

    return PartialViewResult(dialog.TemplateName, dialog.Model);


And the layout template like this

    @Html.Action("GetDialog", "Menu", new { dialogName = "NameFilter" })

Which renders a JQuery UI dialog to the output stream without the recursive layout calls.

Wednesday, October 21, 2015

Who is the Decider?

When it comes to decisions regarding software, it is generally the business who decides what needs to be done, when to do it, what will not be done, and even how to do it. There are so many decisions to be made, some requiring intimate knowledge of the business at hand and others requiring technical expertise.

When the development group is external to the business, and clear objectives are established in what is to be delivered, the lines between decisions that the business makes and the development company makes can be made clear by contract and/or convention. Conversely, when the technical team resides within the business, those lines can be a bit more blurry.
Through working closely with those in the business areas, who are intimately familiar with the working of the business, some technologists (particularly those working on applications used by the business) gain a deep understanding of the processes and value streams of the business. They can, therefore, be well informed partners in maximizing value through applying technological solutions in ways that enable efficiency, productivity, and even opening new revenue streams.

Careful and proper application of technology can help achieve these. Improper application of technology can hinder flow, agility and efficiency. It may end up costing the business dearly. Therefore, it is imperative to successful application of technology that technology experts are included in decision making, especially regarding matters involving application of technological solutions.

It may be beneficial even to have a few key technological resources involved in other decision making processes since there would be opportunities that evolve as a result of having technologically adept minds in the mix. Put another way, a certain portion of a board, committee, or other decision making body should be representative of technology (perhaps even representing different sectors of technology depending on the decisions and the business).

Saturday, October 17, 2015

Kanban, Can it Work Anywhere?

Kanban is a system in which cards are used to visualize a workflow through a value stream. Sure it finds its roots in manufacturing, and yes it has wound it's way into software development. Let's ponder for a bit whether this system would work in other contexts.

First, here is what we know about Kanban:

  • Not a process itself.
  • Supports a pull based system.
  • Enables visualization of work through a value stream.
  • Visualization enables measurement, which enables Kaizen (reducing waste).
  • Waste is downtime in the value stream.

Being a person who is either impatient, or who values efficiency - one activity that I recognize could use Kanban is the deli counter at a supermarket. I'll take a stab at applying Kanban and suggest how it might improve the process.

If you visit a supermarket deli, typically you would take a number and wait around for the next worker to help you with your order. You'll be asked what you need and they'll keep it in their head and usually have to ask a few times per order item to clarify. Most deli counters will take you a sample and ask if the thickness is ok. Perhaps they will work on one thing at a time and ask again what's next after each one until your transaction is complete.

If we introduce Kanban into this system, the first thing we need are order cards and customer cards. The orders would come in from the customer on an order card. This would contain information about each order item - item type, brand, quantity, thickness, etc. The order card would be taken by the worker one at a time and the customer would receive a corresponding card with a number on it. When the order is ready, it is delivered to the customer at the counter, the customer exchanges their numbered card for their order items.

But wait, I'm sort of getting ahead of myself here. We should not change the process just yet, but only use kanban cards to represent exchanges of information and goods in the current process. Let's try again -

First - customer grabs number kanban and waits until number is called. Once number is called, customer gives number to worker.

Worker passes customer an order kanban for the first item and a kanban for a sample. Customer gives worker first order item kanban and an order item sample kanban. Worker makes a slice of the first order item and exchanges it for the sample kanban. Now the customer either approves of the order, or declines and either changes the order or leaves.

If the customer approves (we'll look only at the happy path for sake of brevity), then the worker completes the order item. Once the item is complete, it is exchanged for the order item kanban. If the customer wants anything else, repeat.

It's easy for us to see that there are multiple opportunities for waste in this process. This is evident because the number of transitions at best are 5n + 2 where n is the number of items. For three items there would be at least 17 transitions. The number of times between transitions that the customer is idle are 2n + 1. The worker is never idle, however they are wasting a lot in transitioning.

One improvement would be to have the customer place the whole order, then pick it up later after they've had a chance to shop for other items in the store. Or the customer can have the whole order on some card with standard thicknesses and indicate whether or not they want a sample. There can be special instructions if needed. This would reduce waste by the worker and reduce lead time (where the customer is waiting).

In an even better world, where Kaizen and Just in Time is valued even more, the customer would receive their order JIT as they are checking out!  I would suggest placing the deli between the registers and entrance. Customers would stop by the Deli, get samples and place their order. When checking out, the deli items would be paid for by the customer, then delivered JIT bagged and ready to go into their cart along with other items.

This example serves to show how Kanban and other principles of TPS can be used to improve existence - no more wasting time at the deli counter. But this can be used to improve development processes as well as other IT processes. Wonder if it could improve the lead time on government initiatives?

Monday, September 28, 2015

Classify Work Items for Queue Order
by Steve Smith
taught me about a simple classification method which uses quadrants composed of urgent and important to identify how work items should be addressed.

Thursday, September 17, 2015

Good, Clean Code Helps With Error Resolution

Stack dumps can contain useful information about an exception. They can also be vague and misleading, especially if we have bloated classes and/or methods.

A stack trace can only go so far as to show which methods were called on which classes and in what order. Sometimes there is a line number but if not and we have a lot of lines in a specific method it can take a lot of guessing to find the culprit.

In .NET, for example, private methods are not included in the trace. Protected and up methods are. So, following good practices an improve usefulness of a stack trace.

Away With You Sprints!

Let's face it, building software is more like a marathon or a journey than it is a race. There are checkpoints, people need breaks to refuel (their brains and bodies), and working as fast as possible - all the time - will cause more defects and puts us all in a position to compromise (aka cut corners).

We're sending the wrong message with "Sprint". Let's stop calling an iteration a Sprint, and start calling it something more sensible. If we want to truly convey how we need to build software, I strongly suggest choosing appropriate metaphors in our processes. Sometimes we are on a journey or a tour or a mission.

We have a destination chosen before we leave. What way markers do we need to pass? Will we set certain checkpoints? We make a map. We have a mapmaker and a planning committee. They plan the journey and make the map. One of the committee is familiar with the terrain and can act as a guide. We have a guide. The guide may go forth on the journey or prepare the travelers before they go and guide as needed during the journey.

We have a few roles so far, and there will be more - we don't have as many people as roles, so some people will serve in many roles. They will be prepared to fulfill the duties of each role, lest the journey be a tragic one.

We move forward together as a group in a troop. We have a troop leader. The leader makes decisions that affect the group, but must leave others to learn as they go so that they too can be leaders. The leader must know how to make balanced decisions. The leader must let others lead in their own rights.

Occasionally, we need to send a scout ahead or down some path to the side to see if there is anything of value. We can huddle up and plan our next steps, then continue forward towards our destination or alter our course based on what is learned by the scout. As part of altering the course, we must consider the destination and how we will still arrive in the end.

We update the map as we learn. The navigator updates the map. It is helpful if the navigator is the scout and the mapmaker but not necessary.

We have a journal and a handbook. The journal is used to track daily activities and for lessons learned. The journal is updated daily. The leader updates the journal others may contribute. Each member of the group is encouraged to keep their own journal.

The handbook is a set of guides, principles, and best practices that we consult when confronted by a situation or an obstruction. It is created by or is a compendium of works by those who have experience in navigating many types of terrain. We use it every day, we learn from it, we train with it, every member must have a handbook and know its contents. It describes how to organize, how to plan, what to watch for, how to best deal with most situations. It is the most valuable commodity the troop can own.

The handbook is updated after each journey, or as needed. The handbook has information about how to update it. The handbook may be a subset of a full guide, in this case it would be a field guide. The full guide may be consulted during planning activities and the field guide/handbook during journeys.

The guide books may serve to help define and answer some of the most important questions. What criteria do we use to know if we need to abort the mission early? What hazards might we face? What if we come across an obstruction, can we pull together to clear it or do we need to call in a ranger? If we lose our way, we will need a ranger to help us back on track. Who is the ranger, who are the scouts, who has the map? Who does what? How do we...

There are rangers. There are different types of rangers. There are forest rangers, they are others within the organization who keep the forest healthy and the paths clear so that we may navigate. Occasionally, we may need to call in a special ranger. Special rangers are from outside the organization, they are called in to solve a specific problem that cannot be resolved by a forest ranger.

Training is second to only the guide book. We have training sessions, training missions, should we have badges? Each member must have the appropriate training before taking on a role. Each role must have its training requirements defined. Some journeys may be too hazardous for some members of the pack. The journey should be appropriate for the member.

 We have principles that must be learned, those principles are sensible and important to success, we proudly learn and teach those because they are integral to our way - it is an honor.

We stick together, we help each other, we help others, we uphold our principles,...