Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Institutional Memory and Reverse Smuggling

timothy posted more than 2 years ago | from the you-never-forget-your-first-flunitrazepam dept.

Businesses 312

An anonymous reader writes "Anyone who's worked in a large engineering firm is familiar with institutional amnesia. Things get built, and then forgotten. Documentation is supposed to help, but rots, is lost, or uses obsolete methods and notation nobody understands anymore. I recently found myself in a strange position, rehired as a consultant with the unofficial job of reminding the company how an old plant works. I even have some personal copies of documents they seem to have lost, which I have to awkwardly smuggle back in. I don't find these kinds of experience written about often, but I'm convinced they're more common than you'd think."

cancel ×

312 comments

Sorry! There are no comments related to the filter you selected.

This problem is quite common. (5, Insightful)

ksd1337 (1029386) | more than 2 years ago | (#38258606)

A very relevant area where this problem can be readily seen is computer data formats.

Re:This problem is quite common. (5, Insightful)

YayaY (837729) | more than 2 years ago | (#38258650)

Yep, It happens all the time everywhere.

What I find most troubling about this is that most company don't recognize the problem or are not even aware of it? I think the mentality that "anyone can be replaced so we don't have to create incentive to retain them" is going a bit too far.

Because the real problem is in fact employee turnover.

So what's the problem then? (2)

Colin Smith (2679) | more than 2 years ago | (#38259098)

Management don't care, why should you? It really can't be all that much of a problem. More a perception than a problem.
By all means go ahead and create/use a documentation system for your group but clearly there just isn't a requirement for anything more comprehensive.
 

salvage and surplus (4, Interesting)

goombah99 (560566) | more than 2 years ago | (#38259290)

At my institution we routinely buy back equipment from salvage yards it was sold to. But this actually makes sense. We clear out lots of old stuff rather than pack ratting it. It's a small price to pay for the convenience of getting stuff we need back.

Know-how and know-why... (5, Insightful)

AliasMarlowe (1042386) | more than 2 years ago | (#38259436)

One of the uncomfortable truths (uncomfortable for MBA cost minimizers) is that know-how is between the ears. It is not in the manuals or specifications, which merely prove that their writers had the know-how. Even more important is the know-why, which is part of the institutional memory which also resides between the ears.

I have witnessed some "technology transfers" where a set of working products was transferred with documentation, design data, and much background information to a group in another region (mostly EU/US transfers). The first group is then wound down or redeployed. The new group does fine at first, until a new version of a product is needed. Then they always make mistakes the original designers would consider childish or stupid. They don't know the why behind design decisions, and don't know what to avoid. In my experience, it takes 5-10 years to build a decent product design group from scratch. On the other hand, an existing design group will sustain itself by mentoring and guidance of new inductees by experienced members.

The only successful technology transfer which I participated in was one where a few senior designers were transferred with the set of products they were responsible for. It was far from cheap in up-front costs, but it avoided the crises and financial disasters which afflicted the other transfers after a year or two.

Re:So what's the problem then? (5, Insightful)

0123456 (636235) | more than 2 years ago | (#38259308)

Management don't care, why should you? It really can't be all that much of a problem.

The manager who didn't document anything finished ahead of schedule and below budget. He got a big bonus and moved on to another job at a different company based on his reputation for delivering early and cheap.

The manager who comes in to organise an upgrade to that software ends up taking much longer than expected and going well over budget because nothing was documented in the initial spaghetti code. He gets fired for being incompetent.

And so, civilisation ends. (2)

Colin Smith (2679) | more than 2 years ago | (#38258930)

And a new dark ages are born.

Oh enough hyperbole. Wouldn't worry about it, the companies in question will collapse and be replaced by someone else if the demand is high enough. Or not if it isn't.

Been there, done that: (5, Funny)

Hartree (191324) | more than 2 years ago | (#38258614)

But the NDAs keep me and everyone else involved from talking about it. :P

Re:Been there, done that: (0)

Anonymous Coward | more than 2 years ago | (#38258894)

Could everything we know be forgotten? (Solar flare or EMP? )

Re:Been there, done that: (1)

Hartree (191324) | more than 2 years ago | (#38259006)

Don't even need that. Just time, alzheimers and screwed up documentation.

Re:Been there, done that: (0)

Anonymous Coward | more than 2 years ago | (#38259354)

That's what the Anonymous Coward is for! Let's say "he"... "heard"... you all talking about it in private with his "SuperSpy 5000!!!11one".

Now tick that box and tell us what went down, fool! ;)

It's common (2, Interesting)

Anonymous Coward | more than 2 years ago | (#38258622)

A unnamed corp where I use to work would hire retired employees for contract work at high per hour wages for months due to issues like this.

Re:It's common (5, Funny)

brusk (135896) | more than 2 years ago | (#38259036)

Maybe if the company had given itself a name it would have been easier for it to keep track of information.

No (3, Funny)

Colin Smith (2679) | more than 2 years ago | (#38259162)

Speaking from experience, corporations are unable to give themselves just one name. They have to change their names regularly (because it obviously makes things better, like go faster stripes) and more, they have to change the names of departments even more regularly (again because it improves everything). The result is that any documentation system which is created rapidly becomes fragmented, out of date and lost as the paths to the documents are changed to match the names.

The conclusion is that using names only makes things worse.

Re:No (1, Funny)

brusk (135896) | more than 2 years ago | (#38259234)

If you really believed that you would have posted as AC.

Absolutely true (5, Interesting)

cvtan (752695) | more than 2 years ago | (#38258628)

I have personally witnessed this happen with my former employer. Higher ups seemed to think that there was some benefit to the company "memory" or "team experience" if we almost brought a product to market. People would argue that at least we now had the experience to do this again in the future if we had to. Totally wrong. Teams were broken up and key players re-assigned. Some people left the company or moved to divisions physically remote from their former bosses. Any reports written could not be used to replicate anything useful and, to be honest, who would write a report explaining the history of an unsuccessful product? It never happens. Real knowledge is lost in a barrage of wasteful spending.

I see this in code I work on all the time (4, Insightful)

NotSoHeavyD3 (1400425) | more than 2 years ago | (#38258636)

Somebody writes the code, doesn't bother to comment it at all and then you come in years after the fact. You look at the code and wonder, "why did he do it that way instead of this way?" Then the big gotcha, you think I could ask him but he left the company 5 years ago(At this point slap your forehead and hope you don't break anything working on the code.)

Re:I see this in code I work on all the time (4, Interesting)

ninetyninebottles (2174630) | more than 2 years ago | (#38258740)

Somebody writes the code, doesn't bother to comment it at all and then you come in years after the fact. You look at the code and wonder, "why did he do it that way instead of this way?" Then the big gotcha, you think I could ask him but he left the company 5 years ago(At this point slap your forehead and hope you don't break anything working on the code.)

One way to mitigate this is "extreme programming" where developers pair and constantly switch off projects and tasks. You end up with a larger body of people that understand the code and comments and code that is much more understandable because if you write it in a way that isn't, someone will notice the next week, complain and you have to go back and fix it.

Also, if you're hoping you don't break anything, hopefully you have a battery of unit tests and functional regression tests that will catch the lion's share of anything you might break and let you know in short order.

Re:I see this in code I work on all the time (0)

Anonymous Coward | more than 2 years ago | (#38259108)

While I understand the point you are making when I hear the term "Extreme Programming" my imagination runs wild.

Are your trying to run with the Bulls in Pamplona while trying to figure where that Division by zero takes place?

Re:I see this in code I work on all the time (1, Troll)

ninetyninebottles (2174630) | more than 2 years ago | (#38259192)

While I understand the point you are making when I hear the term "Extreme Programming" my imagination runs wild.

Yeah and the term for writing computer programs is "coding" and the anode on a battery is labeled "-" those are the dreadfully inappropriate terms that stuck. Deal with it.

Are your[sic] trying to run with the Bulls[sic] in Pamplona while trying to figure where that Division[sic] by zero takes place?

Yes I am, but that is unrelated to the term "extreme programming". Also, you improperly capitalized "Bulls" and "Division"; maybe you've been watching too much basketball?

Re:I see this in code I work on all the time (1)

Anonymous Coward | more than 2 years ago | (#38259376)

It doesn't work. You'd need people that follow the same coding practices and have enough experience to move at the same pace. Which is pretty much impossible.

Maybe not impossible, but unlikely, you would need people who worked together for a very long time, unheard of in IT since we're talking about years.

Re:I see this in code I work on all the time (1)

hibiki_r (649814) | more than 2 years ago | (#38259466)

First, enough turnover will always kill you no matter your procedures. If a team turns over 75% of its developers in 6 months, there's nothing to be done. So step 1: make sure your developers don't want to quit.

But even if you are using TDD or BDD, even a bit of sloppiness here and there can still leave you with a very hard to solve puzzle. Maybe a unit test isn't maintained well enough, and it passes even though the code isn't really doing what the test description said. It keeps passing for a year. Then, you go back, and a change makes the unit test go back towards its originally intended codepath and starts failing. But at that point, we do not know anymore if the releases for the last year have been bad, the requirements were bad in the first place, or what. All it takes is the right kind of slip up. And even with the best intentions, there's always slip ups.

Re:I see this in code I work on all the time (5, Insightful)

Anonymus (2267354) | more than 2 years ago | (#38258776)

Even worse, it sometimes turns out that YOU wrote the code 10+ years ago, and you have absolutely no clue why it was written that way.

Re:I see this in code I work on all the time (1)

cbuhler (887833) | more than 2 years ago | (#38258932)

I have this problem exactly. And even if I did document it, I probably assumed that what ever it was doing was obvious so didn't really spell it out.

Re:I see this in code I work on all the time (4, Funny)

zill (1690130) | more than 2 years ago | (#38258950)

You guys have it easy. Sometime when I write a comment I for-SQUIRRELS!

Re:I see this in code I work on all the time (0)

Anonymous Coward | more than 2 years ago | (#38259232)

You guys have it easy. Sometime when I write a comment I for-SQUIRRELS!

What the hell does this mean?

Re:I see this in code I work on all the time (4, Informative)

heypete (60671) | more than 2 years ago | (#38259398)

It's a reference to this scene [youtube.com] from the Pixar movie "Up".

Re:I see this in code I work on all the time (0)

Anonymous Coward | more than 2 years ago | (#38259420)

"Up" referen... SQUIRRELS! ....
https://www.youtube.com/watch?v=bBWrMQVsuak [youtube.com]

Re:I see this in code I work on all the time (0)

Anonymous Coward | more than 2 years ago | (#38259424)

It means he's easily distracted.

Oh look, a squirrel.

Re:I see this in code I work on all the time (0)

Anonymous Coward | more than 2 years ago | (#38259216)

10 years? For me it's more like 2 weeks

Re:I see this in code I work on all the time (1)

Anonymous Coward | more than 2 years ago | (#38259322)

It's totally true. One time I was going through an old perl script and I wondered what kind of asshole would write something like that. Turned out I was that asshole.

Re:I see this in code I work on all the time (0)

Anonymous Coward | more than 2 years ago | (#38259484)

For me that could be a couple of days. I keep a lot of stuff in my head and old stuff gets pushed out pretty quick.

This is why I don't use languages like Lisp, OCaml and Scala. They are very flexible and powerful, too flexible, and often you end up writing something "bizarre" that can't be easily comprehended later.

I have to remind of solved problems (5, Insightful)

gestalt_n_pepper (991155) | more than 2 years ago | (#38258658)

I design automated testing systems. I find myself in the position of re-solving problems that were solved as much as 10 years ago in prior automated testing systems. There's an odd tendency of people to simply passively accept whatever the manufacturer of the new system gives us as somehow "better" or more advanced that what we had, even when the new solution is an obvious fail, or (ahem) undeveloped. So I fix things to make up for the shortcomings of the new software, more or less the same way I fixed them 7 to 10 years ago. Things start working again. Everybody is happy.

I seem to have discovered job security by re-inventing the same thing every 7 years or so in a slightly different form using a different programming language. Of course, that sort of describes the entire computer industry, more or less.

Re:I have to remind of solved problems (1)

Ethanol-fueled (1125189) | more than 2 years ago | (#38258752)

There's an odd tendency of people to simply passively accept whatever the manufacturer of the new system gives us as somehow "better" or more advanced that what we had, even when the new solution is an obvious fail, or (ahem) undeveloped

I think it's an issue of "the engineering or accounting manager knows a buddy in the software business" rather than simple passive acceptance. The good ol' boys ignore the howling pleas of the plebes and laugh all the way to the bank.

Are you in the business of hardware testing (GPIB, bed-of-nails, stimulus/response switching etc.) ? If so, could you provide specific examples listing softwares, platforms, etc? I work extensively in hardware test and I'd like to hear some horror stories.

You haven't discovered job security (5, Funny)

Colin Smith (2679) | more than 2 years ago | (#38258864)

Until you write it in cobol.
 

Why bother (5, Insightful)

Anonymous Coward | more than 2 years ago | (#38258660)

Why bother trying to smuggle them back in. Tell them you'll work on figuring out the bits you can't remember and will write a new manual. You get to charge them for time you don't need to spend and avoid getting caught.

Re:Why bother (1)

couchslug (175151) | more than 2 years ago | (#38258774)

Bingo!

They get the desired result, you get money.

Re:Why bother (2)

houghi (78078) | more than 2 years ago | (#38258964)

And then they wonder why people think that consultants are basically thieves with a title.

Re:Why bother (5, Insightful)

Trepidity (597) | more than 2 years ago | (#38259018)

In this case it really is the safest solution, though. Companies don't want to know that someone has violated their precious document security policies, and would be much happier overpaying to have the data recreated than finding out that someone had a private copy. This guy giving engineers copies of the documents is probably the nice thing to do, but it's a risk that the incentives don't favor. Either he's naive, or knows the engineers he's dealing with well enough to trust that nothing will happen.

Re:Why bother (0)

Anonymous Coward | more than 2 years ago | (#38258992)

I was going to suggest telling them you got the code from a competitor (this might also be a useful way of getting corporate leadership to notice the innovation which occurs within its own walls). Alternatively you could tell them you got it from the open-source community.

Software Evolution (3, Interesting)

Anonymous Coward | more than 2 years ago | (#38258680)

One of the courses of my university study was called 'Software Evolution' in which tutors showcased all kinds of problems with legacy software. Software using languages or platforms no one knows about anymore or lost source code of mission critical systems. Especially older banks and insurance companies suffer from this problem, often choosing the 'wrap around the bit that we know that works' instead of a complete overhaul of a system no one really knows what it does but does it really well. I fear everything we build today will cause the same problems, but worse. Perhaps the old idea that readable code should help people understand its function saves us from this scenario...?

Re:Software Evolution (2)

desdinova 216 (2000908) | more than 2 years ago | (#38258836)

(sarcasm) but that would cost money (/sarcasm)

Re:Software Evolution (2)

Runaway1956 (1322357) | more than 2 years ago | (#38259076)

If you don't know what it does, how can you measure how well it does it?

I think what you meant to say, is that no one really knows what it does, but it continues to return answers that everyone likes.

Perhaps small reusable components might help (3, Insightful)

Colin Smith (2679) | more than 2 years ago | (#38259214)

They could do one thing, just one thing, but do it well...

Now... Where have I heard that philosophy before?
 

Dear Slashdot admins, (5, Insightful)

sootman (158191) | more than 2 years ago | (#38258724)

More like this, please, and less about the Apple/Andoid/MS/Samsung/**AA suit-of-the-minute. I know, I know, flamewars == pageviews == Step 3, but you've occasionally gotta throw something out there for us old-timers.

Re:Dear Slashdot admins, (5, Insightful)

Anonymous Coward | more than 2 years ago | (#38258918)

How about you submit more like this? Or create more like this? Or find a site that is more about this? Or make a site that is more about this? I'd love to see it too but the fact of the matter is that the majority of the people here don't have these kinds of problems nor are they interested. Wait and see. Give this article about 3 days and look at the next closest article about Google/MS/Apple/RIAA and see what gets what comments. Granted, this article will probably get more insightful and thought out comments and a lot less of the memes and trolls than the others but page hits is what the management wants. They don't really care about content.

Re:Dear Slashdot admins, (0)

Anonymous Coward | more than 2 years ago | (#38259064)

Dont have any mod points, but wanted to post my +1 for a refreshingly interesting story.

Outside of the code, all documentation is worthles (5, Insightful)

cavehobbit (652751) | more than 2 years ago | (#38258744)

I currently work for a company that has instituted an incredibly restrictive development methodology they bought from a big consulting firm. It requires multiple forms be filled out for every program written, every requirement for every program written, every request for every change to every program or application written. All of these reviewed by coworkers who are not about to alienate team members, and reviewed by lower management who want to look good to upper management by having everything go smoothly.

These documents are then stored on the LAN. To never, or rarely ever, be read again.

The one thing it does not enforce or require, is meaningful documentation in the code itself.

It doubles, or more, the time it takes to do everything. But it does nothing to stop the mistakes any better than the procedures that went before. If anything, it finds less errors, because we were not given more time to do this double or more amount of work. So time is so compressed, we do not have time to do anything other than get it working and get it in.

One thing it does do very well, is prevent problems from getting fixed. The only people that will start a change effort are those that notice a problem and are affected by it enough to have it cause them problems. Otherwise no one wants to go through the bureaucracy to kick off any sort of change effort, which leaves a lot of ticking time-bombs in the infrastructure configurations, application designs and application code.

The only place documentation is good, is if it is meaningful, and in the code, where it is readily findable and far less likely to get lost, short of some fool deleting it.

Documentation located anywhere else will be lost, or obsolete many more times than not, before you ever really need it.

If anything, documentation in code should be reviewed by people with absolutely no connection to the application it is for. If it is good enough for them to figure out an understand what is being done, and more importantly why it is being done, only then is it worth anything more than the bytes is written with in storage.

Re:Outside of the code, all documentation is worth (1)

Anonymous Coward | more than 2 years ago | (#38258912)

Helloooooooo, RUP

Re:Outside of the code, all documentation is worth (1)

TheLink (130905) | more than 2 years ago | (#38259034)

The only place documentation is good, is if it is meaningful, and in the code, where it is readily findable and far less likely to get lost, short of some fool deleting it.

If the organization is that bad that it loses its version control (or doesn't have one), you might consider not having the documentation as comments in the code, but rather as strings (that are not optimized away by the compiler). That way some poor bugger going through the executable years later can read them despite the complete lack of source code.

I'm kidding of course. ;)

Re:Outside of the code, all documentation is worth (0)

Anonymous Coward | more than 2 years ago | (#38259222)

How about a built in documentation system within the program as both a user available help, and developer documentation?

Re:Outside of the code, all documentation is worth (3, Insightful)

Anonymous Coward | more than 2 years ago | (#38259056)

The only place documentation is good, is if it is meaningful, and in the code, where it is readily findable and far less likely to get lost, short of some fool deleting it.

Deleting documentation is far more important than writing it. There is nothing worse than documentation that is clear, concise, convincing and that assumes something that is ever-so-subtly wrong due to the code base having been changed since the documentation was written. It's better to update the wrong documentation, but deleting it is far better than leaving it in in most cases. So no, people deleting comments are not necessarily fools, especially not if working to a deadline.

sounds like TPS report hell (1)

Joe_Dragon (2206452) | more than 2 years ago | (#38259382)

next up is the bobs.

Opportunity for more pay (4, Interesting)

mbone (558574) | more than 2 years ago | (#38258746)

I recently found myself in a strange position, rehired as a consultant with the unofficial job of reminding the company how an old plant works.

I certainly hope that you negotiated a much higher salary than before.

I have known people who were fired in a "chain saw" maneuver who proved to have core corporate competencies in their heads. They negotiated for a much higher rate the second time around...

Re:Opportunity for more pay (0)

Anonymous Coward | more than 2 years ago | (#38258976)

If you RTFA, you would know if s/he did.

Re:Opportunity for more pay (3, Insightful)

Nidi62 (1525137) | more than 2 years ago | (#38259300)

If you RTFA, you would know if s/he did.

If you had read it, you would know whether to use "he" or "she".

Re:Opportunity for more pay (0)

Anonymous Coward | more than 2 years ago | (#38259358)

If you RTFA, you would know if s/he did.

Eh? What does RTFA mean?

Re:Opportunity for more pay (5, Funny)

Anonymous Coward | more than 2 years ago | (#38259432)

I know a guy who, after the company was bought, got the ax along with every other engineer in the place.

As he was working remotely, he had a local copy of the entire repo. With his severance check was a reminder to "destroy all company information in his possession".

Fortunately, he didn't do that because, 2 months later, they came back asking if he had gotten around to doing that because the salesdroids accidentally sold off the main repo server when they liquidated the office equipment.

He greatly enjoyed negotiating the fee for "recreating" the repo that he "didn't have".

Company rules against removing documents (5, Insightful)

blackC0pter (1013737) | more than 2 years ago | (#38258748)

I'd be very careful in this situation. Even though you are supposedly "doing the company a favor" by smuggling the documents back in, were you even legally allowed to take the documents in the first place? Most employers have contracts or rules that state you can't remove documents from the office or that when you leave the company you must return all property to the company. Furthermore, it is most likely that this documentation was property of the company all along and in that case did you break any laws by removing it from the company and keeping it? IANAL but this is a very tricky situation. You may be doing good for the company now but you are profiting off of documents that you do not own and may not even have a legal right to possess.

Personally, I'd stick with just what's in my head and not keep any documents, files, etc. from a previous employer. It's just asking for trouble.

Re:Company rules against removing documents (5, Interesting)

Anonymous Coward | more than 2 years ago | (#38258876)

Yes, that's what makes it tricky. I wasn't supposed to have these documents, but some important internal drawings have been lost, and I have a copy. The safest solution would be to avoid bringing it up, I agree. Though I'm not blackmailing them for the documents or anything.

I've heard it happen several other times. I've had colleagues who consulted for a company, then a few years later get a call or email asking if they by any chance still have a copy of some old document. Of course they weren't supposed to have kept a copy, but if they accidentally did, it would be really nice if they could send a copy because the company seems to have lost it...

It mostly happens at lower levels of the org chart on a don't-ask/don't-tell basis I think. Lots of people keep personal archives, and sometimes the official archives have to get patched out of them.

Re:Company rules against removing documents (0)

Anonymous Coward | more than 2 years ago | (#38259086)

How about you recreate those documents from scratch, whether genuinely or pretend to? In the latter case you can have longer breaks to read Slashdot etc while you're "reverse engineering" the stuff ;).

Of course if you actually like the company then perhaps you might be more helpful than that. But I personally don't think you should take extra effort or risk to help a company that will screw you for helping them. Sure you breached policy, but if you didn't leak the data out to anyone else, big deal. Exceptions are made for CxOs all the time.

Re:Company rules against removing documents (2)

xs650 (741277) | more than 2 years ago | (#38259228)

That happened to me about 5 years after I retired. A friend who was still working at my former employer called and asked if I had had any documentation on an old project they needed top resurrect. My employer had been good to me while I worked there so I sent it to them. Being only slightly paranoid I did send it with no return address or other info on where it came from.

Re:Company rules against removing documents (0)

Anonymous Coward | more than 2 years ago | (#38259444)

The only "personal" archives I keep are on my user's directory share on the company's network. It will be wiped when I leave, but it is so much more useful to me day-to-day than the document storage structure the company provides and which changes with every re-org, which, I was shocked to discover (this is my first job at a big multi-national), happens more than once a year on average.

I've been there about seven years doing EXACTLY the same thing the whole time and I have had nine manager changes, and at least seven unique department codes.

Re:Company rules against removing documents (2)

Stevecrox (962208) | more than 2 years ago | (#38259408)

I think it can be an easy enough thing to do, for a while I was doing a far bit of travel for my place of employment. Considering some of the journeys took place on the weekends I had to take home some company gear. If you do that long enough the odd notebook can easily be left at home. I agree if you know you have something it's either better to give it back or to destroy it but can see how an employee would have this information.

I would suggest if you have continually worked for the company to simply come clean admit you have it, they can't really accuse you of using the information outside of work. Depending on the place it might either be seen a good or involve you getting a slap on the wrist, in any case disclosing how and why you took it home might help improve their document tracking and security procedures.

If you left the company I'd argue things become more complicated, personally I would still admit to possessing the documentation but I can see that things could go very badly and why you might not want to do that. Where I work they have an ethical helpline (anonymous) I'd call it and lay out the situation and do what they suggest.

Of course if you intentionally took the company gear home and kept it, you should really be asking yourself why you took it home and why you thought keeping it was ok. I'd argue you have much bigger problems.

Worked on High Rises in NY (1)

Anonymous Coward | more than 2 years ago | (#38258760)

Hi !
I used to make construction blueprints, a lot of them were for NY sites(company was very small - 20 people).
Once, we were forced to pull old drawings, back from 70's(done by the company I worked for). It took us a while to figure out wtf is going on

Lost information is common but (0)

Anonymous Coward | more than 2 years ago | (#38258762)

Losing information over the years is common but rehiring for consultation is fairly rare in comparison. The easier method rather then reverse smuggle the data in, since you have worked on the system before, simply sign a NDA with the company that all knowledge remains there and kept secret. Since you are not a true employee, companies require at least a contract of that type in order to feel safer for "outsiders" to work on sensitive data. Barring that solution, just work with the internal team. Rather then trying to get the old data official recognized, quietly give them your data so that they may create "new" documentation based off on the old to be stored (guaranteed to be alot easier when working with management).

Aliens. (5, Funny)

mosb1000 (710161) | more than 2 years ago | (#38258788)

If the history channel read this story, they would undoubtably conclude that the plant was built with the help of aliens.

Re:Aliens. (1)

belmolis (702863) | more than 2 years ago | (#38258824)

If I had mod points, I would be torn between "funny" and "insightful".

Sometimes IT has to help the business (2)

MagikSlinger (259969) | more than 2 years ago | (#38258794)

Where I work, us, the IT teams that program and support the applications, often have to tell the employees how the business works. So many people retired in the 2000-2010 that a huge chunk of institutional memory walked out the door. The new folks doing the jobs often don't know how to handle the Once Every Five year situation, etc. I know the company keeps buying these Knowledge Sharing portals, but it seems more like oral history is the primary knowledge transfer.

Re:Sometimes IT has to help the business (4, Interesting)

TheLink (130905) | more than 2 years ago | (#38259184)

Maybe some companies need a Historian or two.

An important task for Historians is to regularly remind the bosses what Historians are for so they don't get sacked ;).

Re:Sometimes IT has to help the business (0)

Anonymous Coward | more than 2 years ago | (#38259250)

Is your IT team getting recognition as a line of business unit which adds to the bottom line; or is IT considered a cost center with pay and budgets painfully slashed? Are line of business managers getting bonuses for business operations support you provide; and you get no bonus?

I routinely sends IT requests back to line supervisors and managers for specific enumeration when the request asks for support on "my mailing list/file share/server". If the line of business supervisors and managers cannot remember or internally document the IT assets which are critical to their business operations, many other critical business elements in their deptartments are equally operationally inadequate.

I don't have the time or resources to operate their line of business unit and my own IT unit. If I wanted that responsibility, I would be a company executive.

Documentation is key (4, Insightful)

markdavis (642305) | more than 2 years ago | (#38258800)

My situation is different, yet similar. I just have so much responsibility for so many things at work, I simply can't remember how everything works. At times it is frightening, especially since year after year there are more things happening and I get older, so it is already inherently more difficult.

I also find myself "protecting" my sanity by almost intentionally forgetting how some things operate, especially those things I don't like.

I think as a manager, one of the most important things to do is learn to effectively document everything. I always knew documentation was important, to the point that I have a log of everything I do at work, every day, that spans 23 years! But those are just "reminders", not proper documentation. It helps to jog memory or memorialize certain facts for reference. Nothing replaces *proper* documentation, though- the kind that is well thought-out, has great detail, and is organized properly. Further, it will have insights into defining the problem and the solution and WHY you selected certain paths and not others.

Proper documentation takes considerable time, and many people think it is a waste of time, especially when one is drowning in projects and deadlines. When you reach the point that you can't handle the load without continuing to document properly, you know you are in trouble. In the short-term, you can "win" by getting more things done. But in the LONG TERM, you are basically screwed, because you will spend a tremendous amount of wasted time later trying to relearn what you did and why. Or worse, trying to defend your decisions and can't because you can't find the information, it doesn't make sense, or it just doesn't exist.

Re:Documentation is key (1)

Anonymous Coward | more than 2 years ago | (#38259126)

every job ive had, i write my own black book, containing all the useful bits i need or learn on the job. it invariably saves me more time than writing it costs, and really makes life easier. and since im the beneficiary, i make sure its up to date. surprisingly few managers care about it when i give them a copy as i leave.

that is why they need Technical writers / writers (2)

Joe_Dragon (2206452) | more than 2 years ago | (#38259446)

to do the wiring part so that the tech people have time to do the tech work.

Control is the problem. (3, Insightful)

mosb1000 (710161) | more than 2 years ago | (#38258832)

The bean-counters and mindless penny pinchers who run most corporations like to keep everything secret and proprietary without fully appreciating the costs associated with maintaining that level of secrecy. The solution is simple, only keep something secret if you've first: taken the effort to understand what it will cost to do so and second: taken the effort to make sure the secret won't actually be forgotten. In short, keep fewer secrets, and keep them a lot better.

That's why the Feds declassify secret documents (2)

MichaelCrawford (610140) | more than 2 years ago | (#38259096)

It costs money to maintain secrets. If there is no reason to keep it secret anymore it is cheaper not to guard it.

I don't comment my code anymore (4, Insightful)

MichaelCrawford (610140) | more than 2 years ago | (#38258834)

i did so slavishly at first but then my boss pointed out that comments are rarely updated with the actual code. a contrived example:

int foo()
{ // always returns 4

      return 5;
}

now I have a coding style that the simplest fool can understand. that's quite a different thing than the arrogant coders who feel that their colleagues are incompetent if they cannot follow uncommented code. if someone cannot follow my code then I feel I have done something wrong, not them.

assertions are better than comments (4, Interesting)

MichaelCrawford (610140) | more than 2 years ago | (#38258948)

now one does need to document the expected inputs and results of subroutines. better than commenting is to use assertions as well as unit tests. so for that contrived example, what I would actually do:

int foo()
{
        int result = 5;

        assert( 4==result);

        return result;
}

if you don't maintain the assertions and unit tests with the payload code you'll find out about it right away.

Re:I don't comment my code anymore (5, Interesting)

UnknownSoldier (67820) | more than 2 years ago | (#38258974)

> that's quite a different thing than the arrogant coders who feel that their colleagues are incompetent if they cannot follow uncommented code. if someone cannot follow my code then I feel I have done something wrong, not them.

IMO, _proper__ commentting discusses WHY you did something. If someone wants to understand HOW it was done, read the code, as you correctly reason. Any half-decent coder should be able to figure out what the code is doing.

EXCEPTION: If you are doing something tricky, then document that. i.e. http://www.codemaestro.com/reviews/9 [codemaestro.com]

Solution To: I don't comment my code anymore (0)

Anonymous Coward | more than 2 years ago | (#38258984)

Simply convert to COBOL. It's "Self Documenting" !!

Re:I don't comment my code anymore (2)

uufnord (999299) | more than 2 years ago | (#38259386)

now I have a coding style that the simplest fool can understand.

As I am one of the simplest fools that I know, I just want to say -- Thanks for this. It is appreciated.

Old news (4, Informative)

DingerX (847589) | more than 2 years ago | (#38258838)

Primo Levi, "Chrome" in The Periodical Table describes a similar problem with a paint formula at his factory in the 1950s. Evidently, during the war, they had a QC problem, included some chemical to correct for that, and the formula became a cargo cult, long after anyone knew what it was for. Someone changes some other factor, and their batch of paint gets the consistency of liver. So our hero had to reverse-engineer the trade secrets of a previous generation, back when he was working in the lab at Auschwitz.

this is why you shouldn't outsource (5, Insightful)

MichaelCrawford (610140) | more than 2 years ago | (#38258880)

if your own employees do the work your company retains the knowledge of how to get it done.

if you outsource you never learn how to do your own work, instead you finance your outsourcing firms efforts to learn how to operate your business. not only do you not gain that institutional memory but that outsourcing firm can now perform that same work for your competitors.

Try an old schematic in Cadence Composer... (0)

Anonymous Coward | more than 2 years ago | (#38258884)

Now let's try something a little closer to Slashdot...

Remember that circuit/macro/chip you worked on long, long ago, back when dimensions were reasonably measured in fractional microns? What schematic editor did you use? There is some chance that it was Cadence Composer, "the standard of the industry." What are your chances of reading that schematic today? You may have saved the data, but did you save an installation of the tool? Will it talk to the new license server? From what I've seen, any new version will "read and convert" the previous version. But how many people have time to go back and convert all of your previous designs to the latest'n'greatest design database? More likely you kept an installation of the old tool around, "for legacy purposes." When was the last time you tried to actually run that old tool?

Bringing it back to Slashdot again, I'll have to say that we don't often have to go back to old designs for any sort of serviceability purposes, generally one or two generations back is sufficient for that. But LEGAL purposes... You know, the Troll that is suing for something you know you did 15-20 years ago, if you can just find a date-stamped schematic....

Once upon a time, I gave an internal technical talk on schematic entry. I used as my example the ultimate schematic entry tool. It made semi-permanent archives, maintained a constant, readable database, etc, etc, etc. About the only problem was that it didn't directly interface with any of the downstream tools, like simulation or extraction. I actually used this tool when I first got into the design business. It was, of course, pencil and paper.

I work there (2, Interesting)

Anonymous Coward | more than 2 years ago | (#38258940)

I work in a library at a large organization and I see this every single day. The short answer to the problem is that it needs to be someone's responsibility to ensure access to KNOWLEDGE (NOT data, documents, etc, but knowledge) in the long term. I get requests from our employees every single day asking for information on project x that was shut down in the 90's. It is my job to track down any information that I can. Unfortunately, I have neither the directive or funding to start gathering and organizing the knowledge in such as way that it is useful a few decades from now. So instead I tell our employees "sorry, you will have to spend a few hundred thousand to recreate the information."

There are lots of people out there that can fix this type of problem, but they are never given the tools to do so.

Old Story (1, Interesting)

Anonymous Coward | more than 2 years ago | (#38258966)

This guy worked at a company for 30 years. He retired and his company called him back in when an important machine started to break down. He placed an X where they had to fix the machine and then left. He sent the company a bill for $10,000. The company asked him to detail the bill. He sent: Placing a mark where to fix the machine $1. Knowing where to place the mark, $9,999.00. Old story and these days I make a few bucks because people improperly documented their work OR had no clue what they were doing. For example using a 1/4" industrial air disconnect to feed 2 air cylinders which hold a maximum of 10CF each at 90psi and then trying to fill them in about 10 seconds with 60psi of air from a 90psi source. Ain't guys with Phd's really smart :-) If it weren't for those really smart and educated people I might never have made any money.

Re:Old Story (-1)

Anonymous Coward | more than 2 years ago | (#38259276)

cool story, bro!

you and your life are worthless.

NASA (3, Interesting)

Latinhypercube (935707) | more than 2 years ago | (#38258978)

NASA has lost ALL of it's Saturn V knowledge. The scientist have died, the documents have rotten and been lost. The parts were SOLD AS SCRAP. NASA is currently trying to buy up all the lost parts from scrap dealers. All this old knowledge is for the 'new' space program. Yes, we are indeed regressing.

Re:NASA (4, Informative)

0123456 (636235) | more than 2 years ago | (#38259226)

NASA has lost ALL of it's Saturn V knowledge.

Uh, no it hasn't. It may not be readily accessible, but there are (literally) tons of Saturn V information still available.

The scientist have died, the documents have rotten and been lost.

That'll be a surprise to the people who've put many gigabytes of Apollo-era documents on ntrs.nasa.gov.

What they have lost is much of the software; the Apollo Guidance Computer software only exists because some of the programmers had old listings that were OCR-ed, and the Saturn guidance computer software seems to be long gone.. there are a couple of computers left that may still have the code in their core memory, but so far no-one has been brave enough to try reading it out since that's a destructive operation and if you screw up you won't get a second chance.

Fortunately if someone was to try to rebuild a Saturn V they'd use completely new electronics and software anyway. Heck, it would probably have to run Windows...

A nice story (1)

Anonymous Coward | more than 2 years ago | (#38259102)

But have the firms outsourcing their document "management" ever given a thought to the firms handling the documents being copied into digital format?

What a wonderful source of industrial espionage especially when the documents cross nation-state borders for low cost labor in other Nations.

Oh, that hidebound government bureaucracy! (2)

Daniel Dvorkin (106857) | more than 2 years ago | (#38259118)

Something like this would never happen in private enterprise, where the invisible hand of the free market weeds out such inefficiencies.

Oh, wait ...

A liitle more strange (2, Funny)

Anonymous Coward | more than 2 years ago | (#38259128)

I have a situation a liitle more strange. A customer of a former employer (now twice aquired) has asked me to act as a customer advocate on a system I wrote as they have "limited" confidence in my former employer being able to maintain the system and the NDA/Non-Competes/IP Ownership prevent me working on the system for the customer.

This is a solved problem (0)

Anonymous Coward | more than 2 years ago | (#38259136)

We solved this problem year ago, trouble is we didn't document it properly, so we are coming back to it again.

A similar experience (2)

Dartz-IRL (1640117) | more than 2 years ago | (#38259148)

I had a similar experience, from the other side of the spectrum. I was the summer intern doing a project that required digging through the paper archives to find some hardware data that was to be entered into a computer simulation.

It was nowhere to be found. What was documented for this perticular plant was little more than the type of equipment used. Not it's technical ratings or anything. Just what was there. And good luck finding any of that documentation only.

I also found full documentation for a plant that'd been shut down decades ago. Then demolished. And was now a blank wasteland. "In the hope they would be useful"

A while back I got a desperate phone call (1)

MichaelCrawford (610140) | more than 2 years ago | (#38259166)

I once worked for a digital aerial photography company. It had been acquired by another firm. The new owners desperately hoped that I'd kept a personal copy of all the source I'd written. "of course not" I replied.

While I was very good at backing up my code some cluebot had taped over it all with aerial photos.

duh (0)

Anonymous Coward | more than 2 years ago | (#38259170)

Institutional memory is the only asset that matters in the long run. It is the only asset that is not factored in on day to day efforts. The disconnect is both institutional and personal.

If one were to fix one thing in the USA it would be institutional memory. Globalization might be the second and Keynsianism the third.

JJ

down side of outsourcing / contractors (1)

Joe_Dragon (2206452) | more than 2 years ago | (#38259188)

That paper work can get lost and or end up in some 3rd party's hands.

or that the documenting part get's passed around and it's not done or is done poorly.

It is a solved problem (5, Funny)

Bryan Ward (2524388) | more than 2 years ago | (#38259310)

Years ago people solved this problem but they didn't document their solution well, so here we are again.

This is What Technical Writers Are For (1)

Nova Express (100383) | more than 2 years ago | (#38259422)

Sure, end user documentation is one thing, but another reason your hire a technical writer is so they document how systems and processes work in easy-to-understand terms, so that when someone leaves the company, the loss of institutional memory is isn't so great.

I worked at a compay with good documentation. (0)

Anonymous Coward | more than 2 years ago | (#38259494)

As a contractor I was shown where the docs were on the LAN.
A frame relay link went down on the other side of the world causing trucks to begin backing up as bills of lading were being done by hand.
I was able to look at docs turn up a modem on one of the router interfaces to a backup link and call the carrier give the circuit ID and get the link back to full speed.
I an not a CCNA or any of that crap. Made me hero for a day.
Man I miss good documentation only found it that one time.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>