Integrating a Blog

One of my friends and former co-workers suggested that I integrate a blog into my site. I've been thinking about that for some time, and at his prompting, decided to move ahead with the required changes.


Initially, I thought about integrating Blogger into my site, but at first this didn't seem feasible while maintaining a consistent look-and-feel. I tried to use WordPress but for some reason couldn't get an installation to work with my ISP. At that point, somewhat frustrated, I decided to look at Blogger again. After working through some on-line references, I was able to create a new blog and modify the template so that it would integrate with my site.


In the coming weeks, I expect the changes to ripple through Michael's Pen. For one thing, I've written a novel and would like to start talking about it. For another, I intend to make some of my other, shorter work available for others to read and enjoy. This will take some time, and I hope you'll check back often.


Cheers!

Calculating Baseline Energy Use

Now that you've collected a year's worth of utility bills and converted all your energy use numbers into consistent units (KWH, probably) you can calculate your baseline energy use.

Your baseline energy use gives you an estimate of how much energy the basic operation of your home requires when you subtract out seasonal effects. If you live in a warm, humid climate where you run an air conditioner for much of the year, your overall energy use will probably be dominated by cooling. Conversely if you live in a "heating-dominated climate", your winter months will show a significant spike in energy use. If you live in an area with great seasonal temperature swings (hot summers and cold winters), you may find that there are a couple of temperate periods in the spring and autumn.

Calculating your baseline is simple. Here are the steps.

1. Put your twelve months of bills in order. Again, it doesn't matter what the starting and ending months are, just that you have all the months in a twelve month period.
2. Total your energy use for each month. To do this, first convert all your energy use bills into one type of units (KWH is probably best). Then add the KWH's from each source to give you the total energy use for each month expressed in consistent units.
3. Identify the three lowest energy use months. Average these. In other words, add the energy use values for the three lowest months and then divide that number by three.

This number is a good representation of your energy use baseline. It tells you how much energy you use to run your lights, cooking appliances, refrigerator, hot water, entertainment and computer gear month in and month out.

If there are great differences between heavy energy use months and your baseline, you might want to investigate things like patching leaks, increasing insulation (by a large amount), upgrading windows and/or window coverings, and perhaps even looking at upgrades to HVAC systems.

We'll dig into this more in future posts.

Local Optimization

Managers at all levels tend to focus their attention on their own organizations. This makes sense. After all, a team manager is largely responsible for the productivity, output, staff development, and morale of their staff. It is the manager who is scrutinized if his or her team misses commitments – be they feature, quality, or schedule.

Plus, remember the essay on groups. Managers are also primates. They naturally assume the role of the alpha group member.

Still, there is great risk to the long term health of the organization when managers focus too much on their individual areas of responsibility. The best senior managers will reinforce the global view, the organizational view. Why is this important?

Senior managers must balance the natural tendencies of subordinates to optimize things to ensure local success.

Here are some possible artifacts of local optimization. Hopefully, you can see that these behaviors must be balanced by a strong advocate for the needs of the larger organization:

• Each manager is likely to try to interpret the schedule in such a way as to ensure that his or her team will meet its deliverables. Managers are likely to try to squeeze upstream schedules to get their dependencies delivered sooner. Managers are also likely to squeeze downstream schedules by padding their estimates.
• Specifications will be interpreted in such a way as to externalize accountability. Each manager will be very forthcoming with lists of dependencies on other teams. Those same managers will tend to soft-pedal their responsibility to deliver critical system components to other teams.
• Component interfaces will remain in flux. This causes change to ripple "downstream" through the system. The teams with the greatest number of true external dependencies, say localization or documentation or SQA, will see the amount of time left for them to do their work erode as end dates are enforced by executive decree while interfaces continue to change.

There are other examples, but you probably get the idea.

You should know that beyond its obvious implications for system integration, quality, and customer satisfaction, this tendency towards local optimization, if unchecked will weaken you as a senior manager. That's right. If you do not enforce commitments where necessary, your staff members will see you as weak and ineffective.

Those at the start of the dependency chain will make a habit of ignoring your statements on schedule commitment. They will habitually stabilize interfaces and upstream components late and this will frustrate those dependent on them. This visibly undermines your authority.

