Though both ensure distribution, layers are logical while tiers are physical ways of distribution. Usually Layers are for us while Tiers are for machines but not necessarily.

Layers

Layering is to create logical separation in your code during design and development, based on roles and responsibilities in order to increase clarity, reduce complexity, increase maintainability and organize relationships among code artifacts. Layering itself doesn’t imply any specific implementation that how many layers you should have or which layer should or shouldn’t communication with which layer. Following is an example of having layered code or multi layering:

Data Layer

Since almost applications use data, whether it’s a business application or a game, you need to persist and retrieve data You may have a separate set of modules or classes (or whatever code snippets) to handle saving and retrieving data from database, XML file, text file, web service or any data source.

Presentation Layer

Web pages or windows forms are the most common example of presentation layer, where you just focus on the presentation delegating domain logic, data retrieval, security or any other concern to other layers.

Tiers

Tiers are the physical distribution of application at infrastructure level at the time of deployment, like whether to have a single machine for database and web server or dedicate machines for both or even multiple servers for balancing the load or adding backup machines and processes for handling as failover. Again the term Multi Tier or N-Tier doesn’t restrict to any number of tiers instead it depends on the requirements and the platform.

BlogCatalog

There can be multiple options to implement a functionality but there’s only one which should be opted, the most economical one. But how you can choose the best solution till you are unaware of all the available solutions. Yes you can choose the best -you-know but it’s not necessarily the best available —here best means the most optimal solution according to your case specific needs.

Hence in order to choose the best solution, you need to know all the available solutions with their benefits (pros) and costs (cons). So in the given context I am sharing the options, I am aware of, available for implementing workflows with SharePoint.

1.   By enabling ‘Required Approval’ feature on list items

If you just need a moderation by admin on the contents –whether it’s a document or any other list item–added or modified by content editors, using a workflow would  be an overkill. You may just enable  “Approval Required” option on lists to get items approved by admin. This simple feature can also be used where a Accept/Reject decision with Comments/Remarks is sufficient for the approval of an Leave Application, where the approver can be the HR manager.

2.   Using built-in OOTB (out-of-the-box) workflows

There are few very basic built-in workflows in SharePoint which can be implemented with in minutes but are very rigid and inextensible. Opt only if the following applies:

• You need very simple approvals and you are sure that the functionality wouldn’t extend
• No split join or parallel approvals are required
• Inputs from approvers, except  accept/reject and comments, is not required
• More suitable for in-house implementation not in projects where you are always expecting challenging changes request from an inconsiderate client

3.   With SharePoint designer

With SharePoint designer simple workflows can be designed with the help of a wizard using built-in activities.

• Unlike with the OOTB workflows, you can also access other SharePoint contents in the site like Lists and lookups
• You can also define workflow variables and use them in the activities and notifications.
• With some tweaking you can also apply branching or parallel approvals.
• Unfortunately SPD workflow definitions are not portable but fortunately these are part of site backups.

4.    With SP Designer and Workflow Foundation

If the built-in activities and customization with SharePoint Designer is not sufficient you may have to go for the option 5 or 6, but wait, may be you can go for an 80-20 approach, by implementing the 80% (or 90%) simple functionality without  OOTB and SPD while 20% (or 10%) missing complex activities can be written with Workflow Foundation. Instead of writing the complete workflows in WF, it would be more economical interim approach in such scenario. But start writing your own activities, don’t forget to have a look at the activities already written by the communities  at Codeplx.

 

5.    Featured third party solutions

When advance features are required within very short delivery time, you’ve to look for an off-the-shelf featured solution. Which fulfills all or most of the requirements without requiring too much training and implementation efforts. But in that case you have to carefully review the comparison of the available solutions, since even the most popular and well promoted solutions can become a nightmare since you are already short of time and can’t bear the cost of experiments. There are couple of products available like Nintex, K2.Net, Ultimus etc while I am not going to rank them in this post.

6.    Writing your own with Workflow Foundation

When you business logic gets involved or you need advance workflow features like conditions, loops, split and merge, or routing based on input values (state machine), or communication with other adapters or external systems; you simply cant go with the above options. For such advance workflows, the natural option in .NET is writing workflows and activities using Windows Workflow Foundation where you can also use the WCF communicating with external systems. But before opting this option, one should be aware of the fact that beside how this solution is marketed, this is not a workflow solution but a foundation to develop one, as its name depicts.

 

7.    Writing you own workflow engine from scratch

This option is feasible for very few since making this riskiest decision requires really convincing  reasons, for instance:

• You are a workflow solution provider who’s interested to own the product
• Your team has understanding of the patterns and practices of writing workflow applications
• Your Experience on challenging workflow applications and awareness of the challenges
• Study of few good workflow solutions that how they address common workflow problems
• Sufficient resources for development so you wouldn’t go short of them in the middle of the development

I am pessimistic  when it comes to writing your own product, specially when it’s as challenging as a workflow solution as I’ve seen a lot more failures than successes.

