When a SWAT operation is in action, there will be only one Commander-in-Chief and his commandos. Once command is issued, the target should come under control. There will be no time for unwanted questions and answers. Unwanted things may distract the “Power of Focus”

We do have logging and compliance setup into SQL for both OCS and OCS Group Chat. But the feed into Outlook was something very useful for end-users. Does this have to be done separately via the SDK? Or are we missing something? Thanks.

Very nice article. Well can you also help in finding out the situation across load balancers ?

Thanks,
Thani

Cheers,
Suresh Krishnasamy

Can you give an end to end example of how to implement SaaS using Shared DB, separate schema approach? I mean, from the point of end-user’s logging in to the system (how does the connection string look like?) and how does the DB know which schema the user maps to. Also, please shed some light on connection pooling in this approach (shared DB, separate schema).

Thanks,
Nikhil

1) Baking Period: Schedule pressures are so high, that these days developers are more inclined towards diving deeper, making their hands dirty with coding rather than first thinking through the design, its impact and addressing non-functional area. How many times do you see a developer calling a meeting with Architect to review the design? I hardly find this in my projects. That said, I do not deny that good PM’s must understand the importance of this and be proactive to initiate such discussions. Infact this should be embedded into the plan itself (MPP). I agree with you that initial baking time is required and once you have strong foundation designed, you can always build on top of that.

2) Real Estate Broker Effect: To win deals, Sales team will go aggressive and to ensure delivery happens on time such schedule reduction are prone to happen. Yes, there needs to be a correction at this level itself. But I think we can be equipped to handle such scenarios. As a Product development company or Service company very often we are focussed on successful execution of project and meeting the defined project SLA’s. But based on these learnings we do not spend enough time and money to invest in building common code repositories. I am sure you would agree that we can possibly complete 40-50% of coding if we keep building generic code repositories to address various scenarios, requirements. I find very less focus on this in many industries.

3) Governing the Dynamics - Solid PM. Completely agree with you on this. PM must push back when scope creep happens. PM’s must re-define processes, set/reset the expectation as per each project dynamics. Passing down the heat may lead to another issue:attrition. Careful analysis and proper feedback system must be applied. And most importantly PM or leads in the team should stand up and own the issues. It is important to learn from mistakes and be proactive. Reactive approaches will lead to customers unhappiness.

I am sure there are lot of dynamics to discuss, keep shooting your comments.

I need help designing a data migration tool. In which my source can be any form(Excel, DB, flat file, etc) for now, i am taking an excel file with few tables and columns. I want to map columns from source to columns on teh destination. How do i store this mapping in teh DB?

In addition I think the following also needs to be taken care of (atleast for development projects)

1. Baking Period – Most of the times a specific portion/core of software requires X amount of CONSTANT TIME, this should never be a variable and needs a CONSTANT effort Y & cannot be distributed/halved. I would like to call that as Baking Time because it’s very analogous to Baking a cake or bread.. No matter what, the cake has to be baked X amount of CONSTANT Time and Y Number of Oven capacity. Else we end up with either greasy or over-burnt Cake. Similarly it’s critical for the architect/lead to find out such piece of software and ensure that that portion of software gets that time.. the X could be time combo of brainstorming + ideating + design + POC + Unit tests + analyzing alternatives + analyzing NFR et al … and Y is the number of devs required to do the task. If it is decided that it’s better to be done as a timeboxed activity by 1 resource so be it… once this core piece is allowed to be baked properly we can always add icing, bells, whistles et al.
The Project Manager should understand that this is done for common goodness and spending a quality time on this 10% piece of work might have a good impact on the remaining 90% of the product. It could be a pressure but PM has to understand and have his foot on ground to provide such a quality time to the team. Again TRUST is a big factor here!

2. The Real-Estate Broker Effect [Shortening Deadlines] – Few project manager have a tendency of providing false deadlines to the team. For e.g. the customer says total time to deliver is 6 months, the sales guy now walks in and sets the date as 5 months, the GPM sets the date as 4.5 Months, the PM sets the date as 4 Months, the lead sets the internal dead line as 3 months and plans to deliver in 3.5 months… Well the real scenario might not be same, but most of them have this tendency and in essence we tend to lose 50% of valuable time that the engineering team could have easily used to solidify the design instead of just doing plain code & deliver because they have a deadline to meet! This is more like Real estate brokers who hike the rates but in the other direction!

I wouldn’t say this is bad, but there must be an upper bound of 5% - 10% for the buffer time.. which is purely for unforeseen risk. In my opinion if the PM has a buffer time of 10% to 30% he sounds in-efficient in my opinion because he has not calculated all the risks and the project is definitely not in his CONTROL. Moreover it also says that he does not have TRUST on the Engineering TEAM, which is again disastrous!!

3. Governing the Dynamics - A Real Solid PM – It’s easy for any PM to pass down the Heat/Pressure he got from the customer and his Boss to the people below him i.e. his team (specifically on the deadlines). This is the first step when the PM loses respect from the engineering team. He is merely seen as a physical bridge or log of wood who allows loads of gas to pass through.. but a Real PM is someone who would never allow the engineering team to feel the pressure but still deliver successfully on date. There are many living examples of these kind of solid PM’s I can introduce you to…

How do they achieve this? It’s actually simple – They MANAGE the project instead of TRACKING the Project! i.e. each aspect of project is analyzed logically & analytically and they take a stance of if it’s good let the event to happen and if it’s bad they see who needs to be educated, educate them, provide alternate solutions and solve the crisis. Especially if it’s a customer to be educated the PM should have a real back bone to go back to the customer and say what’s WRONG and educate them. Which is definitely lacking in most of the incidents and we end up as a disaster!
In this case the PM is the Bozo who has bought down the whole show AND MONEY!! Any PM who says that “I CANNOT SAY THIS TO THE CUSTOMER” should be added to the Watch List

But any PM who Governs the Dynamics and does it with his own style gets loads of respect and glory from the engineering team, their boss and customer 

In the end… it’s all about governing the Dynamics!!

Just my 2 cents…

Can u please provide some basic details about how I start to design Metadata driven ETL using c#?

Thanks,
BJ