One strategy for increasing job security is to make yourself indispensable by never documenting anything. Deliberately following such a strategy is unethical. Passively falling into such a situation is more understandable, and more common, but it’s not very smart either.
If you’re indispensable, you can hold on to your job — maybe. But the flip side is that you can’t let go of your job either. You can never wash your hands of a project, never hand it over to someone else. You cannot be promoted. You’ll need to take your laptop with you on vacation, if you’re able to take vacation.
I’ve seen this play out in software projects that are never quite finished. The project minimally works, but only with the developer’s intervention. The developer isn’t trying to be indispensable. Quite the opposite: the developer desperately wants to get away from the project. But the software isn’t stable. Bugs are discovered every time a new part of the code is exercised. These may be fixed quickly, but only by the original developer. Or maybe the code is stable, but only the original developer can reproduce the build. Or some part of the code ought to be configurable, but instead the developer has to constantly tweak the source code. For whatever reason, the project isn’t wrapped up and the developer cannot extricate himself from it.
The solution is to plan to make yourself dispensable from the beginning. Ask yourself throughout the project, “How am I going to be able to hand this over to someone else?” Or more graphically, “What if I get hit by a bus?”
Make yourself valuable for what you’re expected to accomplish in the future, not for what you’ve accomplished in the past.
A former co-worker of mine once showed me (with, I’m afraid, a note of pride in his voice) a 2,000-line stored procedure he had just finished writing. When I expressed my worry that it was impossible to understand, he said “hey, job security, right?”
I’m still around and he is not, but working on his code is no fun.
You’re absolutely right. That’s what I do too in my job, I tried to document everything and being dispensable from the beginning.
And usually my response when I see some incomprehensible procedure like that is to rip it out and rewrite it. (Generally this is faster than trying to understand and change it). If you create code that others don’t understand, eventually you leave them with no choice but to replace both your code and you.
I enjoyed reading this article. Thanks.
I had a coworker who went by the motto “Processize and backfill”. What this meant was that he would try to develop a process for what he was doing (processize) and then bring in somebody else to do the job (backfill) so that he could move on to the next task. One consequence of this attitude is that outsourcing becomes much less of a risk, because part of your job is TRYING to outsource what you are currently doing.
Nice article. I think y0u highlighted something that we all should attempt to address to some degree. I particularly enjoyed the comment about “reproducing the build”. It makes me crazy to pull a project out of version control and find the developer didn’t managed to include 3rd party libraries or even indicate where to download said libraries.
Documentation …. Yes!
Clarity …. Yes!
Making yourself dispensable …. Yes!
Also, this all can be gotten from an old notion of Weinberg, that programming ought to be egoless, that there should be a clear separation between the person who writes the code and the code as a product. Often programmers mix up the two.
But sometimes the best way to do this is to make the module or script or unit so solid that it almost never needs maintenance. I know that’s often hopelessly idealistic. In those cases, it Really Needs To Be Done Well so whatever maintenance is needed is straightforward, the code robust, and the test cases documented and thorough. (TDD can win here.)
In some cases, turning the code over to somene else may not be possible, even if the documentation and test cases and clarity are there. Sometimes the company doesn’t have the skillset that understands the code. I have found, for instance, that programmers aren’t plentiful who understand numerics, even if these are calls to the GNU Scientific Library or routines in R. That’s unfortunate but real. I’ve had to design, devise, code, and plan around this fact of life. I bet others do too.
ezkept: I would add that the importance of making code “so solid that it almost never needs maintenance” increases as your code base grows.
If the MTBF for a component is 100 days, that may be good enough if it’s your only component. But if you have dozens of such components and they interact with each other, you’re constantly dealing with failures.
What would you company do for your family and you if you would get hit by a bus? I find it offensive that if you get crippled or killed you care about some stupid app. how fast would the company fire you if you would get hit by a bus and were unable to do your job?
on the opposite you can quit or get promoted if you make no documentation. ive seen it both happen.
@ehhh,
“What would you company do for your family and you if you would get hit by a bus?”
Getting “hit by a bus” is American English idiom or slang for “being made unavailable for reasons no one can control”. It’s not meant literally.
There are other matters here, however, which bear upon the relationship and its ethics. If I write code for hire, the code, its design, its test cases, and its documentation belongs to the person paying me to do it. I therefore have certain obligations to them. However, I reserve certain obligations to myself. Surely, if I don’t get paid for a period I am supposed to get paid, I need to review the relationship. Maybe there’s a good reason why my employer cannot pay me that period and it’s better in my long time interest to understand. Maybe there isn’t, and then, as a professional, I need to finish off my work for them as quickly and diligently as possible and then end the relationship.
There are other ethical things which bear, too. If I am writing software that serves an important social purpose, such as for the military or for a medical device, as professional, I’m responsible for being sure that device performs as it is supposed to perform. Moreover, if I feel the specification is incorrect and I’m aware of it, it’s my responsibility to ask the right questions of the right people to either understand, get it changes, or file the appropriate objections. The same applies to statistical or quantitative consulting, and many other professional activities.
I surely don’t get paid simply to “do software” for N hours, and that’s where my responsibility ends.
Regarding the last couple paragraphs of ekzept’s response above, I am continually reminded how much responsibility software developers have that goes unnoticed. As I’ve said before, the buck stops with the programmer.
Being “indispensible” places one on a slippery slope toward commoditization. Safe haven can only be found within the polyvalent segments of work processes. Therein lies the key to the isoquantal nature of the competing ternaries of value, complexity, and human expertise…
http://wjmc.blogspot.com/2010/03/polyvalence-defies-commoditization.html
Thanks for the opportunity to comment…
I’m fortunate in that my current company holds sharing of knowledge as a core value. I haven’t been there very long, but get the impression I won’t be there much longer if I don’t help others, let alone at in such an irresponsible manner as suggested in the post.
With regards to @ehhh, unfortunately he’s got a point in that trading hours of current work for weeks of future work, and other production for production capacity trade offs will get you ahead at the wrong companies.
If you see this happening, take it as a sign that it’s not the job for you.
completely agree with this article, although I wouldn’t say that its necessarily “in the code”. Often times, the design of where and how you manage state and the decoupling of components is extremely important.
If your organization doesn’t promote from within, or you simply plan on moving to another company as your next career move, then what you say only applies to the degree that you need a job reference. I don’t care if a company that mistreats me has to deal with any mess that I created, intentionally or not, after I leave. It’s their fault for not noticing that I embedded a custom haskell interpreter in the build system or that the few comments that I did write are in Japanese. Mind you, I don’t write bad code– it works and it is roughly documented in hand written notes (in japanese) in a notebook, so that I can charge $200/hour when they need to change something after I leave. And that’s only if I want to.
Tomas: I hope you are being facetious.
John: Not at all. Most managers want working code yesterday much more than well-documented code tomorrow. In practice the quick-and-dirty-but-five-times-faster method always wins out over the slower, more ‘correct’ way. And I don’t have any emotional attachment to the code I write at work b/c most of it is closed-source and owned by my employer (in contrast, I try to follow your advice for open source programs I contribute to). Even if I did write atrocious code, no one but my sorry replacement would see it.
I’m also serious about embedding haskell in the build system (I was bored one week), documenting in Japanese on paper (I’m much faster diagramming and writing notes in Japanese– I did it for my own productivity b/c of crazy schedules). Many of my variables are single greek letters, too… they’re faster to type, and I have my own undocumented policies for which letters mean what.
Furthermore, I’d say that, unless you’re a junior PHP programmer or just doing something completely unoriginal and low-skilled in a trendy language, making yourself dispensable is not practical in most cases. There are countless Cobol and FoxPro hackers out there who properly documented their code and did everything you say, and yet they are indispensable b/c Cobol and FoxPro are ‘dying’ languages, and programs written in those languages tend to involve lots of business-specific logic. Should those programmers spend the rest of their programming days trying to make themselves dispensable? What if you’re one of a handful of, say, chemist-programmers that would ever understand what you’re doing, and there’s no replacement in the first place?
That “… managers want working code yesterday much more than well-documented code tomorrow” is sad, and is an instantiation of a “tax the future” approach to false productivity common in many industries. But, in my opinion, it has immediate costs, perhaps not this quarter, but layers upon layers of this kind of code eventually develop bugs, even if they did not have them in the first place. I know of an organization which has some important code which cannot be compiled by current level gcc compilers (and I’m not talking point releases either) because doing so would require a rewrite that managers don’t want to embrace. They don’t care that more recent gcc versions contain bug fixes and important performance improvements. They also don’t care that the compilation of these products issues dozens of warning messages which are pretty much ignored. What’s important to them is getting a product release to make its deadline, even if it contains errors that affect customers.
I have seen this attitude persist all the way back to my days with IBM. It was not good then, and it is not good now. The idea of doing things with speed being nearly the only criterion precludes an organization from choosing certain solutions, because they don’t want to stop and think about them.
My personal ideal for code quality and documentation are the marvelous LINPACK and EISPACK packages, and to a lesser extent, NAG. I rarely achieve that level of thoroughness, although I try.
I also think it’s important to try to write portable code, and find such a focus helps to reduce bugs. I’m also considered stodgy, I think, by some at my place of employment, because I like to insist upon written requirements statements, if only in the form of a paragraph of prose.