How do you think?


How do you go about writing you program?

Do you think in terms of:

  • Programming construct
  • Database design
  • Abstract algorithm
  • User interaction

Looking back

Way we think about writing a program has undergone several phases of evolution. The evolution has a close link with increasing complexity and technological progress.

Flow chart era

There was a time when it was considered a very bad practice to start writing code without drawing a flow chart.

Those were the days when the concept of interactive debugging did not exist. You would submit you deck of cards to the mainframe data center and wait for the result to come. One compilation means another long wait.

Structured programming era

Then came a revolt against GO TO.

People stopped using flowchart and started using structure chart.

DB design era

Since the time RDBMS became popular most programmers used to thing in terms of database design. They believed that if you get the database design correct then the rest of the application would fall in place. They thought in terms of Entity-Relationship diagram and Database Normalization.

The ability to write an optimized SQL statement was a prized quality for a programmer!

Event Driven programming era

Once GUI became popular, structured thinking could not be used to solve the new class of program required.

That is when event driven programming and thinking in terms of even became popular. A new classes of tools and programming languages evolved. They were clubbed under the title of 4GL or 4th generation languages.

The event thinking and DB thinking coexisted. That was the Client-Server era. The debate was about what code should go into the DB stored procedure and what code should go into the event.

Object Oriented programming era

Then came Web. It needed HTML and multi-tiered application development. Event driven programming could not address this challenge.

As a result O-O thinking became popular. New classes of programming languages emerged. Design patterns became popular.

O-O thinking was not very compatible with DB thinking, so the O-R or object relationship mapping tools became popular.

DB thinking started loosing its preeminent position. DB thinkers lamented that the new generation of programmers could not even write a simple SQL.

Service Oriented programming era

When the systems became interlinked it became too complex to design using only the O-O paradigm. That is when SOA or service oriented architecture emerged. It was more to supplement the O-O thinking than to replace it.

However, the business consultants and the product vendors wanted to hijack the SOA term to mean something much more than a way of building a multi-machine application. Fortunately, that was not a success and the S-O programming paradigm and the O-O paradigm learnt to amicably coexist.

The Way Forward

Again, we are at a crossroad. Desktop and laptop are no longer the only means to access the web. Keyboard and mouse are no longer the only input devices. Number of channel through which we interact with each other and with organizations is exploding.

In short, the technology scenario and complexity of interaction is changing and changing fast.

As we have seen in the past, any such change have invariably impacted how we think about programming.

Looks like the future is going to be SMAC.

S = Social Media = User interaction design and Algorithm

M = Mobile Computing  = User interaction design

A = Analytics and Big Data = Algorithm

C = Cloud Computing = Parallel Programming = (?) Functional Programming

So, are we at the inflection point where we need to change how we go about writing program?

Are you ready to think beyond O-O design patterns? Beyond services?

Would you be comfortable thinking about user interaction design? About abstract algorithms?

Can you afford not to?

Comments
2 Responses to “How do you think?”
  1. Gene Hughson says:

    It’s interesting (and, I believe, supportive of your point) that these are all solution-oriented rather than problem-oriented. Learning how to capture the architecture of the problem makes it much easier to shape the architecture of a solution. Technological innovations then become advantages rather than challenges.

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: