Sometimes the problem is to discover what the problem is (part 1)
![Image](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6Ygi1goAKoq1EcYrGqOYj8_F9jXHIpeSBVryTGX9MHqvm9tue6hDYtuVw39Uq5XvPiLkAWHaqKmouGElk6av2l99An_KuMS4tbxgeSk1AXTG9J5UG18ipMqafPiS1zmgtBP79lD6BlmHbvaK9tF11Ntpotdxp1DNrpozQbvpgUyns2pbVkwqSRb9iIA/w640-h406/slide_2.jpg)
"Sometimes the problem is to discover what the problem is." (Gordon Glegg, The Design of Design , 1969) As software engineers, we often frame problems poorly. Sometimes we frame problems in a way that is inflexible, overly-literal, convenient, laden with implicit assumptions or just plain wrong. The financial impact of this can be enormous: undertaking the "critical" re-platforming project that never finishes, grinds the business to a halt and causes a company to lose faith in its engineering organization; building features that are well-intended but barely used or even worse, ripped out, because they were poorly conceived; slower time-to-market and reduced revenue for those capabilities that are actually needed; and finally, we drastically reduce our potential effectiveness as problem solvers and most of the time we don't even realize it. Like high blood pressure, poor problem-framing can be the silent killer when developing software: it can destroy value deli