Have you ever had this argument about existing code, when someone is trying to prove to you that you have a bug, you are arguing that it is a feature, and both sides realize (after extensive archeological dig through existing documentation) that the reasons behind this code’s functionality have been lost to time?
The better question is not “have you ever”, but “how often have you had this argument”. All architects experience this at one time or another, wondering what were the motivations for a decision, what were the assumptions or constraints at the time, and was there an explicit decision to begin with. While we all recognize how important decisions are in software architecture, we don’t often have a framework for identifying and making architectural decisions.
In this talk, I will introduce a step-by-step guide that will help you identify, frame and make decisions about your software architecture that will leave no room for “it’s a feature, not a bug” arguments.