The JourneyThe ConversationsThe StoriesThe ConnectionsThe IdeasThe LatestAboutHelp

If the community is lost then the system isn't worth it's source code

Told to me via email, and verified through other sources:

17 years ago an application with source code was bought off a vendor.
They had a core set of developers/managers and dbas who were by accident (rule change) made permenant at inflated salaries more akin to contractor incomes.
Around them was a group of long term Analyst Programmer contractors (up to 10 years ).
A small team of Business Contacts / Testers were also key.

I like to characterise this as very much a 'community' view of an application, if a vibrant long term community is present to support a system then it should be able to be supported forever, but if the community is lost (or communication is lost) then the system isn't worth it's source code.

Management created a "nothing new" culture, and just did the simplest thing that worked for a long boring time. Peer review was used to force conformity, and deviation was culturally discouraged. The new developers who didn't like that left. No graduates were taken on, just experienced developers. We were operating more often than not on unsupported platforms, at the trailing edge with email being our typical integration tool.

In the beginning there was a 2 year period where the developers had a firefighter approach, everything was urgent.
Then the next 5 years the code got tightened and bugs were driven from the system.
The system went through the y2K and green screens turned into GUI's and then to mouse active.
Then the code-base started to develop and provide more high function screens, much more tightly welded to the business (think skin tight pants). The parts of the system that were obviously wrong for the business were worked around by external Access databases. When serious gaps started to appear new subsystems were developed with the business to re-engineer parts of the process, but essentially just making official the ways they were working around the system. Those parts were often wildly sucessful although under appreciated inside the business.
A B2B system was developed to integrate smoothly with suppliers via email, surprisingly with microscopic ongoing support requirements.
The business failed to engage with us, partly due to communication problems with the business, chiefly due to our lack of reseources we put into the communication, and also the business became very comfortable in the system.

The cost of the system (TCO) was well under comparable systems even though we used long term contractors.
The functionality of the system/s grew into most parts of the business.

Then a new CEO came in with a mandate for change, and the system will be replaced.

Syndicate content