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 have accomplished in the past.
Related post:
Programming the last mile
{ 11 comments… read them below or add one }
Gabe Moothart 04.22.09 at 08:46
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.
Hector Villalobos 04.22.09 at 09:52
You’re absolutely right. That’s what I do too in my job, I tried to document everything and being dispensable from the beginning.
Corwin Joy 04.22.09 at 10:25
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.
James Aguilar 04.22.09 at 11:08
I enjoyed reading this article. Thanks.
Andrew Turley 04.22.09 at 13:42
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.
Gene Harris 04.22.09 at 21:40
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.
ekzept 04.22.09 at 23:29
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.
John 04.22.09 at 23:42
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.
ehhh 04.23.09 at 02:54
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.
ekzept 04.23.09 at 08:39
@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.
John 04.23.09 at 08:52
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.