I compared it with a movie seen, a very smart hired gun, and the central character of the movie, hero you can say –since in our movies hero means the most shown good-looking male character. So the professional killer was breathing his last breaths in front of the heroine who was delivering the usual state of the art, mind-blowing and heart-crushing dialogs just before the “Climax”.

Surprisingly the later incident brought a bunch of tears, oops. Isn’t it surprising? To better understand the scenario, I ignored whatever I saw and I listened, and just compared the stories without cosmetics. At one side a poor hand-to-mouth mother who brought up her children after years of  …………..  sacrifices –my poor vocabulary couldn’t find a proper superlative adjective to fill the blank. She lost her son, not a son but two. Is there any comparison between the feelings, the pain, the loss, the regret. No comparison with a girl who is going to loose her lover, the lover, who rationally –if not emotionally– deserves that due to his sinful –even if glamorous– life. The lover who might be attracted and affected by her appearance not her soul.  But why it felt more regretful than the former story?

What I did, I searched the interview (video) on the news website and played with a tragic background music. Yep it seemed to be a little tragic. Then a I read the whole story of the widow. Since then I was a little bit associated, it felt a little more touchy. I am not a graphic designer other wise I could remove the roughness, the result of years of dealing with circumstances. Neither I was a script writer who could tell her that what kind of mind blowing dialogged she should deliver to express her pain. Seems she didn’t have few drops of glycerin in her house to wet her eyes which perhaps went dry after releasing enough H2O since she lost her son. In addition, with her poor messy getup she wasn’t  complying with the definition of a noble lady, we have. During my childhood, I were used to feel fear from people with such getups. This kind ugly, messy and smelling people are aliens to us, how can we feel sympathy for them.

I concluded that since our subconscious age we are used to associate happiness and regret with a background music. We are familiar with neat and clean charming expressionist people as good guys and at the other hand, some poor ugly faces as bad guys.

Now we find examples where the “Preface” of a small, two paragraph, How-to article is itself a whole paragraph which often confuses the reader that what it is all about. Yesterday I was searching a How-To on internet and found an exact matching result but when I went to the page, I couldn’t understand what it’s all about, since the user is debating on the history and achievements of the product and trying to convince that his opinion is not biased. I skipped the first paragraph, again it didn’t match the title of the article, I skipped another and found something relevant. Seems the top two paragraphs were the price I had to pay since I were getting the rest of the brief and useful knowledge, free of cost. Or may be the author knows the minimum number of lines/paragraphs for a publication to be graceful But for me it’s too ridiculous to be understood.

If the following checklist returns positive results, it seems you are going to enjoy your leadership role otherwise you may gonna lose your respect.

Checklist

1.   You consider yourself responsible for the performance of your team members
2.   You are eager to know what they think about you
3.   You are eager to know and ask frequently if they are comfortable with the task or role
4.   You are eager to listen their suggestions and opinions
5.   You are able to avoid favoritism based on personal likeness
6.   You support instead of compete with your team members
7.   You insure that they have enough knowledge of the task before expecting any outcome
8.   You are well aware of the strengths and weaknesses of every single member
9.   You are well aware of the need hierarchy of every single member
10. You are not scared of their capabilities and/or performance
11.  You don’t want them to consider you as always-right
12.  You are eager to learn from your team members
13.  You always appreciate their efforts regardless if failure occurs
14.  You share the credit with the team
15.  You are able to see if any team member exploiting others or spoiling the team environments
16.  You take your team’s opinion before taking any decision
17.  You show your trust on them, avoiding unnecessary questions & letting them taking initiatives
18.  You keep your eye upon them but avoid annoying micro-management

Unfortunately, the senior and seasoned people in organizations usually do not realize that a fresh employee is just like a newly born baby. You can shape her according to your needs but you have to treat. These freshies do spare enthusiasm and passion but they lack direction and orientation. The assumption that they’ll start performing like their peers from the very first day, is nothing but a fool’s fantasy. Your team or organizations is like a moving bus whatever the speed is but these new passengers have to set their speed and you have to set their direction before they can jump into the moving bus.

1. The Fundamentalist Craftsmen or Blind Followers

There are people who have beleive only in proven practices. They always have the same number of documents, same life-cycle, identical design, and unbelievably a single strategy for every project. The most surprising point for me is that even the consecutive failures are unable to make them believe that there’s something wrong. Instead of trying to make some improvements and searching for the shortcoming in their practices and strategy, they start believing that failure is a norm, or it’s not failure at all. For instance, you’ll hear them saying “Clients never get satisfied” or “Losing deadlines is a norm in our industry”.

Example —makes things easier

In a software project, the offshore back-office development team shares the documents reside in their local repository with the on-site front-office team to let them update the documents. In absence of their access on offline document repository, the back-office team shares the documents via email with the front-office team. Obviously they get frequent version conflicts in documents and when it happens, they arrange a meeting and manually resolve the conflicts in the documents.  For months, they suffer with this problem but avoid change in their practice e.g. having an online document repository instead of sharing the documents on email. This approach is named as Brute Force approach by Steve McConnell.

