Calculating the Technical Debt of Delaying Your Thesis
Yesterday I went to hang out with my friends, fellow final-year students. There was one friend of mine who was extremely relaxed. He said his thesis is still on chapter one, but he will just do it a month before the deadline using the Overnight Cramming System. He felt confident because when doing regular coursework papers, he always successfully applied that system and got decent grades.
Hearing what he said, I immediately facepalmed. This guy seemingly does not realize that he is hoarding something that in the software engineering world is called Technical Debt.
Here is the thing, in software development, sometimes developers intentionally write bad, messy, or unoptimized code just to catch a tight release deadline. The code works, but it leaves a technical debt. Just like my friend who delayed writing his thesis. He gets short-term profit in the form of free time to play games or hang out, but he leaves a massive debt in the future.
The problem is, technical debt is not linear. It uses a compound interest system.
If you delay writing one paragraph today, tomorrow you not only have to write that paragraph, but you also have to recall the context of the journals you read, search for references whose links you forgot to save, and gather motivation that has already faded. The cognitive cost needed to start working (context switching) is much more expensive than doing a little bit every day.
So what happens when my friend actually applies the overnight cramming system a month before the deadline?
His brain server will experience severe bottlenecks. He will force hundreds of scientific journals into his short-term memory. He will stay up every night drinking coffee until his stomach sends error logs in the form of chronic ulcers. The quality of his writing will plummet because he has no time to refactor the structure of his arguments.
His thesis might get finished, just like the software that was hastily deployed earlier. But when it enters the testing phase (aka the thesis defense), the examining lecturers will immediately find dozens of fatal bugs: the theoretical foundation does not match the methodology, the bibliography is not formatted correctly, and the hypothesis makes no sense.
The result? Massive revisions that take longer than if he had done it bit by bit from the start. And because the revision time is close to the graduation deadline, his stress level will hit a limit that breaks his patience API.
So, for those of you who are currently thinking about delaying your thesis because you feel you still have a lot of time, please recalculate. You are borrowing energy from your future with an unreasonable interest rate.
It is much better for you to apply the continuous integration principle. Every day you allocate one hour to write, or just read journals and note down important points. Commit small changes every day. This makes errors or dead ends easier to spot and fix early. At the end of the month, you just merge all your writings into one neat chapter without feeling like you are about to die.
Stop being a stupid developer for your own life. Pay your technical debt now before your server actually crashes during your defense.
- Khay