Back in 2006, I did some research about Google Guice and compare it with Spring. I don't like the idea of annotation injection for these annotations will mess up with all the other java codes and comments. From a programmer's point of view, it is hard to recognize and maintain. There is a discussion which can be found from CrazyBob . I found the following comment is the most interesting part. I copied and pasted it here only in case one day it will got lost and easily for me to read again.
constantine said...
This blog, and most of the responses, just amaze me. They reflect almost everything that is wrong with the software industry today... Basically, Software Engineering is not just for software engineers any more. The great Edsgar Dijkstra must be turning in his grave. What a shame! People who "don't get" things - by their own admission - still somehow feel in a position to bash what they don't get! Look, Spring or no Spring, there are certain basic principles of computer science and SE-ing that every decent SE should follow in order to build good, reliable, maintainable, flexible software. Some of those basic principles dictate that you should design and code for abstractions rather than hardcoded implementations, seoarate business logic from presentation, separate the applicatino configuratin from the application itself, promote reusability and modularity - for the sake of maintainability, fast error detection, and flexibility, etc. There is nothing new here. Now, Spring is just one very intellingently put together framework/set of tools/whatever you call it, that makes it easier to do all the things that you should be doing anyway. That is, if you are a decent software engineer.
Unfortunately, there are very few really good SEs these days - compared to the hords of really bad ones. Years ago, one of the fathers of Computer Science, the brilliant Edsgar Dijkstra publidhed an article in which declared that about 90% of all SEs are lousy SEs. I was in grad school when I read that article, and I almost got offended. Where does it put me, I thought. Of course, now I realize how correct Dijkstra was. Except, since the late 90s, the software industries has turned into millions of seatshops where the vast majority of programmers are absolutely incompetent hackers - with many years of experience... writing lousy, unmaintainable spaghetti code. There are, of course, companies where very technical and intelligent managers do a great job hiring brilliant people. However, the vast majority of "non-technical" companies with "IT" departments are driving themselves into the ground by hiring talentless and unmotivated clowns with nothing but lots of buzzwords in their resumes. Those people, under "supervision" of incompetent development managers or incompetent architects/bureaucrats, create unimaginable garbage, get praised for the long nights and weekends they spent fixing their own bugs, and build applications that require full-time "sustaining" teams to support for years to come. Each bug fix produces more new bugs, errors are hard or impossible to trace, nothing is reusable... Ahh well... I know this because, in my line of work I work on different projects at different client sites, and there is always the same picture.
The motivation behind efforts like Spring, as I have said, was to make it easier for software engineers to design and build applications that conform to the standards of elegance, reliability and maintainability so passionately promoted by people like Dijkstra. Spring was concieved and designed by the people with a very clear vision of what real Computer Science and Software Enginering should be. Every good SE I know has embraced Spring - not just for the features, but for the great example how to approach application design. It is not about what to use fore configuration - XML or Java, it is about designing your app so that one does not break when the other is modified, or when the requirements change. Of course, a bad programmer will misuse anything, including Spring. So, don't point at lousy implementations as proof that Spring is no good. Don't quote another incompetyent developer who has used Spring on a project but can't explain why and what for. He's just another imposter with a cooked resume. Just try to "get" Spring first. What's more important, make sure you get the basic principles of software engineering first - that are behing Spring. Seriously. And then provide your feedback.
Now, one interesting observation. There are two very distinct kinds of Spring bashers that I have come across within the past few years. The first type are programmers who have been in the business long enough to consider themselves "experienced" but who still have a way to go (they just don't know it yet.) These folks have not yet passed the stage (the stage that all of us, software engineers, have or will have to go through) when they think that their ideas are the best, any criticism is unacceptable and met with fierce resistance. These guys aren't yet at the point when they start appreciating healthy exchanges of ideas, and the fact that there are people out there from whom they can and should learn some really good and useful stuff. Often, these guys stay on the same project for years, become complacent but very proud of their input on that particular project. When facing a new ernvironment where fresh ideas are "imposed" on them, they become extremely argumentative. Simply because it is now someone else's ideas that people are turning to...
The second type is probably the most dangerous type. Those are the not-so-competent but very political and insecure lower- and mid-level technical managers, and architects, and tech leads that spend most of their time in meetings vs. writing code. These people have never been good programmers. In fact, they never even liked programming. They have always enjoyed going to the meetings, discussing "the big picture", project mile-stones, meeting clients, presenting the product written by the "code monkeys." Such people move from project to project, get promoted, add all sorts of cool stuff to their resumes, eloquently speak about every hot technology out there... They just don't write code. Or, perhaps, when they do, you'd wish they never did... But, boy, do they like to talk about stuff. You see their postings in forums like this, theserverside.com, and many others. Their postings usually contain phrases like "my developers", "I always instruct my team", "when I conduct code reviews", etc. It is clear that they are in charge, and they know what they are talking about. They just don't write good code themselves. And these people scream louder than anyone else when some new face suggests a fresh idea. Not because they really "get" the idea after having spent weeks analyzing it, but because the idea comes from someone else, and they are suddenly not the ones everyone is listening to. God, how many times have I seen this...
There is a small variation of the second type: the more technical engineers/managers/leads. They do write code, they are indeed intelligent, but way too much consumed with their egos not get annoyed when someone comes up with a new idea that they hadn't thought of first. Their ego and insecurity stands in the way of them calmly analyzing the issue and perhaps agreeing that the opponents have a point...
The author of the original blog ("I don't get Spring") seems to belong to that particular category - the last one mentioned. And his blog has attracted all sorts of representatives of all three types - to vent, bitch and moan... They seem to have found one place where the likes of them would listen and agree, and support their insecurities. It's a shame.
By the way, one of the great things about Spring is that it is totally non-ivasive. Spring does not force itself on you. You can use only small parts of it - to the extend you think you may need it. And, it you can add more Spring support as the necessity arives. That's the whole point of any intelligently written software. You don't need to de-couple everything. Just use your best judgement. The point is, Spring helps you to do othings the right way - when and where you chose. It is still up to you to decide what your application needs. But if you are sweating to decide whether your code should be reusable and elegant, or look like a big steaming pile of spaghetti, and you don't see the difference... then, perhaps, software engineering is not for you.
No comments:
Post a Comment