My take on trends to watch out for...

Couple of days back one of my friend asked me what are the 3 things important according to me for upcoming year 2011. What he meant was - What are the 3 things that I would focus next year? That got me into thinking.

This blog post is an attempt in that direction  - which are the trends that I think would make a difference for any software developer to keep up with the fast pace of change.
(Note: Not in any particular order, all are important)

1. No SQL.
• Traditional DBs are good but definitely not "one size fits all" solution. We have to understand  these too have some limitations.We have to stop thinking in rows and columns and start thinking in Documents. Get familiar with some of these concepts, find out what makes these (Mongo DB, Redis etc) successful, what kind of problems can be solved by these. This technology is going to thrive.
2. Scripting language
• Enough of Java, C++, C#. Enough of OOPS. Its time to open a notepad and do some quick scripting to get things done. Too much dependency on IDEs have made many of us dumb. Its time to brush-up (or learn) scripting language. Simplicity matters. Be it Ruby, Groovy, Perl, PHP. 
3. Cloud computing
• Get familiar with Cloud computing architecture. This technology is already 5 years old. Amazon launched its services in 2006. Computing is cheap these days and just a click away. There would be a time in future when everything would be on cloud. This technology would grow by leaps and bounds
4. Git / Mercurial (Modern Version Control Systems)
• Speed is the mantra of this age. Gone are the days of client-server versioning system. In this era of opensource and distributed teams, distributed version controls make life of the developers easy. Every developer should be aware of installing and using these distributed configuration management systems.
5. Web 3.0 (HTML 5)
• A month back I attended one day conference on HTML 5 conference in NYC. The takeaway from the conference is - HTML 5 is inevitable. It has been already a decade since HTML standards got updated. The big guns (Google, Apple, Microsoft etc) are all supporting it. HTML 5, CSS3 will be the future of the web. Features like Offline storage, drag drop, geo location, canvas etc will make developing "desktop caliber" web apps a breeze. Developers, Architects ignoring this will be left behind.
6. Functional language
• History repeats. Computing started with Functional language (Lisp, Scheme etc), moved to procedural (C, Pascal etc) to object oriented (C++, Java. C#) and again back to Functional languages(F#, Clojure, Erlang, Haskell etc). The job trends already indicate a huge demand for Clojure, F# etc. Hardware has become cheap, grid computing has been norm and some real world problems can be solved insanely easy with these functional languages. Its all about "Share Nothing Architecture". No concurrency issues. Its high time for the developers to start thinking differently and learn (or re-learn) the concepts of functional programming
7. Data visualization
• At least two billion tweets are being posted per quarter (Source wikipedia). Wealth of information is available on twitter and all the data is public. Everybody would be interested in visualizing this  data in some form (graphs, charts, trees etc ) to make sense of it.  Its too much information out there. Barack Obama knew this and used this technique to do a wonderful campaign for his elections. This trend would keep growing as more data gets collected on the Internet.
8. Mobile / Tablet platform
• iPad has been rated as one of the best devices to consume information. Consumers, executives, enterprise folks - all would have one or the other form of tablet devices in the near future. Its the new trend and a growing trend. Analysts call it "arm platform". Architects, Developers should first think of smart phones, then tablets and finally the notebook - when architecting or designing new enterprise or e commerce applications. 
9. Agile 
• Everybody should be familiar with Agile Manifesto. 
• TDD, BDD
• SCRUM/XP
 

This should take care of your learning appetitie for at-least couple of years :). 

Please share your list ...

Top 10 qualities of an Architect

1. Act as an interface between Business & IT
2. Identify risks (project, technical , business)
3. Should not be stereotyped (Keep aside your experience, explore & look for possible alternatives)
4. Keep upto date of latest technology trends – especially in terms of limitations
5. Excellent presentation / articulation skills
6. Master (at-least) one Programming language (OO / Functional)
7. Develop technical intuition  (Usually comes with experience. Read a lot)
8. Be Passionate. And Don't be too clever.
9. Take responsibility of your decisions.
10. Write Good code. If you design it, you should be able to code it.

The Profession Of IT Architecture

Check out this SlideShare Presentation:

The Profession Of IT Architecture

