A rootin', tootin' new article entitled "Evil Technology Rant", written by Max Habibi, appears in the latest issue of the JavaRanch Journal. You kin check out that there article here. Y'all have anything to say about it? Say it right in this thread!
Uh yeah. I've said for years that good programming solutions are the ones that when finished, are so clean and self-evident that people look from the big pile of requirements to the end code and ask what the big deal was in the first place.
Unfortunately there seems to be a corporate culture that rewards complexity for it's own sake -- "real" programmers being those that we're afraid to lose because of that critical-but-cryptic application.
Gods forgive me, I did once, sneering, ask was I supposed to "code for the lowest common denominator"? A couple years on call taught me the lowest common denominator was me, after last call.
I apply a kind of combined bauhaus and shaker ethic to my code. And what remains is that which is necessary and beautiful, and rarely causes a problem in production or with extesibility.
I was always taught that the best engineers find the right balance/compromise in complex, multidimensional situations. When approaching a project, problem, question, etc. many decisions must be made. How much will it cost (in money, time, people, etc.) how important is performance, scalability, security, etc. What is the scope now, and what is the projected scope in a year or in a decade? Many such questions with complicated, often contradictory implications must be resolved. How does this affect the usage of Spring or other frameworks? Well, before you consider that question, you must have already answered a more basic one, Java. Why bother with an inherently slow, half compiled bunch of crap that can't even run directly on the system? Why don't I just write it in assembly? Since the advantages of Java have been thoroughly explored by those far better then myself and are wholeheartedly embraced by me, I won't enumerate them here. But, now that you are in Java, or more specifically, J2EE, you are faced with more narrow, yet non-trivial concerns. Should I use EJB, Spring, JSP, ... (a myriad other choices), or just plain old servlets with some nice printouts? Why should I learn to deal with all those pesky JSP tags when I can just print my html straight out of the servlet? Well, if you're writing a very small app which you do not expect to grow, it may very well be the better solution. If the size of the app, future concerns, etc. ... merit the use of JSP, you use JSP. BUT, if you're writing an application where you need to access multiple databases (which implies that the code dealing with just the db issues alone will take up half the time, code base and future bugs), if your transactions span multiple servers (and maybe countries), if you have a 100+ complicated pages (which in JSP start looking like spaghetti, but in tapestry can actually be coded and debugged effectively by your very thankful combined team of software developers and artists/html coders) and you could really use AOP because your logging, persistent audit logging and a few other things take up the other 20% of your code and resources, you will think frameworks are miracles, gifts from god handed to you at the small price of having to know a few proprietary things, some xml and obeying some conventions.
Joined: Mar 24, 2005
There is another point in your article which really enraged me. The XYZ you speak of which you claim can do the 90% of the work is still there, untouched, ready and willing to be used. Why, then, do you criticize the ZYX? I could understand your complaint if the implementation of ZYX took away XYZ, BUT IT DID NOT. Maybe it took away focus from XYZ, because many people believe that XYZ not really responsible for the 90% but more like 50-60 and because whatever the XYZ does not cover (be it 10% or 50%) is a real pain in the ass that takes a lot of time, headache, etc. You are still able and welcome to use XYZ, but a great lot of people appreciate the option to have ZYX as well, because it alleviates their suffering. The ZYX is not there for the bells and whistles, it's not there to be flashy, to increase complexity, weight or to obscure code. It's there to be used in those cases where it will ease the pain, reduce the complexity, the code base, etc. And that simple craftsman you speak of must be a simpleton if he acquiesces to using a complex framework where it's not needed. That's like using a 100 yard, 1000 ton crane to build a single family home. Perhaps the simple craftsman is not so affected by others because they use frameworks, but because he has no projects that merit them. It sounds like he wishes he were building something that could use the big crane, but not having any such projects, he misuses it to build the simple house while shaking his head and sighing about why the hell did anyone build such a large crane and why does everyone love it so much when he knows he could very well do his job without any crane, never mind such a monster. Perhaps he needs to see a psychiatrist.
first, I want to thank you for contributing feedback here: Javaranch is a friendly community of engineers, and we try to open up our ideas for useful discussion. As one of the moderators here, I help enforce that policy. Now, I want to talk about some of the interesting and valid points you raised.
I was always taught that the best engineers find the right balance/compromise in complex, multidimensional situations.
We must have gone to similar schools: I was taught something similar. To wit, use the simplest thing that works.
Since 'right', 'balance', 'compromise','complex', etc are highly subjective concepts, I was taught to work for an objective goal: meeting all of my requirements, and being able to justify all of the complexity directly towards my requirements.
Why bother with an inherently slow, half compiled bunch of crap that can't even run directly on the system? Why don't I just write it in assembly?
It seems that you're suggesting that since the use of Java over assembly is justified, then, correspondingly, the use of complicated frameworks over less complicated frameworks are similarly justified. If I'm reading you correctly, this is, in essence, argument by analogy. I'm not convinced that the analogy holds, either generally, or specifically.
In general, the usage of one expenditure does not justify a second expenditure. Just because you choose to have an expensive steak one night doe not mean that you should do so ever night.
Specifically, in comparing Java to Assembly, I would argue that Java is significantly easier then Assembly: both to learn, and to use. Granted, this is a subjective judgement, but it's one I would be willing to defend.(in another thread, of course).
if you're writing an application where you need to access multiple databases ... if your transactions span multiple servers (and maybe countries),....if you have a 100+ complicated pages.... and you could really use AOP because your logging, ...and a few other things take up the other 20% of your code.... you will think frameworks are miracles
There are a lot of ifs in that last statement, followed by an assumption that is not based on objective evidence, AFIK: there is no evidence so support the contention that I would be glad about this-or-that, or [for that matter], that I might resent the limitations of the framework.
Of course, some frameworks are better then others, and, of course, it's always possible to contrive a context in which the framework in question is the only thing that works. As a matter of fact, there are often legitimate context in which a given framework is a perfect fit.
But generally, it seems to me, that simple answers are better then complex answers. A Einstein said: Everything should be as simple as possible. But no simpler.
There is another point in your article which really enraged me. I'm sorry to hear that: I certainly didn't mean to upset anyone with my thoughts.
The XYZ you speak of which you claim can do the 90% of the work is still there, untouched, ready and willing to be used. Why, then, do you criticize the ZYX? As an engineer, I dislike things that do not have a function. If ZYX is not solving a problem, then it's just fat, in my opinion.
Maybe it took away focus from XYZ, because many people believe that XYZ not really responsible for the 90% but more like 50-60 and because whatever the XYZ does not cover (be it 10% or 50%) is a real pain in the ass...
Except that it's not: remember, I was the one that came up with the analogy . If you're talking about a case where the ZYX is 50%, then you're not talking about the article I wrote.
And that simple craftsman you speak of must be a simpleton if he acquiesces to using a complex framework where it's not needed....Perhaps he needs to see a psychiatrist.
well, maybe. Actually, I'm sure of it. [ March 27, 2006: Message edited by: Max Habibi ]
Hey Max, No need to apologize for angering me with your article, I just took it personally, but that is nothing you should feel bad about.
I went to MIT. I agree that you must justify the use of anything towards your requirements/solution; I argue that the high price you pay for the frameworks can be justified in more cases than your article implies, but I concede that it is not always justified in the real world solutions (in cases where it could indeed be replaced by something more simple, cheap and straightforward) (also in those cases, the motivation sometimes is to show off , though not always ).
Is assembly really harder than java? It may be harder to use well and effectively, but is it harder to learn? I don't really want to argue this one. You did dissect my analogy correctly, except I did not make it as general as you imply (or as your article, which sort of is the crux of the whole discussion, I think your article was too general). Permit me to use your food analogy: as long as I can afford and justify it (get what I pay for), I will eat steak one night, foie gras the next, hamburger the next, truffle paprdelli .... But, I will neither eat it solely because someone recommends it (or eats it) or advises me against it (or avoids it). In other words, I guess, if the problem I am solving merits the use of some complex tool, I will use it.
The example I gave was just an example, and it did have a lot of ifs. I should have said that I felt like Spring was a miracle when I discovered how helpful it was in alleviating my pain (instead of saying you would). I love that Einstein quote, and I thought about using it myself before for the flip side -- I think that ALWAYS avoiding ZYX is trying to make things simpler than possible (or at least simple at a very high price).
As an engineer, I dislike things that do not have a function. If ZYX is not solving a problem, then it's just fat, in my opinion. The point I was trying to make is that the 10% is not just fat, but addresses real issues and helps solve real problems. And they happen to be very painful problems, like database or transaction management.
Except that it's not: remember, I was the one that came up with the analogy . If you're talking about a case where the ZYX is 50%, then you're not talking about the article I wrote. Correct me if I'm wrong, but the way your article starts out, it seems to critcize the very creation of ZYX ("But being tinkerers, they could not stop pushing & probing ... never mind that the language is able to do X,Y, and Z. It is much more impressive to make it do Z, Y, and X ...."). That is a very general attack on the existence of frameworks, externalization, etc. While I agree that misusing heavy-weight tools where they have little impact but a huge cost is basically stupid (and should cost an engineer his job if his only reason is showing off), I disagree that these tools are useless fat in general. My construction analogy again: it would be stupid to use a giant crane while building a little house, but it is equally unwise to claim the crane is just a useless heap of metal and Scania should have been happy with all the little cranes thay had which could do 90% of the world's construction work, but they had to tinker around and build these huge heavy giants just to enable people to do the remaining 10%. There is an incredible amount of overhead, time, price, preparation, etc. involved with using a very large crane, but the alternative is building the Empire State Building by hand (well, at least the top 75% where a crane analogous to JSP will not reach).
Joined: Jul 18, 2001
Originally posted by Emanuel Kadziela: The example I gave was just an example, and it did have a lot of ifs. I should have said that I felt like Spring was a miracle when I discovered how helpful it was in alleviating my pain (instead of saying you would). I love that Einstein quote, and I thought about using it myself before for the flip side -- I think that ALWAYS avoiding ZYX is trying to make things simpler than possible (or at least simple at a very high price).
The key here is to remain objective and not become fanatical about any particular technology. I am a big fan of Spring and as a project it has had a huge influence on the programming practices of the Java Community and the direction of J2EE. However, Max is entirely justified in critizing Spring MVC... it one of the worse MVC Frameworks available.
Use Spring for what it is good at: Dependency Injection, JDBC, ORM (Ibatis, Hibernate, JDO), Transaction Control, and Remoting. Leave MVC to the WebWork, Tapestry, and Wickets of the world.
Emanuel, nowhere does Max state that the use of complex solutions is never justified. What he does say (and I agree with him wholeheartedly, having seen it in action regularly) is that in many environments (and the larger the company involved, the more likely it seems to be that that's the way it works) complexity is equated with quality. So a small, lightweight, solution cannot possibly be any good BECAUSE there's a heavyweight solution available as an alternative. So massive EJB based applications are created for things that could have been done for a fraction of the price using just a few servlets calling Hibernate. One project I was involved in myself was running just fine using just servlets and JSP on a single midrange machine (with another similar machine to run the database). The solution recommended for the next phase of the project (which would add maybe 10-20% to the codebase and load) by the highend consultancy firm brought in involved 5 highend servers just for the web frontend, another 3 for the database. As the project team we immediately set out to write a competing project plan which showed quite clearly that the completed next phase could run with no problem on the existing hardware (plus database and application server software) and would take about 20% of the development effort from the original proposal. Total savings for our simpler solution would amount to something like �5 million for the development and deployment phase alone, never mind the maintenance phase.
Around the same time the Gardner group published a report which estimated that the unjustified use of EJB technology was costing US companies an estimated $2 billion a year over what they would have spent had they used more appropriate technology (this was about 5 years ago, the figure would be several times higher today I think).
That's the kind of thing Max is talking about, the use of complex solutions for complexity's sake rather than because they're the best solution for the job at hand.
I have to say that I very much agree with the article and also agree with Jeroen. It really put a smile on my face. I think that it is less a criticism of frameworks and more a criticism of large companies and their attitude and reactions to the latest technological fads.
Currently I am working on a set of requirements for an industrial water company that requires GPRS wireless module attached to water meters to send their collection data back to a centralised server. The server is to collect this information and convert it into comma seperated text files which are to then be manually copied and fed into the company's CRM billing system. Since these Wireless Modules are battery operated they are limited to an absolute maximum of 5 sms messages a day or equivalent GPRS connections. Realistically they will send their data from their sensors once a week. Currently they have 100 Wireless Modules.
We knocked up an application that did all that was required using JSP, servlets, JDBC with a MySQL database and JFree chart to add some reports (managers always like their 3D Pie charts) within two weeks.
Our project manager was not happy. Oracle ADF, My Faces, Hibernate and JBoss are to be the technologies utilised. Extensibility, failover and quality were all reasons cited why are solution was not good enough. When I suggested that this was over kill and added too much complexity, the response was: "Whatsamatta, you're intimidated by a little complexity"
We are now two months into creating an application that meets said requirements. We have bugs galore, transactional deadlocks in the database, wierd navigation through the web application. A tangle of Java Script, XML configuration files and jsf files with expressional language. In a recent meeting, since we are over running our deadline, it has been decided to cut down testing time....oh and told to consider AJAX within our implementation (uttered in the same sentence).
I wonder if Max happened to, either work in the same company as I am in now, or just had the same project manager as me ;-)
Evil Gnomes lurk everywhere. The responsibility for your company (or team) is to employ a Good Gnome. The Good Gnome understands what the Evil Gnome is up to and, while skeptical, evaluates the Evil Gnome's offerings as it pertains to their particular situation -- especially if it has far reaching consequences.
The Good Gnome acts accordingly, and nixxes the offering where appropriate. The Gnomelettes who *actually have to do the work* are joyous. And the Good Gnome then fights their evil captors (management) to allow his subjects ongoing freedom to do what is right.
The moral of this story should be: if Evil Gnomes prevail, then you have a Good Gnome shortage and your kingdom may fall into the fiery pits of hell.