Member-only story
Let’s Bring Back Documentation In Software Development
In the early days of my career, I was mocked by my teammates for being a documentation guy. My task involved creating a bunch of documents depicting user stories, and nothing else, for weeks.
The task was purely verbose. It bored me so much, that I almost left my software career. I pleaded to my boss to assign me some real coding stuff.
To my surprise, he put me into an elevated task:
Write functional and technical specs.
Being a beginner, I hesitantly concurred, but later on, I began to understand the fullest extent of its potential.
I appreciated it from the bottom of my heart, for it played a very crucial part in formation of a programmer: myself. The only part that was left to accomplish was coding by hand / copy-paste from reliable source.
That final part, as I realized, was only 20% of a programmer’s daily routine. I had already surmounted 80% during documenting.
Why Is It Fashionable & Trendy To Hate Documentation:
Every time there is discussion about software development life cycle, developers and project managers are divided into two camps: Waterfall vs Agile.
Since Agile has somehow positioned itself as ultimate cost-saver by validating frequently and delivering early, documentation has taken a backseat due to it being primary ingredient of waterfall model.
Besides, it appears to be adding no tangible value to the end user.
Efficient coders publicly hate documentation. They discuss the design in team meetings. They will fill up a whiteboard in 3 minutes. But they won’t document.
But their reasons for hating documentation are sometimes creepy.
More often than not, rockstar developers are fearful of putting their take on a design decision in a document. A document that can some day come back and haunt them.
They publicly advocate and demand on jumping on the real thing, instead of wasting ePaper.
