Leaderless Group Politics

I have no problem leading, or supporting, or even sitting on the sidelines, but what I hate is group politics with no one I can depend on to act as coordinator.

Let me tell you a story that illustrates this.  Long, long ago, in a place far to north three business professionals where travel to a business meeting.  As far as their positions in the company there was a very clear line of responsibility between the, but it also turned out that they were friends.  So outside of the meeting itself they acted pretty much like friends on a road trip.  No one wanted to hurt anyone else's feelings, and everyone fairly complacent with where they went to eat.  So as is common in such situations the conversation begins: "Anyone care whether we stop and eat or just head on to the office?"  There are then lots of "whatever is fine", and "I am fine either way".  Slowly someone mentions that they are a little hungry, and the conversation moves on to "I am fine wherever you guys want to go",  "I don't care either", "Anything look better than anyone else?", "I am fine what ever" and so on.

Well, it turns out that I often have a little preference, and I know that everyone else does too.  I figure that is why everyone is so noncommittal.  Well, anyway in this story, one of the businessmen spoke up and said something like, "I would actually like to go to Restaurant A."  So magically the car begins to turn toward Restaurant A.  The other businessmen find the choice of eateries a little out of the ordinary, but perfectly satisfactory.  To make a long story short, the businessman who made that suggestion was jibbed and teased for the next three days.  You know how it goes, "Oh don't ask so and so, we'll end up at Restaurant A again."

You know what?,  Let me tell you another story since this is my soapbox.  There was another place and another time when a small office was working late, and the company wanted to buy dinner for the office.  As locations and types of food were discussed nobody has any strong suggestions until someone suggested something, and suddenly half the other people in the office didn't want that.  So after literally hours of working and haphazard discussions about where to eat or get food, the members of the company began to finish up and head home.  Eventually the company bought dinner for 2 of the remaining 5 employees, and everyone had to stay later just to wait for the food to arrive before anyone dared to 'abandon' the rest of the team and go home.

I am sure there are social names for this phenomenon, and I am sure it is very fascinating to study, but I hate being in it.  Now don't get me wrong, I love working in teams, and collaborating, and brainstorming, and all those team activities, and I believe that in software development it is more enjoyable, and far more productive to work in a good team.  What makes me grind my teeth is when everyone is too afraid to make a suggestion, but when someone ponies up with an idea suddenly everyone has a descenting opinion.

Version Control Branching and Versioning

In a VCS (Version Control System) there are some basic concepts that I am not going to cover like check out, merge, update, etc.  What I am going to rant about is how and when to branch/version, and what the different type of directories are for.  Also, please note that these are my ideas, and may not be held generally.  Also, please note that I have over ten years of experience with VCS including CVS, SVN, and Bazaar.

In simple terms each 'project' has a base directory.  Inside of that, among other things, are three VCS directories: trunk, versions, branches.  (You will often see some repository specific files here as well, but you should be able to ignore those for general use.)

trunk - This is the 'home base'.  All new significant branches come from here, and all production features get merged into it.  It is possible to have features that only exist in branches, and some of those may actually be deployed and used in 'production', but if they are not merged back to trunk they are not considered part of the core code.

versions - These are production snapshots that are 'released' or deployed into a production environment.  Once a version is created it should only be updated with bug fixes and minor release.

branches - These are temporary copies of the version or trunk.  Here the work is actually done and tested before the code is pushed back to trunk.

Aside:
- bugs that 'escape' into a production release should be 'patched' onto each and every 'supported' release, and then applied to trunk.
- I am only addressing the major / ideal events here.  There are some very complex and subtle interactions that may occur between branches, version, and/or trunk.

To explain my preferred way of versioning and branching I am going to use a completely manufactured, but common, example situation.

In this example a software company has an application.  The application is large enough and has enough developers working on it at any one time that it would create confusion and major confilcts if not handled properly.

This company is preparing to create a new version of their software.  It will be the fifth major release of their software.  So first, trunk is branched into something like branches/5, branches/v5.0, etc.  As time goes on new tasks are branched from that or from trunk itself.  Where they are branched from is completely dependent on what release they are target for.  So, a developer that has added some functionality to be released with version 5 would branch branches/5 into a branched named something like branches/5-QuickInventory, branches/5-13235, etc...  At the same time a developer might be assigned to develop a feature that would go into some future release.  That developer would branch trunk into something like branches/RestInterface, branches/11564, etc...

As tasks/branches are competed they are merged back into the base from which they started.  Once all of them are merged in the base, branches/5 in this case would be merged into trunk and either moved (or re-branched from trunk) to become versions/5.

