>>>Look, a person can invoke all the "white coat" images they want. The fact is that there's very little in the way of market pressure towards the commoditization you describe. Actually, the market pressures are quite the opposite.
>
>Yes, but there was no "market pressure" for Android either according to some people, until after it was too late. There was no market pressure for Netscape according to some people who would have been toast if not for leverage of OS dominance. The wagon to which you are hooked, cannot do that today. Only Google could and they haven't had to play the card yet. "Market pressure" just means people filling out triplicate forms because that's the way it's always been done, until one day it's not. A medical equivalent would be people expecting to be paid a bomb to mix fillers differently to make the same medication tablet.
>
>>>And I'd like to think I provide quite a bit of versatility to clients - and also yeah, in the year 2014 receivables are "quite the bomb". Lots of milkshakes for the family. :)
>
>You'd need to ask yourself why customers need "versatility" and to whose benefit is the need to be "versatile" rather than tried and true commodity? Versatility in car mechanics would prevent the 25K mile "first service" advice that is becoming the norm rather than constant tinkering by mechanics who need only display competence to be sought after and highly paid to keep your car from breaking down. Sorry but complexity needs to increase reliability and reduce labor (look at car mechanics again and most medical technology) and while IS may have gotten away with the self-serving opposite for years, you need to accept that the IS equivalent of engines ought to be a commodity that "just works" same as your new Mercedes'.
>
>Also FWIW, recently there was a conversation with an ambulance-chasing lawyer who was appalled to hear how the rest of the world handles healthcare funding and tort. According to him, ambulance chasing is the pinnacle of life's endeavors and he is needed to keep the market honest. I read it as rationalization of blatant self-interest and chose not to debate
>
> You're smarter: take a step back and ask where things are going. For example, say Cloud does prevail and databases become mysterious entities dwelling in the distant ether maintained by who knows who, with "good enough" business product offerings that may not be versatile, but do a workmanlike job at a fraction of the cost. The decision for business then is: does bespoke art improve the company's competitive position? If it does, then fantastic- but commodity will gather that into itself unless people truly are coming up with new paradigms rather than shuffling the chairs around the table.

re: bespoke vs "good enough" -- 16 years ago, my day-job company decided to go after the Enterprise Market, having done well with the High Fashion store market, and other single or few-store venues. Now we do 17-site, several hundred store enterprises, and are about to roll out the first wave of an 1,100 store enterprise.. The customer is not buying "good enough" in this case -- they can get whatever they need. They are buying the best product on the market for their needs. I mention this to point out there is something between "bespoke" and "good enough" -- it's the domain developer product refined over many years of working with customers in a given business context. In this case, the domain experience goes back 27 years.

The key to domain-expert development is to give the domain developer tools that allow the job to be done without becoming a technical expert. We did that in VFP, and we are in the process of doing that with Lianja. Next year we have road-mapped 8 add-on mobile apps to be developed and deployed in/on Lianja, with the first due to hit sometime in January. In 2016, we will bring the full product to small customers, and in 2017 to the Enterprise. All of this will be done with a 1-pizza development team (including me, and I don't do domain development, just the technical stuff they use), 2 pizza's if you include doc and qa. staff.