tag:blogger.com,1999:blog-8655567.post383333024755720863..comments2023-10-30T01:48:47.905-07:00Comments on Panic From Fuzzy: OR - Notfuzzyhttp://www.blogger.com/profile/04442788840388847156noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-8655567.post-68549941367756546372007-05-25T09:55:00.000-07:002007-05-25T09:55:00.000-07:00I read somewhere the statement that we solve all p...I read somewhere the statement that we solve all problems in software by adding another layer of abstraction. I've seen this happen with interaction with the database, too. When embedding SQL in our code became too difficult, we added the abstraction of ODBC/JDBC. When that became too difficult, we added EJBs. Et cetera, et cetera.<BR/><BR/>I agree that just using SQL, especially through JDBC, doesn't seem difficult enough to warrant the extra overhead of another layer of abstraction. (My analogy is that it feels like drinking a milkshake through a half dozen straws fit together like Shaggy and Scooby do.) One could also argue that assembly (or C or C++ or...) isn't difficult enough to warrant the extra overhead of the Java abstraction. To me it's all about the cost-benefit ratio.<BR/><BR/>There are some Jedis that are fine slinging SQL and would prefer to just use JDBC, perhaps with some RAII framework around it. But there are plenty more padawans that will screw it up. From a project management perspective, you have to pick your poison. Like everywhere else in software, you can have wicked efficient code but you need to get some Jedis around. If you want to staff with the first three padawans that show up at the door, you have to make some concessions to the variance in talent.<BR/><BR/>I'd like to think that J2EE put to rest the notion that we can build a framework that allows non-coders to write code. But the reality is that there are plenty of shops that are willing to trade slower and klunkier code bases for the ability to staff with contractors of dubious skills.Anonymousnoreply@blogger.com