Accountable Code

I often lose the plot about why a bit of code was written. The business context or the problem domain is important to remember especially when you want to refactor something fast. Why did you decide to do it like that in the first place? Have you often changed something only to discover that it was right the first time? You need a way to quickly get all the balls back into the air fast. What were the business needs behind this coding decision? Here The Goo helps by sticking together: The Pain -> The Problem -> Your Code. So you can link back in time to why you did something (or someone else in your team for that matter).