1. Project Created: /projects/falcon
2. VCS set up: /projects/falcon/trunk, /projects/falcon/branches, /projects/falcon/versions
3. Major Release Cycle
1. Version identified
2. /projects/falcon/trunk branched to /projects/falcon/branches/1.0
3. /projects/falcon/branches/1.0 branched into development branches:
1. /projects/falcon/branches/1.0-100
2. /projects/falcon/branches/1.0-101
3. /projects/falcon/branches/1.0-102
4. development branches merged back into /projects/falcon/branches/1.0
5. /projects/falcon/branches/1.0 merged back into /projects/falcon/trunk
6. /projects/falcon/branches/1.0 moved to /projects/falcon/versions/1.0
4. Maintenance/Minor Release Cycle
1. /projects/falcon/versions/1.0 branched into /projects/falcon/branches/1.1
2. development branches created:
1. /projects/falcon/branches/1.1-234
2. /projects/falcon/branches/1.1-237
3. /projects/falcon/branches/1.1-238
3. development branches merged back into /projects/falcon/branches/1.1
4. /projects/falcon/branches/1.1 copied to /projects/falcon/versions/1.1
5. /projects/falcon/branches/1.1 merged back into /projects/falcon/versions/1.0
6. /projects/falcon/versions/1.0 merged back into trunk

Goals:

1. Always be able to build every 'supported' version at any time.
2. Prevent features (code) from being lost.
3. Prevent code regression

Spiritual MMO

Foundation Premises:

• Daily activities produce short term and long term benefits
• constructive activities build positive power - destructive activities build negative power.
• personal power enhances community power - community power enhances personal power and national power - national power enhances community power
• helping / interacting with / grouping up with other people produces synergy effects
• 
  

Entities and Proxy Objects in Hibernate

I would like to attempt and very simplistic explanation of the various states in which a JPA entity can exist.  I am going to consider this from my perspective using Hibernate and EJB 3, and other implementations may vary in some ways.

It is not my intent in this post to explain Persistence Contexts, Entity Managers, or any of the other numerous technologies involved.  I am simple going to give some insight in the states of entities and some thing that Hibernate allows you to do manage the state.

First of all a JPA entity is a managed object that is backed by a persistence store.  Meaning that the object can be 'saved' and later retrieved.  In EJB 3 the entities are POJOs annotated with @Entity.  In theory this is the simple part.  It becomes a bit more complex in implementation because of caching, lazy-loading, and detachment.

I am going to use three objects in my examples: Location, Store (which extends Location), and Suppliers (a Store has many Suppliers), and all relations are considered bidirectional.

Loaded

When an entity is managed by a persistence context it is 'loaded' into or 'managed' by that context.  The opposite of 'managed' or 'loaded' is detached.  There are two ways to get an entity in the 'loaded' state. (Please note that a Persistence Context is generally accessed and manipulated using an Entity Manager. I am going to refer to the theoretical context and ignore those implementation details here.)

1. look the object up from a Persistence Context
2. merge the object into a Persistence Context

Once you have a 'managed' entity it can be either a 'real' entity, meaning you actually have a Location for example, or it could be a proxy object that extends Location.  In either case you still have a 'managed' or 'loaded' object.

One thing to be careful of is that when you get a proxy object you know what you have.  For example if you retrieve a Store from the data store you might actually get a 'location proxy'.  A location proxy will have all the methods available from the Location, but it will not have any Store specific elements.

Initialized

To facilitate the lazy loading and caching the objects have a concept of 'initialized'.  An object that is 'initialized' can have all the getters and setters relevant to the Persistence Context called.  If you have a Location object and it is 'initialized' you can call getStores(), but those objects may not be initialized.

The Fire-breather

This writing is an attempt to glean and share some of the things I have learned while working in and around very difficult situations. You might immediately associate this story with someone in your life, or you may not know know anyone like what this describes, but I know that everyone faces difficult challenges in their relationships with other people, and I hope this will help you turn hurtful relations into productive ones.

A Note to the Camp Director

In some fantasy worlds there is a dragon that breaths a poisonous and sometimes flammable gas which is commonly called chlorine gas. This gas is poisonous to living creatures, but only burns when exposed to open flame. I explain this only because I would like to use these properties in a short allegory to explain a certain complex challenge that is difficult to understand and even more difficult to explain.

The main character in this story is a man, Jim, that has a very strange trait: he exhales chlorine gas when he talks. This man lives high up on a certain mountain among a small group of family and friends that understand him, and have learned how to protect themselves from the gas. It also turns out that the semi-isolated life of a mountain man is very enjoyable to Jim.

On this mountain there is also a summer scout camp, and every summer for as long as anyone can remember Jim would be a councilor and guide to the scouts at this camp. The other councilors learn very quickly about Jim unique breath, and learn to protect themselves and the scouts from too much exposure. The scouts always throw and endless stream of jokes and jibes at him, but he doesn’t seem let them bother him.

