Let me train your developers in Object-Oriented paradigm and modeling

There is a lot of undeniable evidence of the high productivity of Object-Oriented paradigm.
The core of the reasons behind this is the simplicity of two layer structure of all activity.
When all activity is divide in two parts: the things that each participant achieve individually and what is the result of two or more individuals collaborating together.

The paradigm sift from procedural to OO in early 1990’s was a total discontinuation point. It seems that the huge majority of “the old school” veterans that had not enough training and resources to understand the hard core of the new paradigm and the poor new tools together caused the whole computing community to deteriorate back to the “golden age of algorithms”. This way we mentally retreated at least 15 years in software development methodology.

Today my guts feeling is that most application development projects are conducted in an extremely inefficient way. Thus those cost many time more than would be necessary.

Agile development is one step forward and an attempt to do things better but it deals most with group dynamics only and it requires strong methodological support from the professional side. OO is that counterpart.

Software developers should be much better of if they were not taught any 3G procedural languages and databases at all. All this stuff belong ti the past. Instead the should be taught domain modeling, object behavior and collaborating sets of object, object life cycle and persistence.

When a person has learned to develop a Java application in modern IDEs then it is not a big effort to learn the OO paradigm if one is to learn it at all.

I think that the current development teams should give their member a fair chance at least to learn to know the cornerstones of the OO-paradigm and the development method to be able to compare the methods and to decide them selves.

It takes only 2 – 3 days of on-cite training to open peoples eyes if that will happen at all.
I am most willing to give that training.

Advertisements

5 Responses

  1. I agree heartily on the fact that few people really learn OO at school, or understand it even after years of working. Most discussions are about frameworks and libraries, and modeling skills, object or other, are not appreciated much.

    Depending on the size of the project/organization/team SQL know-how can be necessary. ORM and other tools have made developers less dependent on SQL, but there are times when developers need to use it. For instance, if the project is small enough to not have a DBA available or if there are vast amounts of legacy code.

    • I agree with you Heikki. My point here is priorities. In most cases the application development is finalized to a punch of compromises. When the important structures are right most of the issues especially with recalling set of stored objects have minor overall effect. There are however important guidelines in application construction. For instance novice developer when thinking db-oriented ends up materialising hundreds, thousands or tens of thousands objects, but humans can deal only a few at a time!

  2. I think one of the biggest problems with modeling is that there are little rewards for it. There are some immediate benefits from proper modeling, but most of the benefits come after months or years. And often developers are no longer in the project after those years, and they rarely get appreciated for things they did several years ago.

    I’m not sure if there really is anything else that’s motivating a developer to model properly except for his sense of decency and desire to do his job well.

    • I have difficulties to understand how your development processes goes when you say:

      ” I’m not sure if there really is anything else that’s motivating a developer to model properly except for his sense of decency and desire to do his job well. “

      If you read my texts about model driven application development, the model is a key element of the implementation process. In my method ( ie. real OO- method ) all business logic is abstractly defined in the domain modeling phase. So there is no other way to find or implement business logic than the model. By the way OO-model consists of a class model and n pieces of collaboration diagrams (see. Examples within my model posts:
      https://jukkatamminen.wordpress.com/oo-model-examples/ .)

      In this modeling phase ALL the methods that are needed for business logic are named and briefly described..

      The the implementation starts generation this model into code of the selected programming language.
      After this team starts to analyze the work flows and design and implement these as the application layer

      There is one essential aspect to add here. It is the incremental nature of the domain model. During the implementation phase this model grow in details.

      By the way use cases are not needed in OO- development at all !

      • What I’ve seen, the requirement for a model is often missing and it’s up to the developers to create it.

        And since they usually will receive mainly negative short-term feedback and only little if any positive long-term feedback for it, it will not be done.

        The difficulty is in getting people (not just developers, but the managers and clients) to understand the usefulness of a proper model. As well as other practices which are critical in the long run.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: