With the recent financial meltdown, I couldn’t help but notice a trend among my clients. I’ve worked with over one hundred companies in one capacity or another that has given me an insight into how they develop software.

Among these companies, there were two particularly frustrating companies where I was on site and a third that I assisted with a very difficult proof-of-concept. I actually compiled software applications for each of these companies, each of them failed to implement the enterprise software process and automation improvements I was helping them with and none of these three companies exists today - victims of risky investment practices and high-profile failures in the 2008 financial crisis.

To be sure, I’ve had many frustrations at many other companies because implementing centralized software development management practices is extremely difficult, involving almost every department in IT. But the other companies ultimately gained the consensus, management backing and financial support to implement real change to lower the risk of software delivery and improve business continuity.

The three software management failures that ultimately turned business failures were particularly sore spots for me. And, as a trained physicist, when I see three software management failures and three business failures and they are the SAME three out of a hundred, well, I know there’s a very high probability for a relationship.

An anecdote: one of the three, a super large bank liked to grow by acquiring other banks. Word on the street is that the OCC, stepped in and said you have to improve your software management practices before you can acquire more banks. So, the bank implemented a software management improvement program including first centralized version control and later more proper configuration management (always surprising to me that they can deliver binaries and manage versions but not know if the two are related in any way). I was brought in for the centralized build management part. Then the OCC said something like “We see you’ve implemented some version control. OK, you can go ahead an buy more banks.” POOF! The software improvement projects were all massively scaled back and there was no more enterprise build management to work on. How about that?

When a company implements software development and delivery improvements they are lowering the risk of proprietary software changes which in turn lowers business risk by decreasing interruptions of services and ensuring on-time delivery of new features. At this stage of industry maturity, a company that does not have control over software delivery is accepting a business risk that fewer and fewer competitors accept.

So its reasonable to believe that a company that takes large financial risks will take risks across the board - even with their software management practices.

We’ve got a couple of things going on in the next two weeks. Quinn and Dan and I were at a rousing TechCocktail Chicago event last week and met a lot of new people as well as some old friends.

Chicago Rational User Group - Presentation on IBM’s Jazz. This is at TransUnion, 555 W Adams, Wed Nov 12. Quinn Bailey will be attending this one, starts at 5pm. Registration at: https://secure.rational-ug.org/check_user.php?type=meeting&meetid=873

WindyCity.pm Perl User Group. At the Google offices, Mon, Nov 17. Topic: http://www.frdcsa.org/ . Registration is usually via a Google Doc form - not available yet. Yours truly will be attending this one.

Eclipse Demo Camp hosted by OpenMake Software. At one of our favorite restaurant/bars, The Kerryman, 70 W. Erie St., Nov 19, 6pm. Yours truly will demo “Desktop Workflow Automation in Eclipse with Mojo Plug-Ins”. Free beer - need another reason?

I found myself actually using four different file control tool plug-ins in a single Eclipse 3.4 workspace. This is not show-off, but for legitimate needs. Before proceeding, let me disclaim that I am reorganizing my Perl development on a new machine and I have everything somewhat haphazardly in a single workspace. Ideally I will have different workspaces for different projects, but until I build a standard set of preference, particularly for EPIC Perl templates, and, I can export and import them into different workspaces, I’m locked into a single workspace for now.

If you are not familiar with Eclipse and version control (or as I call it generically “file control”) you have to install plug-ins that provide the functionality to interface with different tools. I have an EPIC plug-in that provides Perl tools, and I’ve installed EGIT for Git integration and plug-ins for Subversion and Bazaar. The CVS plug-in actually comes as part of the base Eclipse install, though that status is questionable given the popularity of Subversion and the rapid rise of Git.

These plug-ins provide the capability to create a new project from the contents of the file control repository, or attach an existing Eclipse project to a new project under file control. You do this by right-clicking on the project and going to the “Team” menu and the “Share” item.Here is a quick explanation of the screen shot above. “om64Perl” comes out of our OpenMake CVS repository. The ones attached to Git, are pretty obvious with the word “Git” clearly to the right of the project name. Being a distributed repository tool, the Git repository that the projects are attached to is actually in the workspace. Then, I have an anemic open source project on SourceForge to which the “PerlSCM” project is attached via Subversion. And, finally, there is the Perl VCI project “vci” that uses Bazaar.

There you go. Because I’m involved with three open source projects that use different file control tools, and regular work that uses another, I end up with four.