View more presentations from Christopher Grant.

Frameworks frameworks...too many

Check this out ...one more new framework...Nevertheless nice comparison of different new and old frameworks. Below is the presentation

How to choose a web framework and be surprised

View more presentations from Jose María Arranz.

Will do a poc soon and share my findings of http://itsnat.sourceforge.net/

Are we going back? (Client Server == AJAX )

One of the fundamental rule in designing software systems is always to divorce presentation logic, business logic and data access logic,

• so that each tier can vary withstand modifications of other tiers
• so that different teams can focus on separate layer and specialize in that
• so that building complex systems can be easier etc etc

Many books have been written emphasizing the advantages of this pattern.
Coupling any of these layers would take us back to ancient Single tier or Client Server architectures.

Why am I telling all this?

One of the projects which I'm currently working on is a Web 2.0 application. This app helps users to do financial analysis by pulling large amounts of data  from the database and plotting charts. And there are no page refreshes and every request is a XHR request (nice :) ).
jQuery is the Ajax framework & jQPlot is the charting framework.

One of the interesting side effects that I'm observing building this Ajax Web 2.0 app is more and more "business logic" is getting into the front end javascript files(and btw the other side effect is - Ajax apps are not search engine friendly - not "crawl-able").

What could this mean:

• sooner or later javascripts files grow larger and soon will end up in an un-manageable mess
• anything running on the browser is kind of "open source" available to entire world - as these files get downloaded on the browser cache. Anybody with little effort can look at the business logic
• bad user experience because of browser freeze - This is basically a counter effect. The primary reason why somebody would take ajax approach is to give a better user experience i.e. if the code runs in the browser then it it faster. But these days, an average user will have min 6 to 7 browser windows open (plus mail client (lotus or outlook), some office documents, pdf readers , IDEs etc) and if the browser starts taking your laptops cpu cycles looping some java-script code and rendering and re-drawing html --then a browser freeze is guaranteed (HTML5 promises to solve this)
  

Its kind of going backwards in time where all the presentation logic, business logic is getting mixed.
The browser for Ajax apps are kind of acting as a thick client, downloading data from the server (usually as JSON content) and manipulating most of it on the client side. The app server is just acting as a content provider.


Why this could be happening?

One word. Performance. Users are impatient and response > 3 secs is not acceptable.
The primary reason the business logic ends up on the client side is to limit the number of requests to the web server.
Network calls are very expensive (one to the web server and another from web server to the database server to get the actual content). So naturally developers would take easy way out, bypass these network calls, get chunks of data on the browser and manipulate it.

How to avoid this ?

• Avoid putting business logic putting on the client side
• Use java script wisely to manipulate the DOM
• Use good server side caching solution
• Tune your SQL queries
• Design a good UI
• Anticipate user clicks, fire the request at background and have the data cached on the server side
• Keep clearing the server side cache

just my thoughts...

Back to Square one - HTML5

Wow! That's what I uttered when I watched one of the videos on HTML5 on Google I/O 2010.

I started my career coding HTML 4.0 way back in 2000. The web was hot at that time (btw it has become hotter now :)). HTML seemed easy. You write tags and see the changes, no wait time,no fun ;) .
Java was the hot buzz word. Every other person was crazy about learning Java. Applets were kind of geek thing. It was kind of prestige issue to learn Java. Your fellow buddies silently respected you when you showed your new Applet or Servlet.

During my early months of job, I started feeling HTML is only for greenhorns, there wasn't much fun in doing any HTML or say for that matter Javascript. One reason was that the tools used for (D)HTML were spitting too much of code. You don't understand any thing in that. There was not one correct way of doing things. Cross browser or say for that making code compatible for matter different versions of IE was a nightmare.

I slowly forgot HTML.

But now, With new HTML 5.0 killer features, nobody can ignore it. It has the capacity to completely replace these Rich Internet Apps be it Flash, Silverlight etc.

It would soon become a standard and entirely change how we write web applications.
Javascript would be new language of the Internet.

Some of the features are just amazing:
1. Offline storage database
2. Drag and Drop
3. Canvas
4. Rich Media tags
& the list goes on..

Check this out:
Demo of HTML5 is in HTML5 How cool is that !!.

