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,...

Friday, September 11, 2015

How to Load Text into Html from a File

When creating a "static" page with some informational text, it may be helpful to enable admins to replace the text without editing the main html page.

This can be done by using an Ajax request to load a text file or preformatted html file into the innerHTML of an element.

JQuery.ajax can be used to fetch the file then write the contents to the page.

        $('#elementId')[0].innerHTML = '<pre>'+ data + '</pre>';

with this approach, the textFile can be marked up with plain html tags and it will work without the need to escape them.

One thing to note about using this approach is that the file should be available via the web server and at a path relative to the host site, this would avoid additional configurations - just let the same web server serve up the textFile.

Basically, in this way you can have a wrapper and put the content into the wrapper however. Sort of a way to do an SPA.

I'd you'd like, set the pre CSS to wrap the lines. As an alternate to appending pre tags, you could style the parent element.

More information about that -

Friday, September 4, 2015

What is Void?

We cannot define void in terms of what it is, only in terms of what it is not. Void is that which is not everything else. If everything else exists, then so must void. Void and everything else are like the Yin and the Yang. Void is not a number, it is not a char, it is not the air or the sun, it is not made up of the stuff that makes everything else, however void exists because know it. Perhaps it only exists in our minds.

Speaking of void and everything else, what is everything else really? Is it that which we see, hear, taste, experience? Or that which we can experience? We see it through a small window as it flashes past. Or perhaps we can think of a computer screen on which everything scrolls by. We cannot control the scrolling, only what we choose to witness. The void is there all along, it is where we do not see.