The basic software stack contains the most generic code on the bottom with subsequent higher layers getting more specific (through business logic and APIs) until the most specific code resides in the UI, that hopefully solves a specific problem.
The problem is that, as good little OOD engineers we just love re-use and generic all-purpose code. We are always looking to making our logic, features and code as generic as possible because we just know that we may re-use it sometime in the future (yeah sure!). Sometimes we try to push the generic code up through the layers and expose them in the UI, you know, because we love re-use and such. It's in our nature. Because we are sure the user will understand and love our code too. We just have to convince them what a great feature it is and how it benefits them.
We add complex syntax, tools and options galore so they can do almost anything, except solve their problem out of the box. Simple for the developer, lousy for the user.
We don't just do this to our users either, we do it to other developers too. Ask for an API to do X and we may get an API back that does (a+b+c+z) so that we can get to X, because it's more generic, it's better. The closer the code is to the end feature (UI, Service API, presentation, etc.) the more specific it should be. At this top most level we should not be trying to write the next great tool or concept, but a solution for the user on the other side.
This is yet another area where you have to separate your desires from what your users need. Your personal goals != User needs.
Comments
Post a Comment