And this video on youtube:

Java EE6 CDI

Choices ..choices. Now Java Development without Spring.
Its making harder for Java EE Developers & Architects. Now they have to un-learn and learn new stuff.
Jokes apart -- Java EE 6 with CDI indeed seems to simplify things for the programmer. Less code more work backed by Oracle (i.e. Sun) & Tomcat support coming soon. Finally Spring taught a lesson to Java & Java has learnt it well.

Let me head to the book shop to pick up the book - "Java Development without Spring" By Johan :)

I don't know what my next client would want. Spring or No Spring. Do I have a choice?

Java EE6 CDI

View more presentations from johaneltes.

Bob Martin on Software Craftmanship

After listening to this marvelous session, if any body related to Software development, who writes production code, does not write a unit test (i.e. automated test) for that production code, then he is not a software "professional" --> period.

Everything falls in place, like good design, good architecture when we have a set of test suite. It adds immense confidence to keep improving the software without any "fear" of breaking it. Good test suite == good software.

Craftsmanship is nothing but professional commitment of an individual to deliver "best" software to their client or the employer.

No finger-pointing, no blame-game, no wasting time how this mess got created - just get your hands dirty and start fixing.

Thanks Bob for the lesson.

Advice to myself - Choosing Work

There are three things to look out in any new endeavor that I undertake.

These are not in any particular order:

1. Does it give me money
2. Does it give me fame
3. Does it give joy

Of course the last one is the most important one. Often many try to buy the last one by the first one, which is mostly superficial.

If all three come on your way then nothing like it...

Reading Code...Software Archeology - 2

In the almost a decade of IT experience I can safely conclude that I have read more code than have written.
This is true for many of us. In college we spend most of the time writing code and the moment we are out in the industry , we join a project team and put  in a situation where the majority of the time we spend in reading (others) code.
This is always true at-least in Indian market where the engineers work on the outsource project.

Few other reasons:
1. Most of the companies have a big agenda of "Re-use".  They always emphasize and encourage teams to create a librabry re-usable components/assets. Often they track this by metrics on how much your team has shared and how you have reduced cost by using the already available components.
2. There are umpteen number of opensource libraries. Most of them lack documentation. The only to make it work is to open the source and digest it.
3. 80% of the projects that get outsourced are maintenance and enhancement which lack up to-date documentation.
4. Legacy projects
etc

Look at this way,we almost spend about 60-80% of our time in the industry reading code and 15-35% writing code and remaining on other activities but almost all the tools, processes, standards, best practices that are available on the web are for writing and creating new systems but very minimal to read & understand existing code.

What is Software Archeology?

I will leave the veterans and experts of the industry to shed more light on this:
Digging code: Software archaeology - Good overview
Grady Booch on Software Archeology
Listen to Dave Thomas on SE Radio
Article on Java Dev Journal

In my next post, I will share my experiences of diagnosing and understanding a complex Java EE app using some of the tools that I stumbled upon on the web.

Reading Code...Software Archeology - 1

Finally things have come to an end..and there is some relief of completing this particular project.
This project had some history (of-course not a good one) of being slow, complex, no-documentation, open bugs etc. My luck, I landed in this one. But there is always some scope to learn..be a new project or old project.

Background:
This project was a IBM WAS portal application (one big portlet) built using legacy struts1.1 framework and accessing a set of remotely deployed ejb services. The ejb services project (was configured with 6 datasources) acted as a service provider and the portal project as the consumer of services.

Size wise, the portal app is having 6 very big struts 1.1 action classes (where all the UI logic resides), 11 packages & about 20 KLOC. When I say very big, I mean very big about 5KLOC in each action class.

The goals of this project was to de-portalize i.e. move away from the portal run time - i.e. to save some money on portal licenses & merge the complex ejb services project with this one. This is primarily to strip of ejb layer so that performance is improved and all its services are local. Everything is at one place and so it is more maintainable.
btw, earlier I wanted to use the word - re-architecting but found out that there is no existing architecture in the current project to do that. So instead used another jargon - de-portalizing.. :)

But what this has all got to do with the Topic of this blog..Reading Code...Software Archeology.

You might have guessed based on the above background where I'm heading to..