Posts
Dear Reader,VISTA's bigger than you think it is - vastly bigger - by scales of magnitude. None of the numbers you can put next to it (files, programs, lines of code, function points) comes remotely close to its actual complexity and sophistication. The interaction of its intricate integration with its unparalleled extensibility creates intricate effects that VISTA depends on but that we don't begin to know how to measure. Fortunately we don't have to.
We just have to understand that it is very, very big, too big to be effectively managed as a whole, unlike most software in the world. Bluntly put, as a whole VISTA is unmanageable. If you try to manage VISTA from a single code repository, your VISTA codebase will stagnate and your productivity will fall over time. You'll know you've begun to grasp the scale of VISTA when the idea of a single, central code repository for managing VISTA literally makes you laugh. Until then, you're not even close.
Fortunately, you don't need to begin with a single code repository to manage a shared VISTA code base. The VISTA lifecycle sure doesn't.Instead, we follow the traditional divide-and-conquer strategy that makes computer science possible. We break up VISTA into packages and manage each package with its own independent code repository. In our experience, this reduces the scale of the problem enough that a highly expert, dedicated team can almost - almost - keep up with the problem of managing just that one package.
So, throw away the idea of beginning your VISTA lifecycle management with a single, complete gold account, and replace it with the idea of many gold accounts, one per package.
Yours truly,
Rick
3 comments:
Excellent point and I couldn't agree with you more, but the problem we have always had (at least it seemed like a problem to me) was getting a "for profit" entity to say, "I'll take package 'A'" and get another "for profit" entity to say, "I'll take package 'B'". From a business perspective, it does not make sense to turn over what could be a very key part of your profit ability to 'competitors'. As a matter of principle, you would have to leave kernel development and management to a "not for profit" or "non-profit" entity that was designed to do that, and only that - develop/manage the kernel.
Dear Rodney,
I started proposing something along these lines in 2001 and did so with some clarity and passion in 2004, but the vendors needed to go learn for themselves the costs of trying to manage the whole thing.
Now that balkanization is getting clearer to them, along with the costs of being cut off from innovations in other dialects of VISTA, it seems there is a chance for the VISTA vendors to come together around a common shared core codebase.
Now that VA's grip on VISTA is loosening, because of their commitment to centralization and guaranteed-to-fail replacement projects, the currently somewhat disorganized community outside VA is beginning to emerge as the likely custodian of VISTA in the future.
The road to understanding the VISTA lifecycle has proven long for the non-federal adopters, but the future may lie with them, now that they are beginning to understand the point you made.
Yours truly,
Rick
PS: Of course, IHS also is becoming more central to VISTA's future, shifting from second fiddle to VA to becoming the healthiest federal VISTA adopter and developer. The emerging relationship between IHS and the nonfederal VISTA community will play an important role in shaping the division of packages within the community.
See: http://www.linux-mag.com/cache/7536/1.html
As I understand it, the way that Linus Torvalds manages his team, it is very much like your ideal: "owners" that manage the various packages.
Linus is more like the guy that takes the "single" boxes in your diagram and pushes out the "multi-dot" boxes as a distribution. (This activity would be a bit tweaked for your model, but essentially the same).
For those Linux users interested in following/tracking development by receiving "deltas" ("patches" in VISTA/KIDS-speak), that is available too.
The Linux side is simpler since there is not really any "data" component.
Post a Comment