Similarly, those who have upstream dependencies may also decide that you are weak. They may also view your lack of action as evidence that you "favor the upstream teams" or (perhaps worst of all) that you either don't care or don't understand what's going on.

And of course the overall organization – the corporation whose success you are charged to foster – will suffer.

To counter this, you must visibly and repeatedly emphasize the global nature of responsibility. You must educate your staff members so that they understand their responsibility to the system. Explain the concept of Systems Thinking to them. Show them examples of how they and their teams are really operating within a product development ecosystem. Be patient and ask a lot of questions to make sure that you hear what they have to say.

But in the end, you must hold your staff members accountable for the needs of not merely their teams but also the needs of the organization. This may well mean that you'll have to replace one or more of your staff. While this can be painful, the alternative (inaction) is not viable for your company or for your own career.

Nice Introductory Video on Scrum

Recently I came across a YouTube video titled "Scrum in Under 10 Minutes".  I watched it a couple of times and came away impressed.  The creator, Hamid Shojaee, did a very nice job with this overview.  I recommend that you view Scrum in Under 10 Minutes for yourself and see what you think.  The video is even supplied in HD format.

Adiabatic Changes

In thermodynamics, we learn that most changes to a system are irreversible.  The entropy genie is let out of the bottle, and once out cannot be put back in.  Certain types of change, however, are reversible.  We call these changes adiabatic.

In an adiabatic change, the system neither gains nor loses heats to its surroundings, but I think that the concept applies nicely to software systems too.  Let's dig in a little bit and see how it works.

If we make large-scale changes to a complex software system -- especially a system that's being developed or maintained by a team of more than a handful of software engineers -- and those changes go wrong (i.e. the system fails its regression test suite), we must diagnose what went wrong.  Yes, if you are using a source code control system, you can simply back out all the changes that have been made until you restore the system to its last known good state.  I suppose in that sense, all software changes can be viewed as adiabatic.

But if you have multiple engineers involved, it is costly to back out everyone's changes and simply start over.  You could try backing out each engineer's changes one at a time.  We back out one set of changes and rerun the regression tests.  Does the system now pass?  If so, we might have a clue as to which changes caused the problem.

We might.

But what if it wasn't any particular engineer's changes that were at fault?  What if it was instead the interaction between changes that, taken individually were benign, but when taken together had a pathological effect?  Backing changes out one at a time, might not lead you to the right answer and might even mislead you.

On the other hand, if each change to the system is applied incrementally, we might be able to back the changes out without misleading ourselves.  So we emphasize incremental changes to complex systems. We emphasize incremental changes to local data structures. We emphasize changes that can be verified to have local effects.  We emphasize changes that due their incremental nature are reversible, adiabatic.

So we see that incremental changes to complex systems are easier to manage.  This is why I advocate phased development efforts. This is why agile methods work best (or at least easiest) on smaller projects involving fewer than 10 people: the changes are more often verifiable with regards to the propagation of their effects.  The changes do not cause the system to depart from its equilibrium (i.e. passing all regression tests) state.

Maintaining reliability thus becomes mostly a matter of sequencing a series of small changes and testing in between application of changes. While this cannot completely shield us from undesired interactions between changes, it will at least reduce their likelihood.  It will make most changes adiabatic.

The Delphi Method and Project Management

Spend some time studying software development models.  Fashions change and so do the sizes of projects and the sizes of the teams tackling those projects, so try to avoid getting too enamored with any particular model. Instead try to see behind the individual vocabularies and preferences.  You'll find that whatever they're called, software development models are really risk management activities.  It matters little whether you're looking at Boehm's 1988 paper about the Spiral Model or a new video posted about an agile development model.  In the end, the project manager is using various tools and ideas to manage risk in a software development project.

The artifacts of the various models are good and interesting.  The "Burn Down Chart" from Scrum is appealing to some.  The feature set lists and "Progress Bars" from Feature Driven Development are also attractive.  All will probably work -- if you use the procedures wisely and have good work estimates to begin with.  If you  have good data, you can extrapolate to see likely end dates.  If you have good data, you can see which teams are struggling and try to move work around to make things better.  

To the extent that your work estimates aren't so good, your artifacts probably won't be either.  If you keep good records and manage to survive for a few years, you might be able to get some mean productivity measurements for your product development teams.  These could be useful (if your staff turnover is low) because project decomposition into functions, features, objects, or whatever building block your organization uses will probably be done by a slowly changing set of staff members.  If you keep records and count the number of building blocks completed per engineer per unit time, then for future projects you can use that data for rough schedule estimates.  