While normally this danger would be unacceptable it is tolerated at this camp because of his knowledge of the area and the wild life and he has saved many lives over the years. He knows where all the dangerous cliffs and canyons are. He know where the bears live, and how to protect against them if they are going to be extra aggressive. He also has a powerful ability to teach respect for the forest, other scouts, and yourself.

From time to time a new camp director will be assigned to this camp, and will quickly learn of Jim. Some have immediately expelled him without understanding him, some have embraced his knowledge injected him as close to the scouts as possible, and some have put him up on a tower where he can teach without danger to those around him. Needless to say, Jim creates a very difficult conundrum.

Perhaps you have now become director of this scout camp, and have to figure out how to use or eliminate this challenge. Perhaps you are a fellow councilor or a scout. But, before you make your final decision on how to react to him I would like to introduce myself. I have never been the director of a scout camp, and I may not fully understand the pressures you are under. I am a camp councilor, and I like to think of myself as a good councilor that cares about the scouts, the camp, and the forest in general. I have been a councilor here for several years, and have seen a number of approaches to handling Jim. I have been around Jim enough to have seen and experienced great suffering because of Jim’s breath, and I have seen that same poison save lives repeatedly. I have seen how that breath offends and hurts anyone close enough to catch a smell of it, and, I have seen that breath kill on at least two occasions. I, myself, was nearly killed by it. But, I have seen that breath ignite wet frozen wood to save the lives of scouts caught in a late snow storm. I have seen that breath ward scouts at night by chasing off bears, skunks, and numerous other dangers. Essentially I would like to help you understand Jim for both his good and bad. I hope you will take a moment and consider my experience and proposal:

The Breath

First I would like to consider Jim’s breath. Most people first meet Jim by hearing one of his firesides stories, or by attending one of his trainings. And, most people are at least intrigued by him if not entirely captivated. In these situations the organizers of the fireside or training have insulated the audience from his breath so there is little or no chance of experiencing the hurtful affects by attending these events.

Even when a person meets him face to face they may not notice or understand the minor effects that the gas can have on them. It is when a person begins to work with him closely that they begin to suffer more and more of the effects of the chlorine gas. Even then it is difficult to identify the cause of the pain, and still harder to identify its source. But, eventually it becomes clear, and most people will experience very hostile feelings toward him. By the time it is identified many people have already suffered irreparable damage, and, like I mentioned before, I have seen at least two people entirely leave the career field that put them in contact with him.

On the other hand, there are a lot of people that only work with him marginally, but close enough to see him work some very astonishing feats, and as long as they aren’t directly around him enough to suffer from the gas they will do everything they can gain and retain his talents.

Neither of the two extremes is useful because they will both collapse eventually. Either a person will suffer until they can’t take it any more or they will eventually find that the astonishing feats have as much chance to explode as to produce useful effects. For this reason we need to examine this gas. Only when we understand the gas can we make a fair assessments of its value and danger.

First we have to understand that Jim cannot entirely control his breath. He can for short periods of time hold his breath or divert it away from other people, but it requires a great effort, and he cannot maintain it for very long. So the idea of getting rid of it are only going to delay the problem.

Second we have to understand that the chlorine gas is more than just a trait, it entirely defines him from the inside out. It is the gas that makes him special. It is the gas that has saved his life and the lives of those he loves. It is the gas that has given him the things that he treasures most. Without the gas he would feel that he has nothing to offer. Without the gas he would have to entirely rebuild his self-worth and self-esteem, and without the gas his spirit would likely be broken robbing him of the ability to rebuild. At the same time he is only vaguely aware that it is his very breath, his life force if you will, that causes the suffering he so often sees around him.

What we have to understand from this is that we cannot separate Jim from the gas. First of all it would kill him, and secondly it would destroy spirit and his will. So lets examine the properties of this gas to see if we can turn it from a liability into an reliable asset.

The Gas

This gas, first of all, is invisible to our eyes. As much as we want to see it we can only ever see its effects not the gas itself. It has a definite smell that is accompanied by irritation, but it is difficult to identify. We are simply not capable of following a smell like we can follow a light or even a sound. It is not flammable by itself, but it often enhances the flammability of other things. In extreme case it can even facilitate an explosion.

With this understanding we can see how it would be useful in repelling unwelcome visitors (like bears), and if used at the right time it can guide scouts without leading them by the hand or actually lecturing them. It can also be used in numerous other ways to provide guidance or protection. The combustibility can also be used to great advantage. It is these properties that help while he talks at a campfire. You might notice the fire grows when he gets excited and dies down when he quiets down. It can really add a hypnotic effect to his stories. Another way it can be used is to help young scouts when they are learning to build fires. When he is helping a young scout learn fire starting skills the tinder seems to ignite a little easier, and really helps the budding confidence of the scouts.

