Generativity, an open door policy

So, I have had some time to sit and consider what it is about software projects in my work a day world that make for successes and what things make for interesting types of failure. Here is where my thinking landed me:

1) Being open, and inviting is a benefit not to be undersold

It sounds so tantalizingly simple when you type it out like that, so much so that you might read that line above as "...If you build it, they will come..." but that isn't quite what that line means.

When teams develop new software, the software being developed is sometimes about a new feature or a new thing that BigCo. wants to have as a product and sometimes is to scratch an itch that the team has. In either case, this new software is likely to be able to assist a whole bunch of people which same or similar needs (it is unusual for software to actually be built 100% single purpose). Because most software can actually serve many 'close knit' needs, once you or your team has taken the time to build, you should also take the time to advertise and allow other teams to make use of what you have built. Being open, means no matter what you develop that you essentially open the door to others to build, manage or deploy with you.  Let other groups make use of the things you built, with as few a number of restrictions, provisos, caveats as humanly possible.

2) Protect the system, but keep the number of rules as low as you can

This is somewhat self explanatory - try to only put in place those rules that help you to make sure that the system is up, available, and working correctly.

3) Trust people to do whats right

When you open the door - you are opening your system up to whatever may come. To that point, you have to be able to trust that peoples self interest will also align with you and yours to some degree. Try to keep a light touch and trust that people will not go out of their way to screw you - or the system you built - that they are now using. If those who have been invited in through the open door do take advantage, know in advance how you would like to react to those coming to seek your new hot thing. Describe your "open door" so that people know what they are signing up for in advance.

4) Don't fall into the trap of N.I.H.

Part of doing work this way, with this mind set, is preventing yourself from going off into a corner and building it yourself because:

   * You believe that building it yourself is the only way to control your own destiny
   * Your team can't possibly be successful because your success is dependent on another team

It will always be simpler to modify something that is already built than it will be to go from scratch no matter how good your developers are. Work already done can trump work to be done in a great number of occasions.

5) Command and control will squash peoples desire to use what you build

Don't try to control the software and how its used too must - exercise just enough control to manage and maintain the quality of the system. I have seen plenty of people that believe that becoming the manager, exec, vp, director or what have you is all about being able to do it JUST the way they want. Nothing really could be further from the truth. The farther up the chain you go, the less desire to control you should have and the more trust you have to have that things will head in the right direction. If you attempt to stringently control things, no one will want to come be a part of the thing that was built and like holding a fist full of sand, the harder you squeeze the more sand you will lose, no way to hold it all.

Be open, be inviting, be willing to negotiate and understand how people will want to use your software. Be generative - providing space for people to get the most amount of benefit out of the building blocks you have already put together. It will eventually help the bottom line because everything being built will start to move faster, eventually.

Forward compatible data consumption

Forward compatibility means ignoring new fields should they arise ... passing them through if possible, ignoring them if they can't be passed through.  i.e. FOCUS ONLY ON WHAT YOU ALREADY KNOW and ignore the rest.

This means in XML parsing, if you are using annotation based parsing - tell it to ignore fields and objects it doesn't understand and continue with the rest, or if manually parsing to only concentrate on known objects and ignore the rest.

Same thing for json, annotations (like Jackson) need to be told to ignore fields that can't be mapped into the objects in a known way and to proceed with everything it does understand.

This way other systems can include new information that could be consumed at some later date without impact to the system at hand.

Why is all the above at all relevant or important - these steps are vitally important to the compatibility of APIs that you might be developing. In order for the API to be forward and backward compatible as changes to it are made the API system must be able to accept new things or ignore things it does not currently understand. APIs have to hold themselves accountable for what they 'know' they can do - and things that can safely be ignored.  If the API you are developing can't ignore things it doesn't understand, then errors get returned to the clients that may have otherwise resulted in a useable response from the API.