What can happen to IT Ecosystem w/o EA ?

Sometimes picture depicts more than hundreds of words

Few thoughts on Ruby

I took sometime to write this small blog. Blogs from James McGovern raised my curiosity on Ruby. I wanted to make my hand little bit dirty before writing.

Basic principles of RoR
1) Don’t repeat yourself (DRY)
2) Convention over configuration
3) Instant deploy
4) Ease of learning and more pragmatic
5) Built-in reusable components like ActiveRecord, ActionMailer, ActionPack, Action WebService

It is made for small to medium size application development. It is based on existing best practices in J2EE and DotNet world. It hard codes all best practices and makes them principles. No easier way to improve or change them. I feel with time best practices will improve and Ruby won’t be able to incoporate all of them.

It’s an interpreted scripting language and people from background of Python, Pearl and PHP will feel happy to move to object oriented scripting language.

My experience is in early stages of development Ruby increases the productivity but as application grows it starts taking time equivalent to or more than other Web frameworks. Ruby has its own boundaries and constraint which bounds the new developers to follow the convention and shows the best direction. But anything outside the boundary of Ruby will become difficult to implement. Inexperienced developers would make less design errors while working with Ruby in comparison to J2EE.

Currently it satisfies needs of small to medium projects with small team. May be in near future enterprises will start adopting Ruby for internal applications. It suits web based application on simple CRUD requirements without any need for complex business logic, sessions, security, availability, clustering and transactions. Let Ruby be like that.

In future, Ruby community can keep adding baggage in Ruby to fit all kinds of projects. But I feel it will act like a slow poison for Ruby simplicity. There is lot of scope and lot of small projects which will go for Ruby in future due to simplicity. But if Ruby community tries to make every customer happy with inclusion of all unbaked features, it won’t take Ruby to home.

I suggest for next 3-5 years, fix the scope of business requirements which Ruby will cater and sell it. Instead of expanding to everyone needs. Focus on niche small to medium web based internal application development. It will increase visibility of Ruby and it will also increase the number of people who knows Ruby well.

Way Forward in 2007

I am not the right person to predict the way forward in 2007. During last quarter, I got little time to go through buzzwords. Hope, I will find some way to reduce meetings in this year.

I hope that Architect's world and I will understand the basic principles better in 2007 and onwards -

1) Loose coupling and Reuse - Will adopt SOA to push loose coupling and reuse.

2) Abstraction - Add more XML files to abstract things.

3) Layered architecture – Vertical silos will break to give way to horizontal layered architecture in different domains.

4) Segregation of concerns - Cross cutting open sources like Acegi will gain momentum.

5) Cohesion - More companies will consolidate/merge to make impact especially small companies working in niche areas.

6) DRY - Move from code reuse to component reuse to service reuse.

7) Add more indirections - More virtualizations at different layers like Data and Servers.

What is more important for a project - Quality, Cost or Effort?

There are multiple objectives and goals for a team to achieve. And I concur that there exists a collective ownership for all objectives. But still for each objective there is prime stakeholder. This stakeholder persuade others to achieve this objective. Now coming to title of blog, what is more important for a project? I first list down the prime stakeholder for these objectives -

- Architect is main stakeholder of Quality (always busy to improve the quality by using different tools, Architecture document, better design, refactoring, automated unit test, reviews, POC's, continuous integration, increasing customer feedback, improving process)

- Business Manager is main stakeholder of Cost ( always busy in simplifying business case, selling flexible pluggable extensible & configurable components)

- Project Manager is main stakeholder of Effort (always busy in reducing timelines, parallel development, starting different activities simultaneously, change management, planning, scheduling, tracking, milestones setting)

So what's more important - whosoever is able to sell his viewpoint more convincingly ;)