Distribution: Layers vs. Tiers
Even though there’s so much written on this topic and I really don’t like to discuss the discussed, the motivation here was observing general ambiguity regarding the difference between Layering and Tiering among interns. So here without going into details we will just discuss the difference.
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.
Simple charisma test: what makes you a leader
If you have assigned a leadership role where you are responsible for the performance of couple of people, this simple checklist may help you.
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
Take the lead
At the end of two years in revolutionary efforts like team building, strategy aligning, building a technical architecture and an efficient and simple programming platform we could come out of the state of deficiency and chaos, which is a norm of industry like ours (immature and subject to change) and people like us (developed by 3rd world’s education system). Fortunately, I had couple of people who were honest with their profession and people. They were just seeking for couple of cheap but rare organizational attributes like direction and appreciation.
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.
Tradition vs. Innovation: story of an ancient war
If you ever noticed that most of our nonintellectual discussions and debates are wars between tradition and innovation. Here you may find a person trying to convince others that one should stick with the legacies: experienced, practices, and patterns — not necessarily using the said words but some contextual jargon— while the other person is contradicting like if only innovation and creativity can make a difference or in other words you learn as you go. The same quarrel exist in our software engineering field.
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.
Understand DateTime, avoid Format-Hell
One of the most common mistakes programmers do is to treat the DateTime as string, or in another words always assuming a specific date format.
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
Pigs & Chicks
I couldn’t stop myself laughing out loudly when first time I came across the following paragraphs about some Roles defined in Scrum —an Agile development modal.
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
ASP.Net Page loading twice
If you are observing load event twice in a post back in ASP.Net page, check the following:
- If Page_Load handler defined in Codebehind then AutoEventWireup property should be “false”
- Check if you have mistakenly multiple event handlers registered for an event
- Src or ImageURL attribute of your image control are defined and not empty (you can put %20 for blank)
- bgColor or background is empty
Last two problems usually appears in one browser while disappears in other.

leave a comment