http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I very much agree with this post, having the experiance of working with a tool like you're describing (PNM Sequence if anybody is interested). One fact i think you didn't mention, is that sometimes those tools have very poor performance, or cause a lot of security risks for the application. The even bigger problem, is that because real developers are not always invloved with the development, it could be that no one will realize the security threats. The software i worked with, is a BPM tool that is actually very successful, and it gives you a designer to design a buisiness proccess, including desiging screens. It also lets you write javascript for those screens (in an ugly and anoyying notepad like window). The big security problem, is that the "para-programers" as you call them, had to do validation on the input data!!!! of course they can only write javascript!!! i guess every developer can see the big security issue with with validating only at the cllient side, but because no real developer had ever looked at whats going on there, no body even realized there is a problem. everyone just saw how the input is validated correcty... http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment18http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment18Tue, 07 Sep 2010 20:28:25 GMTIt's just natural evolution. Read the history of Computer Science, we started with machine language. Abstracted that into a more usable set that a larger amount of people could understand. Rinse and repeat. The key here is the free market knows that there aren't enough great technologists to serve the demand for solutions that exists. We are going through a revolution equivalent to the Industrial Revolution right now. Developers must think differently and build tools that let less talented and skilled people accomplish something of value. Why? Because there aren't enough smart people to build all of the applications the world needs. http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment17http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment17Sat, 04 Sep 2010 14:51:02 GMT@Daniel Interesting thought... Biology values heterogeneity, the other sciences (esp. math) like homogenius solutions... Yet another impedance :) Si http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment16http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment16Sat, 04 Sep 2010 00:23:06 GMTI think the software will evolve to something like living creatures. We can see too much similarity, too much similar issues and solutions. Encapsulation (cells), Inheritance etc. Denormalization (actually brain stores data denormalized too) It's bad we do not have enough time to study biology. I believe we could learn a lot from that. http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment15http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment15Fri, 03 Sep 2010 23:58:48 GMTOh one more impedAnce is my lack of spelling ability... still optOmistic though, that Oren's rewritten blog software will have spellchecker :) http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment14http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment14Fri, 03 Sep 2010 21:38:28 GMTAs an optomist, I'd say the issue is that no-one has found the answer yet, not that it doesn't exist !!! OO to Relational databases is just ONE of the impedendance mismatches we face on a daily basis... We have the whole language mismatch mess of T-SQL -> C# -> XML -> XSL -> HTML-> CSS -> JS Each language interface is an impedence (I'll exclude Linq here, as IMO that is yet another sublanguage thrown into the mix :( ) While we are on the subject of language impedence, probably more important is the interface between "operational person" to developer. Dig further and let's not forget classic OO doesn't solve the impedence mismatch of real world vs computer models of objects over time (real world things change over time, without being versioned controlled, IMHO computer science OO works for things that have lifecycles that are measured in the lifetime the program.) Then when simple things like why the heck when using new() {something = "fred", somethingElse = "bob" } the seperate parts are comma seperated, not semi comma seperated is completely beyond me. (Whilst we are on the subject... why require ";" FFS that was required when compilers needed every line terminated to gain the last ounce of a z80 chip... ) It feels to me at least we are operating in Ptolemy's realm... one day a modernday CS Copernicus will come along.... ....well as long as people keep searching for it!! http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment13http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment13Fri, 03 Sep 2010 21:17:44 GMTIt could be called "The Law of Conservation of Essential Complexity" as well. http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment12http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment12Fri, 03 Sep 2010 16:58:28 GMTThe issue is complex systems are just that, and while you can shift the burden of that complexity around, it cannot be eliminated. The problem in attempting to 'hide' complexity to shield a large percentage of developers (para-developers) from it is it means you are making the system way more complex for some other percentage of developers (framework / product developers). The other effect is the process of 'hiding' complexity invariably involves limiting a system's exposed capabilities - you see this in discussions such as Oren's [ORM] comments about using repositories versus just using the session directly, or in architectural decisions driven by the question of how best to utilize a given mix of junior and senior developers. Once you understand you can't eliminate complexity from systems then it's more a matter of determining who really needs to be shielded from it and onto whom the burden of complexity is going to shift - and at what cost. For me it's a more a matter of resource utilization / optimization, and one in which the business case needs to be examined very carefully before embarking on grand efforts to shield the masses from inherent complexity. http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment11http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment11Fri, 03 Sep 2010 16:39:05 GMTAlex, how about "undeveloper"? ;-) http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment10http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment10Fri, 03 Sep 2010 15:15:35 GMT@Steve, I cannot agree more with the fact that you cannot solve complex problems with easy tools. And that even trying to use those tools essentially set you off in the wrong direction making it even more complex and hard to maintain. I am currently working (with a team) on a framework in C# for building complex, datacentric business applications. The framework lets one define a UI in an abstract sence, so no designers (yet :)). Also data and functions are abstracted and can be run on every tier. There is some resemblance with lightswitch, but I think we are more flexible and open. The tradeoff is that is more difficult to develop a system in this way. But so far we have come a long way. http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment9http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment9Fri, 03 Sep 2010 15:01:37 GMTRene, It's not just Lightswitch, I believe Oren is referring to the fact that the "easy" stuff is easy, even for the most junior developers as long as they have even average (or barely below average) skill. The problem is, nothing is as easy as people think once you get beyond the simplest of applications. So these tools (be it data access or coding tools used by Quasi-Developers) rarely have much value since they, in themselves, are only doing the "easy" work. Once you get a semi-complex scenario, toys that do data access or generate code mostly end up causing more problems then they solve. http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment8http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment8Fri, 03 Sep 2010 13:54:32 GMTThis is due to people watching too much Star Trek where they say stuff like "computer, simulate a space shuttle in the holodeck" and boom, there it is. A fully functional space shuttle. http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment7http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment7Fri, 03 Sep 2010 13:25:15 GMTPara-developer... I think better term would be Quasi-developer :) http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment6http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment6Fri, 03 Sep 2010 13:16:37 GMT@ scooletz - on the flip side, if we didn't reinvent wheels, we'd be driving on stones. I'm okay with letting a free market decide what tools make it and what tools don't. Of course, as developers, we're all very opinionated about what tools should make it and which ones should die a horrible death. Tools and frameworks like Webforms, Zope, and Rails, and Naked Objects all have their grand promises and very real drawbacks. The key to being a savvy developer is recognizing them quickly and accepting or rejecting them based on the right tradeoffs *for the current problem domain*. Sometimes, you go with a technology not because it's the best, but because there's a huge job pool or technical resources available. Sometimes you hold off on a really promising technology because it's not mature enough for your risk tolerance yet. And sometimes, you stick with what you know because you know it well because as Phil Haack claims, "We're not here to write software, we're here to ship products and deliver value. Writing code is just a fulfilling means to that end". http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment5http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment5Fri, 03 Sep 2010 12:42:39 GMTI guess you are talking about lightswitch? I personally believe we can do better than the current state of art in programming. There will be a new system, which is better for building business / data centric applications. There is currently way too much repitious work for developers. Of course there will be tradeoffs. Most probably losing the ability as a developer to do everything with 'designers'. http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment4http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment4Fri, 03 Sep 2010 12:07:10 GMTSorry a little unclear with my above post... my team lead thinks his idea is always better and is scared to use anything ORM like... http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment3http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment3Fri, 03 Sep 2010 10:15:50 GMTSounds like my team lead, I wrote to Oren a few weeks ago...seems his solution is always better than what is already is there... very frustrating! I agree with points above for sure! http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment2http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment2Fri, 03 Sep 2010 10:14:36 GMTReinventing wheels of any kind is extremely common. There is some kind of religious movement in developers' world making us think, that there is a Holy Grail which allows us to build the ultimate solution. I'd add that the same movement creates false truths as 'ORM are horribly slow', 'I can do it better ' (in terms of log4net) and so on http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment1http://ayende.com/4617/the-law-of-conservation-of-tradeoffs#comment1Fri, 03 Sep 2010 10:02:23 GMT