Slashdot Mirror
Institutional Memory and Reverse Smuggling
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."
A very relevant area where this problem can be readily seen is computer data formats.
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.
Please do not read this sig. Thank you.
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.
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.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
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.
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.
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.
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.
Request your free CD of my piano music.
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.
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.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
I saw a company lose probably 60% of their IT knowledge base. They announced outsourcing six months in advance, and directed current employees to document their jobs so that offshore workers could take over. Employees instead used the time to find other jobs, as one would expect. Transition was a disaster, and a year later they're still discovering things that the company no longer knows how to do.
One of the mistakes made was to assume that everything the old team did could be described as a procedure that a junior offshore employee could follow. This is a fallacy at a basic level, and shows a basic misunderstanding of IT. Knowledge is more than just memorization of individual procedures, it's information about topology, architecture, the flow of information, how the business works, and where the knowledge points are in the organization. (Who knows what.) Degradation of that knowledge base began on the day outsourcing was announced, and by the time transition arrived, there wasn't much left.
The basic misunderstanding, I believe is thinking that IT is generic procedure-based stuff that anyone could do. There are cases where this is true, but if you are in the business of providing a web based business, your IT *is* your value add, and your success is probably based on in what way your team does things that *aren't* generic.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
"But of course, this would imply a corporation with the ability to see beyond the tip of its own nose, which is rare."
The problem is not only corporate culture but societal.
Say Big Corp A has in fact the ability to see beyond the tip of its own nose and then spares efforts to prepare for the next decade which, of course, impacts its bottom line for this quarter. At the same time, Big Corp B doesn't see beyond the tip of its own nose and this quarter's results look better than that from Big Corp A. Then, all of a sudden, everybody, *you included*, sell their stocks from Big Corp A to buy stocks from Big Corp B which makes Big Corp B even bigger while Big Corp A is not a big corp any more.
Which, ironically, makes Big Corp B to be the one with the ability to see beyond the tip of its own nose because since Big Corp A is a big corp no more, its investment for the future is now moot and shouldn't have been done to start with.
That's exactly why you see from time to time companies exploding basically out of nothing (say Google or Facebook) despite of the fact that other Big Corps near the business niche have much more than enough muscle to crunch them -their stockholders wouldn't allow for the investment. And that's exactly way you see those Big Corps investing much more in rising the bars for new entries with lawyers, IP, patents and lobying legislators than in real R&D.