There are inherent dangers in using these properties as well. For example, if the young scout has a little help starting a fire it can be good for him, but if he always gets that help he will begin to rely on it like a crutch and not even realize it. While it can produce a great effect while telling a story around a fire, there are a lot of fires like a signal fire that need a very steady burn, and the gas can make it difficult or impossible to send the right signals.

Recomendation

So to wrap up here is my recommendation. Create a unique and highly customized position for him. He will never fit in the role of a normal councilor, and he has far to much knowledge and experience to treat him like a scout, yet he does not have the capacity to be the camp director. Let him talk at the firesides, but don’t let him mingle with the scouts or parents after. Let him give tips and insights to the young fire-starters, but don’t let him linger for any length of time. Let him blow his gas around the camp at night because it keeps the bears and skunks away. When a scout is lost follow his instincts, but don’t cancel other search efforts.

There are also some things I recommend that you never allow. Never allow him mingle with potential scouts or their parents. Keep his direct interaction with anyone to a minimal highly focuses purpose. If there is nothing for him to do directly encourage him to go explore unfamiliar canyons; you never know when you will need someone to guide an expedition there. Don’t let him bunk with anyone because the gas can kill while they sleep. In fact it is even dangerous for him to bunk indoors because he too requires air to breath and he can poison himself if he spend any length of time in an enclosed area.

Above all, try to make these ‘special’ arrangements become his request. Help him see that he prefers to sleep under the stars. This will not only help him feel happy it will protect himself and others. Help him feel that he can help more scouts if he doesn’t spend too much time around a specific few. This will allow the individual scouts to get small doses of his help without putting them in danger of hurtful poisoning or ignorantly using the gas as a crutch.

Whether you choose to have, or not have, his advantages and disadvantages around is a fine choice, but be prepared in either case to give an answer to others who may adore him and may abhor him. Very few people actually understand him for good and bad. Most just see one or the other, and can’t or won’t see the whole picture.

Code Rating System

I would like to propose a rubric of classifying code with regards to its completeness and maintainability. This system will have two parts, separated by a dot '.', both of which are ratings from 0 to 4, 4 being the best. The first part or the part before the dot rates the objects and methods that perform the work, and the second part, or the part after the dot, will rate the quality of the automated testing. With this scale 0 would indicate that the code exists in some manner, but it is not working, and a 4 would mean that the code is in an optimal state for long term maintenance. So code that rates as 1.1 would mean that the code and its test work, but it is in a poor state for maintenance. While code rated as 4.4 would mean the code and its automated tests are in an optimal state for maintenance.

The elements that this system will rate are:

• +1 Does the code work as intended.
• +1 Are sufficient comments and documentation in place.
• +1 Are sufficient logging statements in place.
• +1 Are coding standards followed.

This code rating system is intended to be customized by each organization. As an example perhaps there is an organization that has no coding standards and they would just use a a 0 to 3 scale, or perhaps an organization considers on schedule to be important so they add an on-time and an on-budget item and use a 0 to 6 scale.

Logging

Logging is often underutilized in development companies. When an organization really understands the value of logging it will reduce the maintenance cost of code dramatically.

What is a log? A log is a short message that an application stores to give a maintainer information about what is happening behind the scenes (behind the user interface). Logs are generally stored in a file or a database so that they can be read and/or searched to find information about the running system.

Logging should be broken up into levels; each level having a specific and distinct purpose. In general those levels are as follows:

1. Unrecoverable Problems: When something occurs that causes the entire system or application to cease running unexpectedly. When this occurs the log should get as much information about the state of the system and, if possible, the factors that caused the problem. This is generally difficult or impossible to capture because if a contingency plan was possible to implement it would be a level 2 problem.
2. Undesirable but Recoverable Problems: When something unexpected occurs, but the system is able to recover, and return to normal operation. This type of problem is often caused by a necessary part of the system becoming unavailable. If a recovery is possible it is usually done by waiting, reinitializing part of the system, or switching to an alternate of the element that failed.
3. Normal System Operations: While the system is running it is often useful to get information that allows a maintainer to verify that the system is running as expected. This is often information about periodic state of the system, or significant operations being completed.
4. Major Module Operations: This level is used to monitor the normal operations of a module. It is generally not included in normal operation logs, but is useful to monitor the operation of individual modules while the system is being tested.
5. Major Feature Operations: This level is used to monitor the normal operations of a feature. It is generally not included in normal operation logs, but is useful to monitor the operation of individual features while the system is being tested.
6. Minor Feature Operations: This level is used to monitor the fine details of a feature. It is not included in normal operation logs, but is useful to monitor the fine details of a feature while the system is being tested.
7. Line by Line Changes: This level logs information about each non-trivial variable change. This is generally only useful when attempting to debug.