Friday, November 10, 2006
Frameworks or Flameworks?
One of the guys at Readify (Andrew Matthews) recently posted to the Tech list referencing a snippet from old posts/emails:
"most code is the expression of desires through the expansion of code (design patterns) with metadata. Name anything that you have written lately that wasn't like that to some extent."
To which Andrew asked:
"If this is true, and we were ever to find a way to represent our desires more precisely/succinctly, what would be left of our day jobs? Could we ever boil our practical work down to JUST coding the business logic and nothing else? What kind of development environment would we need to be able to do that? Would you want to work in that kind of environment?"
I made two replies to this thread, to whit:
"The real question is do you think that business requirements will ever allow us to only code within a sandbox/framework?
I haven't been in a single environment where the business needs haven't pushed the envelope of cost/time/performance, which usually requires custom solutions, or out-of-the-box thinking."
and later..Andrew asked me if I thought it would be possible in the future to code entirely "in-the-box"..
"I doubt it. Frameworks try to cater for a broad spectrum of requirements and functionality, sort of like a blanket solution. Because new technology gets developed almost dynamically (read: very quickly) I doubt it would be possible to keep up with the day to day (or even month to month) demands of more focused business-specific technical requirements.
My view is that emerging technologies make it easier to develop complex solutions faster (RAD) and can remove some of the time consuming burdon associated with more common tasks/functionality/requirements. This has certainly improved dramatically over the past 15 years.
Then there is the real crux of the matter: if it was just a case of writing business workflows, it'd take all the fun out of programming."
What do you think?
Posted at 10:30 am by ausrob2003