2. The Innovator –or scientist, we can say

Away from the above category, the innovators are what most of our new graduates comprise of. They start with buzzwords like Web 2.0, cloud computing and believe that legacy practices are all obsolete and that the senior folks are not creative at all. They drive their projects for learning, ignoring the ground realities they neglect the cost and risk of change and avoid exploiting legacy patterns and practices. Since they believe that they make things better than they are, it’s possible if you see them writing their own DB connection pooling for technologies having built-in connection pooling or writing their own classes from scratch instead of extending the existing one. They often try to make simple things state-of-the-art and having insufficient knowledge and experience they get lost in the middle. This approach is named as “Silver Bullet approach” by Steve McConnell.

3. Engineering Mindset: the most needful

The moderate mindset – or engineering mindset as I say– tends to utilize and exploit the experience, invested by lots of great minds avoiding useless reinventions but never shy addressing the issues with a practice in the particular scenario. The mindset says that understand your objective whether it should be build-to-learn or learn-to-build. It says that to be honest and successful, an engineer shouldn’t behave like a scientist who build and destroy just for learning. And it says that there’s always room for improvement since improvement is a continues process and a going concern but it’s not the ultimate goal of an engineer which is to deliver the most optimal and economical.

A single practice may have various out comes when followed with or without reason. So, if a practice is being followed by majority, most probably there are reasons, try to find them, don’t shy asking other followers if you couldn’t,  but if nobody else knows, you have at least one reason to avoid it. Better to have your own with reasons instead of following blindly.

a request

Being an engineer, I do not think, I am right all the way; considering that I’ve limited amount of skills, knowledge, and experience. Your comments and disagreements are highly anticipated hoping it’ll help us having a more balanced mindset.

How DateTime Works
In strong typed languages like Java and .Net, DateTime contains the
date and time value as a consolidated numeric value without any format specification.
The culture aware ToString() method of DateTime converts the time value
according to the culture/format specifications of the system and configuration.

How to use?
Always use DateTime type for date and time values especially when savin/retriving DateTime values from/to Database.
Always use command parameters with proper types for passing values from application to database.

What to avoid?
Using string to contain DateTime values can become a disaster especially in large application.
You may find yourself trapped in a Format-Hell if you are assuming any particular format in calculation or representation
Never pass Datetime values as string across platforms or contexts for instance application-to-database

Parasitic workplaces are kind of Catch-22, at least for the hosts of parasites. Here host–according to the biological definition–is one who harmed by a prolonged, close association with the parasite, who is benefitted. As per Wiktionary, a parasite is “A useless person who always relies on other people’s work and gives nothing back”. Host, one who actually works for her employer, adding value but shares the credit with the parasite and unfortunately sometimes handovers the lion’s share.

Here I refer it a Catch-22 because at these workplaces, usually the hosts cannot get rid of the parasites unless they withdraws from their jobs. Increment in hosts’ efforts also strengthen their parasites. Their efforts are viewed as average performance of the team; a team comprise of hosts and parasites. Even sometimes the parasites get more than their hosts as the hosts struggle to increase the productivity while the parasites struggle to get the credit.

Usually in starting few months the host tries to perform more in hope of getting appreciation but it doesn’t help, instead it increases the average productivity and she finds her parasite being appreciated for it.

Having good ethical behavior, it doesn’t instantly bother hosts to share their credit with others. But when it becomes the norm, it sucks. The host which are the actual producers, start demotivating. Then they become divided in two different groups: the optimists and the pessimists.

The Optimists

Only few of them become optimist who still believe in performance, they try to bypass the glass ceilings to show the actual picture to senior management, who are too busy in their out-of-the-box matters. Again most of them fail to adapt such kind of behaviour that is, to put efforts to present what you have done instead of doing more, which doesn’t comply with their job description. Again Catch-22, they cannot rid of their sense of duty.

The Pessimists

Pessimists realize that they have been caught by Catch-22. This realization and the awareness that the lack in their performance will also weaken their parasites kill their enthusiasm, ruin their motivation and decrease their productivity. This situation helps in very rare cases when this decline in team performance could disturb the management and convince them to look into the matter.

This post is pending, author is still working on this post …

Several roles are defined in Scrum; these are divided into two groups; Pigs and Chickens, based on a joke about a pig and a chicken.

A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed but you’d only be involved.“

So the pigs are committed to building software regularly and frequently, while everyone else are chickens that are interested in the project but are really irrelevant because if it fails they’re not a pig, that is they weren’t the ones that committed to doing it …

The misfortune is that sometimes projects are implemented with the above incomplete and unbalanced specification. Following is the remaining part of this paragraph:

… The needs, desires, ideas and influences of the chicken roles are taken into account, but not in any way letting it affect or distort or get in the way of the actual Scrum project.

Responsibility and Influencing Power should meet at an equilibrium point just like Demand and Supply in economics. Otherwise if you are changing x, you are implicitly changing y. And if you think you can control it, just give it a try.

http://en.wikipedia.org/wiki/Scrum_(development)#Scrum_roles