After decades writing, designing, documenting, and diagnosing software, I guess it's time I sat and wrote what I've found out about it. It's not that I feel so completely capable. I don't I'm not good at writing. But I guess, I've tired of watching people propose more and more outlandish things for developers to attempt.
Development strategies seem to have focused on the architecture. Structured programming was fine, but then object orientation tried to compartmentalize on all the complexity there. Which was fine, but for a smaller subset of development. 4th Gen languages tried to simplify further, but fell by the wayside doing so. UML has has some better success at visualizing the software, but it doesn't seem to have dealt with its complexity. MVC(D) models restricted themselves to the browser model of doing things, again focusing on only a subset of the development that has to be done to get things done.
And really, after all -- isn't that what software should do? Get things done?
Yet we don't focus on that. We focus today on how we're going to stuff the request to get things done down to the component that gets things done. In doing so, we spend a lot of time communicating the request. But not much time on the work.
There are admittedly some great systems for getting this communication across. My particular preference is for IBM Domino. It allows me to spend far less time on the packaging and far more time on the product. But even then, it's easy to get distracted into all the facilities for making a good package.
Don't mistake me. It's kind of silly to say you don't need good communication between client and server. You do. You need it badly. But that packaging had better be easy to replicate & reuse for any application, or it's useless. We can't afford to rewrite an interface for every application. It's simply too costly.
So I would recommend you find a package that costs a minimum of code and effort to create a user interface. Plus a minimum of effort to send communications to your model. You all know MVC(D) ... that's the VC part of it. You should be able to minimize your time there. It simply shouldn't be hard or long or take time for these pieces. If it does, you're not getting the customer's job done.
Development strategies seem to have focused on the architecture. Structured programming was fine, but then object orientation tried to compartmentalize on all the complexity there. Which was fine, but for a smaller subset of development. 4th Gen languages tried to simplify further, but fell by the wayside doing so. UML has has some better success at visualizing the software, but it doesn't seem to have dealt with its complexity. MVC(D) models restricted themselves to the browser model of doing things, again focusing on only a subset of the development that has to be done to get things done.
And really, after all -- isn't that what software should do? Get things done?
Yet we don't focus on that. We focus today on how we're going to stuff the request to get things done down to the component that gets things done. In doing so, we spend a lot of time communicating the request. But not much time on the work.
There are admittedly some great systems for getting this communication across. My particular preference is for IBM Domino. It allows me to spend far less time on the packaging and far more time on the product. But even then, it's easy to get distracted into all the facilities for making a good package.
Don't mistake me. It's kind of silly to say you don't need good communication between client and server. You do. You need it badly. But that packaging had better be easy to replicate & reuse for any application, or it's useless. We can't afford to rewrite an interface for every application. It's simply too costly.
So I would recommend you find a package that costs a minimum of code and effort to create a user interface. Plus a minimum of effort to send communications to your model. You all know MVC(D) ... that's the VC part of it. You should be able to minimize your time there. It simply shouldn't be hard or long or take time for these pieces. If it does, you're not getting the customer's job done.