If you manage to survive, you'll be able to refine your building-blocks-per-unit-time estimates over multiple projects and multiple years until -- for your teams, anyway -- they might give you some useful estimating tools.

But what do you do in advance of that?  How do you obtain estimates that are credible and reasonable before you have historical data for your teams?  You might consider some variation on a Delphi Method.  (Note: if this link goes bad, please Google some variation on "Delphi Method" or "Delphi Process" to find another paper describing it.  There are also wikipedia articles on this method.)

Delphi Method Summarized:

In any viable development organization, you must have some subject matter experts.  If you don't, well, you're going to have trouble developing viable products, so let's assume that you have two or, better yet, three subject matter experts (SME's) on your team.  Here is a quick summary of the Method:

1. Initially, each SME, working independently, develops a work estimate -- a forecast.
2. Each SME expresses her/his forecast in a specified manner, e.g. via a form, and submits the forecast to the project manager or other Facilitator.
3. The Facilitator combines and summarizes the individual forecasts, preserving anonymity while identifying areas of disagreement and important details.
4. The SME's are convened as a panel to discuss the summary report, ask questions, etc.

The process then restarts at the top and goes through all the steps again.  Iterations continue until a consensus is reached or until the project manager feels that the process has converged as far as it can (in which case the project manager will have to make the final call).

The key to the Delphi Method is that each SME operates independently while developing his or her forecasts.  By combining the forecasts, we assume that we'll end up with something that at least represents some varying points of view.  By letting the Facilitator synthesize the results, we avoid the situation where a dominant personality exerts excessive influence on the process.

Once you have work estimates for your project, you can apply them in whatever development method you choose.  Again, keep a record of actual "burn rates" of features.  If you have several developers working on several projects, you will eventually develop some baseline productivity data that will be valuable in subsequent projects.  Even if you continue to use the Delphi Method to develop work estimates, your historical record will be extremely valuable as a sanity check.

Groups

TPW, a very intelligent friend of mine, has wide ranging interests. One area to which he often returns in his recreational reading could be termed "primate psycho-biology". Even though I've not read nearly as much on the subject as TPW, I have stumbled across a few concepts that apply to management. They explain so much about behaviors we see in the workplace. Humans are, after all, primates.

Now, primates form groups. This seems to be a basic behavior. Perhaps we are programmed at the DNA level to form groups. It is not difficult to visualize roles the group could have in the selection (or de-selection) of traits. After all, banishment from the tribe practically guarantees that one's genetic material is not passed to subsequent generations. Thus, the psychological drive towards membership in a tribe or group is very strong.

One important part of a manager's job is to direct the formation and maintenance of groups that benefit the enterprise: We, the employees of this company, are a special group -- The Tribe. We must prevail. Our competitors are other tribes. The herds, the land, the business environment cannot support us all. They must not prevail. Our survival depends on it.

A difficulty with all this is that the primate group formation drive is constantly active. Also, we tend to form hierarchies of groups: our family, our community, our region, our country... So we may subscribe to the notion of the enterprise as a group, but without careful guidance from our managers, we'll also form local, atomic groups that center around our individual work teams and closest co-workers. So the QA department has a group identity that is distinct from that of the Technical Writing Team. Both of these identities are distinct from Marketing or Development.

Through inattention, careless managers, may allow local group identities to impair cooperation and flows of information between teams. Ambitious managers may exploit group identities as part of a strategy of self-promotion. In either case, the enterprise is harmed.

Wise managers, managers who truly care about the health of the enterprise, will accept their teams' local identities while consistently channeling those identities in constructive directions. Wise managers will always refer to other teams respectfully. Wise managers will encourage cooperation and mutual support among teams and, most importantly, will visibly embody that cooperation in their public dealings with their own peers. Privately, managers may argue and negotiate. They should test assumptions and plans rigorously and strive to develop the strongest strategies. Publicly, however, managers must themselves be active members of their own group, their own team.

So we use the basic, group forming drive to establish a work identity that is comfortable for our employees and healthy for the enterprise. We discourage group behaviors that are unhelpful. This is not so hard, but it does require conscious behavior on our parts.