CQRS Experience 01

Did you hear about CQRS? Are you using it?

We, at Selise, are building a large enterprise application with CQRS. I would like to share some of my experience with it.

I would take a moment to explain it first in really basic words, you can checkout and dig more later. The core principle is  CQS - Command Query Separation which tells you to separate your data read and data write operations. The method returns data should not modify the data, on the other hand the method that modifies the data (like inserting, updating or deleting) should not return any data. Which means your AddNew Method cannot return the newly added row ID back to you. CQRS ( Command Query Responsibility Segregation or Separation)  is an application CQS concept. We can call it a pattern. Its not an architecture or framework. 

To go a bit deeper with CQRS lets agree to some arguments.

 Argument 1: In any large user base application you will have more read than writes. 

 Argument 2: Reading data to display in the UI from a normalized database is slower than a denormalized database. Joining and retrieving data is expensive, its much faster if you could retrieve all your UI data for a single page as a collection row from a single table of the database without joins. The structure of this table should be more like the View-Model of your application.  

 Argument 3: When user modifies a data, it is not always necessary to synchronously update the database. We can live with some delay and let the database change happen asynchronously. Update of the UI also could be asynchronous. For example while adding a new row to a grid, the UI to add item could make an async request to server to add the row and UI can get back to grid. The grid seems to be not showing the row which just now has been added but the UI is responsive, you can make another add row or click on a different link meanwhile.  If you are still at the grid, after a few sec the row appears. 

Asynchronous database operation

On the next episode we will see how this arguments will drive us to CQRS.

[Read more:Wikipedia - Command–query separation, Martin Fowler on CQRS, Udi Dahan - Clarified CQRS, Greg Young's Blog on CQRS]

Offshoring 01: Software Offshoring to Bangladesh

Bangladesh is at this moment could be the best place to setup an offshoring operation for any software company. In this blog series I will try to explain why and how you could setup an offshoring operation and look at the major challenges you will have to overcome.

Why Bangladesh? I summarize them into 2 reasons, Cost and Talent pool. Let’s have a closer look.

Cost

Bangladesh is still cheap. Office space rent in Dhaka is 50% of Bangalore, India, 33% of Kuala Lumpur, Malaysia. Later we will take detail look at each of the infrastructural costs but in summery Bangladesh is cheap in all respect comparing to India or any other surrounding emerging economy. Developers salaries are still quite low as the living cost is low. Service cost is minimal, administration salaries are almost invisible. You could run an 50 employee team in Dhaka with full infrastructure with the cost of a 10 employee office in US.

Talent Pool

Scrum Team @ Selise

Bangladesh has produced a huge pool of Computer Science graduates over last 20 year and still continuing. It has over 30 public and more than 100 private universities where 45 of them are located in Dhaka. Many of the them are specialized Science and Technology university and almost all of them have dedicated Computer science departments. As the industry is growing many of the talented minds are driven towards CS and that gives you access to a huge pool of experienced developers, QC, UxD and project managers.

Bangladesh is a gold mine now, its a window of 5 to 10 years. Prices will go up, all the big players like Google and Microsoft will be here, talent pool will get drained in this time. If you can move in now you will rule the place.

Many are already in. Samsung, Vizrt, Metatude , Orbitax, Cefalo, Selise,  IMH health,  ImpleVista  are just a few of them. Some of them are here for over a decade.

On the next episode we will talk about finding the right partner to start your venture.