views:

156

answers:

6

I work in the IT consulting line. My job is to penetrate into whatever client/customer environment I have been assigned to and bring about technological improvements (or sometimes, black magic tricks) to boost their business/domain.

As I am sure many out there are just like me, you would know first hand the situation I describe. The environment we step into is not plain barren land waiting for brand new systems to be built upon. we inherit a world of legacy, and the world ain't perfect. It is less than complete, comprehensive, and systematic.

There is a black box system developed in some ancient arcane platform. The vendor has closed shop 15 years ago. No source code or documentation exists. The corporate network is managed by a 3rd-party global infrastructure team and configuring all the firewalls your application will touch involves contacting over 30 different personnel. Your customer liaison doesn't know who they are either. Nobody dares to modify the framework layer code base ever since the original architects quit three years ago; they don't even know if the code in the version-control repository is the latest. The DBA or application team are always unavailable, and you cannot connect to the database or authenticate with their web service to pull the data for integrated or stress test. Nobody claims responsibility for that monitoring server in the corner with the crackling hard disks. The CIO knows squat about the enterprise architecture and what systems are in place, and commands no technological direction for the coming five years. What are the passwords to the servers in the DR site?

Essentially, it is an environment where processes, information, documentation, and knowledge have been loss to time as generations gone by and relationships vaporized. Chaos is guaranteed when disaster happens, because the correct group of trained personnel to handle the situation are non-existent. A humongous amount of time and effort is spent peeling the layers of murk and dusting and combing for clues. Details absolutely necessary to get the our own jobs done.

I have not come across any book that touches such job factors and conditions. Yes, a great deal is all about social engineering and dealing with the human factor to chart and plot the political boundaries (official or otherwise, public or hidden) and knowing the exact people to get things done. And that is part and parcel of our daily routine. I would love to read about the experience of others in their quest to overcome these hurdles of "lost technology" or "civilization". If there can really ever be a systematic guideline or approach in the unearthing and self inference of these artifacts?

Am I crazy to wish for such a book?

EDIT: just to clarify the above descriptive is not regarding the current environment I am in. It is a collection of random illustrations based on the experiences with past environments.

Yes I am looking for books and materials that cover processes that help one try to discover more about systems they are taking over. It is more than just pure programming source code, but the entire scope of people and infrastucture that the systems operate in.

A: 

Might not be exactly what you are looking for but this book deals with change in several places. Probably something you could consider giving to the clueless CIO. ;)

http://search.barnesandnoble.com/Information-Systems-Management-in-Practice/Barbara-C-McNurlin/e/9780131854710

Kevin Goff
+1  A: 

If you don't know about the amazing novels by Vernor Vinge, he has a similar concept of Programmer Archaeologist

thelsdj
A: 

If your question is whether you are crazy to wish for the book, I would say no -- but I think a book would be to constrained to contain everything you are proposing.

Maybe you could start up a website or wiki that focuses on this, defining a process and best practices for defining legacy systems at an enterprise level...

I have worked in environments like you describe, doing this type of work, and it's a brutal slog sometimes; my best success is to define what the responsibilities and boundaries of each software system (a challenge in itself), then come up with a plan to define consistent interfaces. No two environments will be the same, of course, and this is not a "quick fix" but rather an enterprise architecture roadmap, with the goal of helping simplify business processes and ease maintenance and improvements/upgrades.

Guy Starbuck
A: 

I work with maintaining an aging code base myself, albeit not nearly as problematic as what you're describing - my opponent is just a few megabytes of undocumented win32 C code. I picked up a book from a bargain bin in my local tech bookshop by chance, called Software Maintenance: Concepts and Practice, but I haven't gotten around to reading more than the first few pages so I can't tell you if it's any good.

While browsing for the link I also found the following list at Amazon which might be of help: "If you're stuck with someone elses code". Although I fear that anyone in your situation will be a bit too short on time and sanity to successfully write a book about their experienses!

odd parity
A: 

Amazon offers a few interesting books when searching for legacy systems.

The Wikipedia entry on "Legacy System" suggests a few other search terms you might want to try; "legacy modernization", "legacy transformation" and "legacy code".

Things You Should Never Do, Part I is a great article by Joel Spolsky on why companies should never write code from scratch.

The system you mention sounds very large. Perhaps the first step is to break it down into components and work out exactly what source code exists and which components must be coded from scratch.

As for the human factor, the people working with this system must feel the pain when things go wrong. They should be pleased if you try and introduce new parts of a system to reduce problems. The key thing is introducing things slowly and incrementally, educating the users of the system on why these changes need to happen and keeping them informed when changes are about to happen.

andyuk
+1  A: 

Thank you all for your suggestions. I shall take the time to check them out.

Steve Smith recently touched on the topic of testing legacy code as well. More on the programming side, but well... http://stevesmithblog.com/blog/testing-legacy-code/

icelava