Are you stuck in the vacuum tube age?

[Peter Gibbons]

Goddard Bolt mentioned in another thread that his dad didn't make the transition from Vacuum tubes to transistors.

We know some people didn't make the transition from mainframes to PCs.

Are you stuck technologically but have all the right justifications and explanations?

I know I have dismissed a few technologies in past that now I feel too embarrassed to admit.

I think with experience sometimes we also start to feel that nothing is really new and what we know is better than the new way of doing things.

( Think about a dentist who is a real expert in making fillings using lead based compound and finds all the reasons why the new plastic stuff is inferior material. )

So over and over again we miss new trends.

P.S. This will also happen in the new career you are planning for the post contracting times.

[Peter Gibbons]

By the way: It's seldom than a new tech completely replaces the old one. There are still areas where vacuum tubes are superior to solid state devices, mainframes are still in use ...

So knowing the old AND the new tech is an important advantage.

[The Original Henry]

I guess I'm stuck too. My cell phone has only 12 buttons and can't do anything but make and receive telephone calls.

I see the same thing happening with all the new development frameworks. I still scratch my head at the people using ORM frameworks, especially the Hibernate derivatives. Connecting to a database may be boring, but it's just not that difficult - certainly not enough to justify such a massive dependency. So many times these ORM frameworks are so bloated and overbearing that the rest of the architecture ends up getting designed around it. Ugh.

Anyway, if that makes me a vacuum-tuber then light me up and pass the Redenbacher.

[John Masterson]

I think if you get your satisfaction from solving the business problem effectively and efficiently, you will naturally gravitate to better technologies to help you do that.

If you get your satisfaction from being an expert in a certain technology, then you will get stuck.

I had an epiphany way back when I finally realized clients do not care a bit about anything other than a good solution to their expensive, irksome business problem.

[Richardk]

Or if you get good in a certain technology, I think you'll have little reason or time to look at better technologies until you're forced to or it bites you in the butt.

I suppose that's the old "if it ain't broke then don't fix it" attitude and it fits right in with the client doesn't care as long as it fixes their problem.

[Peter Gibbons]

I had an epiphany way back when I finally realized clients do not care a bit about anything other than a good solution to their expensive, irksome business problem.

JM,

I know you have solved this issue in a rather elegant way - hosting the solutions yourself and dealing with managers who have a budget and are willing to bypass the IT department.

This is definitely an excellent model to follow.

Unfortunately in the other 99% of the cases the customers do care how you solve their problem.

Even when the system is working perfectly fine I have had to justify in writing why I used C++ for certain module and not the "Company Standard Language" - Java. Why I used library X instead of Y which is more popular and well known. Why we used PostgreSQL instead of Oracle and Tomcat instead of Sun ONE. Why I used relatively unknown application server ( even though the technology was superb ).

Why, Why, Why ... and this is in the cases where I could actually pick the technology.

In most cases everything has been already chosen and we had to just implement the solution.

Even "Fixed Price" projects often will specify that "The work will be done using industry standard language."

[Peter Gibbons]

I see the same thing happening with all the new development frameworks. I still scratch my head at the people using ORM frameworks, especially the Hibernate derivatives. Connecting to a database may be boring, but it's just not that difficult - certainly not enough to justify such a massive dependency. So many times these ORM frameworks are so bloated and overbearing that the rest of the architecture ends up getting designed around it. Ugh.

Agreed. However an ORM doesn't have to get in the way. The Active Record in Ruby on Rails looks quite simple and usable.

I myself wrote one in Java that takes care of the boring stuff and is also extremely simple.
It just doesn't make sense to assemble all those select statements and map the data to the Java objects manually.

So, I think ORMs are a good idea but some of the popular implementations are less than optimal. I did some research before I decided to reinvent the wheel and found this ORM:

http://www.simpleorm.org/

