Many students, especially those who are poor, intuitively know what the schools do for them. They school them to confuse process and substance. Once these become blurred, a new logic is assumed: the more treatment there is, the better are the results; or, escalation leads to success. The pupil is thereby "schooled" to confuse teaching with learning, grade advancement with education, a diploma with competence, and fluency with the ability to say something new. His imagination is "schooled" to accept service in place of value. Medical treatment is mistaken for health care, social work for the improvement of community life, police protection for safety, military poise for national security, the rat race for productive work. Health, learning, dignity, independence, and creative endeavor are defined as little more than the performance of the institutions which claim to serve these ends, and their improvement is made to depend on allocating more resources to the management of hospitals, schools, and other agencies in question.From a 1970 essay by Ivan Illich entitled Deschooling Society. I'm not convinced schools intentionally mislead, but I do agree that many people confuse process and substance.
With many things though, people have this strange tendency to avoid knowing them, and instead ask someone else unfortunate enough to already know them. Say, Makefiles. Is it just my experience or do people worldwide pretend to be incapable of dealing with a hairy Makefile, and leave its regularly scheduled tweaking to a small set of knowledgeable victims?From The cardinal programming jokes (PG-13). By the way, this quote is incredibly true in my profession, and I think in all of life as well.
I spent a good part of this week debugging a particularly nasty software bug on an internal-use application at work. On day one I intuitively felt that a foreign key linked EJB was the correct way to go. When I could not get it to work within the application's custom framework, I assumed my solution was incorrect, since I have not used EJBs often. After two days with very little progress, I was ready to say the heck with the whole bug, the heck with EJBs, and throw a big pity party. But then I realized I needed to take a step back, reevaluate the situation and my assumptions.
My first assumption was that the framework was correct. Indeed, it had been in production for several years. On the other hand, it did not have many foreign key relationships like the one I was trying to add -- perhaps it did not have any. I decided to dive into the bowels of the custom framework. Lo and behold, it had incorrect behavior for certain classes of foreign keys, mine included. A little patching and I was on my way.
There are a couple good software development lessons in here. The first is to frequently revisit your assumptions, especially when you are going nowhere fast. Changing your assumptions allows you to explore more of the possible solution space quickly.
Another lesson is to be cautious in adding new framework layers over top of established standards like EJB. While EJB development can be complex, matters are complicated when you deal with an unfamiliar extra layer.
Finally there is a lesson to keep your abstractions simple. An entity EJB is ultimately an abstraction of a database row, yet the implementation is complex enough that some developers feel compelled to add another layer to abstract away the EJB abstraction!