Over the years, I have learned something very odd about software that many people know but never consciously realize. I am sure sales people know about it because it is just the kind of thing that sales people live for…like “Sell to their heart and appeal to their head” or “The real price is the price they are willing to pay”, this nugget of insider knowledge sheds light on unconscious human behavior that most of us never notice:
All Software Looks Good In Thumbnails.
You can take any screen shot of any mediocre application screen, shrink it down to 150 x 100 and it just looks nice. Try it yourself.
There is just something about shrinking things down that makes them more appealing. Take cats, for example. Lions are beautiful animals, but few of us want to run up and squeeze it. But shrink it down to a kitten and nobody can resist it. It is impossible.
And have you ever seen a baby lamb? Who could possibly resist it? This even works for people. Nothing makes us want to squeeze on a person and pinch their fat cheeks like shrinking them down to infant size. Come back in twenty years and keep the same look and hardly anyone is tempted to squeeze their cheeks, and it is almost impossible to get someone to pick them up.
Nature knows that cuteness greatly decreases the chances that a parent or other relative will kill and eat an infant animal (or person, for that matter), so it maximizes cuteness as a survival tactic. Unfortunately, some people pushing certain ungainly software development methodologies have been known to do the same. They do this by expounding on the virtues and simplicity of an idea at a level that makes it likable and cute. They provide a thumbnail view of it so that the warts don’t stand out and spoil the image. This leads to rapid adoption and almost as rapid dropping of it.
This is not entirely unlike what has been done in this series of articles so far, and it just may be that some people are getting the idea that there is really nothing cute about this idea, that it is really some made-up utopia that really doesn’t translate well to the real world. That it is really only half-baked, gangly, ugly, and un-lovable. They would only be partially right.
This article will start to show from a practical, normal project view how the Project Integrity Management concept can help keep your projects on track and well organized without turning into a three ring circus of QA meetings and tracking charts. Over the next few installments, a clearer (non-thumbnailed) picture will emerge that will help you assess whether or not you are wasting your time and brain cycles on another useless methodology or it this one really is onto something.
So, without further delay….
How can Project Integrity Management help keep projects on track? Please, no sales pitches.
Project Integrity Management is a concept that abstracts all pieces of a project into something trackable, versionable, and managable. It relates all pieces of the project to all other pieces in a way that if one changes, others that depend on that piece also change. Each minute piece of a project, whether it is a configuration file, a source code file, a server, or a third party library is uniquely identified and versioned. And this is actually very easy to do.
The key to the simplicity of this approach is the abstraction of all elements. No matter what we are talking about in a project, it has the same structure from a PIM standpoint:
- Unique Identifier
- Version
- Properties
The Unique Identifier differentiates a particular item from all other items in the project. No two different items will have the same unique identifier, which I will refer to as ID. Associates with each ID is at least one Version. Version is not unique to a single item. It is used to tie any number of items together as a unit. For example, lets say you are building an image management library. For simplicity’s sake, this library has three files:
- ImageMan.cs - The source code file that contains all of the logic for the library.
- ImageMan.config - The configuration file that contains user definable settings.
- ImgApi.dll - A third party imaging library (compiled) that was licensed for redistribution with the application.
To version this library (i.e. the project), the following Integrity Management Items (IMIs) would be created:
ImageMan.cs
ID: 1234
Version: 1
ImageMan.config
ID: 1235
Version: 1
ImgApi.dll
ID: 1236
Version: 1
These can then be compiled into a list of items for this particular version:
NAME ID VERSION ---------------- ----- ------------- ImageMan.cs 1234 1 ImageMan.config 1235 1 ImgApi.dll 1236 1
This list can then be saved in a text file, database, or any other storage medium and given a name:
ImageMan.PIM
Here is where the fun starts. If someone were to need to know what files were part of the ImageMan project, all they would need to do is look at the list in ImageMan.PIM and gather those files together that are listed as part of the project. Simple enough.
But what happens when the vendor of the imaging library ImgApi.dll comes out with a new version? How do we make sure that our project has the newest version without breaking the release that is already in testing?
The answer is simple, yet it has deep implications: We version the list.
In other words, we create an IMI named: ImageMan.PIM with the following information:
ImageMan.PIM
ID: 1237
Version: 1
Since the file ImgApi.dll changed, we create a new VERSION of that IMI:
ImgApi.dll
ID: 1236
Version: 2
Now each time a file within the list changes, we can create a NEW VERSION of the file which contains the NEW VERSIONS of the changed files:
ImageMan.PIM
ID: 1237
Version: 2
NAME ID VERSION
---------------- ----- -------------
ImageMan.cs 1234 1
ImageMan.config 1235 1
ImgApi.dll 1236 2
At this point, we have TWO versions of ImageMan.PIM. Version 1 points to all version 1 files (the original list), and version 2 points to the original files except for the one modified one, ImgApi.dll
Now if we need to go back and reconstruct the original set of files, we can use Version 1 of ImageMain.PIM to identify the needed files. However, if we want to recreate the newest version, we can user Version 2 of ImageMain.PIM to get a correct list of the needed files.
This simple introduction does not fully explain how large-scale projects can be managed using this methodology, but it should give a good idea of what the philosophy is, and what is meant by everything is versionable. In future articles, I will be digging deeper into how to implement this on a larger scale and exploring some ideas of how to automate the process to make it more manageable.
M@