that seems to be written by developer with much deeper understanding of Relational Databases than me. It's much more feature rich and in general looks pretty good - however the license was a bit strange and I just didn't need all those features since I prefer to use plain SQL in the more complex queries.

[Richardk]

Mapping tables to classes? What a PIA. I guess I really did forget my Java.

I can see some applications where you really want to work with some "class" that is stored in a database but for everyday data processing that seems cumbersome. I guess I long for my PowerBuilder days where you just create a datastore that mirrors the tables that you want, connect, retrieve and go.

Their white paper looks like what I'd do if I wanted to manually retrieve the data in code. So it looks very familiar and easy to use.

I guess I don't understand the need for ORM unless you need to map to complex objects that you've built a class for. Maybe I've done so much data processing and always started with a (hopefully) good database design that I have an unusual point of view?

[Richardk]

Unfortunately in the other 99% of the cases the customers do care how you solve their problem.

This mirrors my experience as well. If it was a pure turn-key solution, they probably wouldn't care but often the code / project is maintained by their staff. So this often severely limits your choices, to like no choices and you use what the client has.

[Peter Gibbons]

I guess I don't understand the need for ORM unless you need to map to complex objects that you've built a class for. Maybe I've done so much data processing and always started with a (hopefully) good database design that I have an unusual point of view?

Just to make CRUD operations simpler:


Contractor contractor = new Contractor();
contractor.first_name = "Peter";
contractor.last_name = "Gibbons";
contractor.rate = new BigDecimal( "200.00" ); // I wish
contractor.save( connection );

...

Contractor contractor = new Contractor();
contractor.first_name = "Peter";

// Get a list of all contractors with first name Peter:
List< Contractor > list = contractor.list( connection );

...

This is using the convention over configuration idea (popularized by Ruby on Rails ActiveRecord):

Contractor objects are saved in table 'contractor' with fields first_name, last_name, rate, ..., ...

So you don't have to map things externally in a XML file.

P.S. Of course Powerbuilder had this ( and more ) 17 or 18 years ago

[Richardk]

P.S. Of course Powerbuilder had this ( and more ) 17 or 18 years ago

I guess that's why I'm questioning the need. Don't all languages have this now?   

It also explains why it looks so familiar.

I'm comfortable with SQL and stored procedures thus I push as much as I can onto the server. And like you said, with PowerBuilder you also had the option to easily work with the data on the client as well using a datawindow or datastore.

Hmm, Ruby on Rails. Yet another thing I should blow the dust off of. I really can't keep up anymore.

[The Original Henry]

But it's a mistake to assume that middle-tier objects will map cleanly to database tables. Normalization rules and performance tuning usually dictate storage structures that are quite different than how they are represented as objects. ORM just turns into a nasty pretzel trying to accommodate all the differences, usually to the point where it's less effective to use ORM than to NOT use it.

[Richardk]

You're suggesting that they implement this quite blindly and hope the mapping works well. I can see a lot of problems with that.

[The Original Henry]

Actually I'm suggesting that the mapping is highly custom to the specific project to the point where a comprehensive framework is not possible. The attempts to accommodate all of the nuances and edge cases just makes for a gigantic mess in the middle.

It also violates both encapsulation and loose coupling, which to me makes it a non-starter in the first place. Automatic updating of the mappings tries to hide this but it just adds even more complexity to the mess.

ORM is the product of architecture astronauts who thought regular old database interactions were beneath them and their mad architecture skillz.

[The Gorn]

Actually I'm suggesting that the mapping is highly custom to the specific project to the point where a comprehensive framework is not possible. The attempts to accommodate all of the nuances and edge cases just makes for a gigantic mess in the middle. ...

Just to make CRUD operations simpler:


Contractor contractor = new Contractor();
contractor.first_name = "Peter";
contractor.last_name = "Gibbons";
contractor.rate = new BigDecimal( "200.00" ); // I wish
contractor.save( connection );
...

I'm loving this debate! Very informative.