I’ve got bad news and good news.
Also available in Czech, kindly translated by Aleš Roubíček
Writing Legacy Code* is a distributed activity.
*In Working Effectively with Legacy Code Michael Feathers defines Legacy Code as “Code with no tests“, which reflects the perspective of legacy code being difficult to work with. I’ll stick to this definition.
Oh, no! Bad code again
You have been assigned a new task.
Your mission: to add a simple feature to a Corporate project. You know almost nothing about it, but the feature request sounds feasible. You can easily accomplish the task.
This is what you think. Until you open the code base.
I agree with Michael Kennedy when he says that Software Development could be modeled as a Knowledge Discovery Process, “the process of going from 0% knowledge about an idea to 100% knowledge of a finished product ready for delivery to a customer“.
I agree so much that I decided to adapt my future Daily Scrums to this.
Well, if only I had seen then what I saw today, I would have used in my talk, since I think it would have been the perfect example.
See what I found in a recent production code.
Right now, it hangs on the wall of our open space, for all the developers to see.
Rule #1: write commit comments before coding
Rule #2: write what the software should be supposed to do, not what you did