Regarding the topic stuck in “P” mode, I forgot I posted a comment on another blog here. Yes, it is an interesting article worth reading. In my experience I’ve worked on several different applications where the “tool” was prioritized over the user. Take my prior job for instance. I recall many meetings with developers instructing customer service support with sentences that begin with “alls yuh haff tuh do is…”
…I hate that sentence! It’s the prefix of an incoherent explanation that defines a complicated program model that falls nowhere in the ballpark of the typical user model. User models tend to be simple. Many of us developers tend to add complexity to these simple models to justify the misdirection of our development practices. A simple user model could be something like, “I need to print customer addresses for shipping labels.” A typical misdirected developer extrapolation would begin with the muddy details of existing (bad) code that prevents access to access to the address for customers outside of the context of an opened order. Rather than focusing on the need of the user focus is placed on adding features to (read poking holes in) the “tool” to support printing shipping addresses. Complication is added through the introduction of a feature that allows an order to be quasi-opened or pretend-opened. The feature complicates other order processing done in the warehouse as people wanting to close orders get locked out due to the pretend-opened order on the other workstation on the other side of the warehouse where a missing shipping label needed to be reprinted. That creates the need for another made up “feature” that allows users to close orders that are opened elsewhere. Now you have “close” and “force-close” options in order processing and a need to explain the difference. The sentence structure you choose will no doubt start with, “alls yuh haff tuh do is…”
I wrote this short post many moons ago but it still rings true. To add clarification to the “poking holes in” comment above, developers typically poke holes in a crappy program component that doesn’t follow OCP. These holes are work-arounds to the cancer of bad design that nobody wants to touch for fear of the entire application toppling over. We poke holes to add back-door features then we instruct others with “alls yuh haff to do” then the most arrogant of us will grimace when a consumer of our product is puzzled to our overly complicated design. Don’t act like it’s just me. We all over-engineer I’m just the first to admit it!