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

Parasitic Culture: another Catch-22

 

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 …

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.

Don’t let them leave or change

I don’ t know whether it’s a common phenomena or not and whether it has been written in HR books or not. Having being hunted by this problem during my early days, when I got the first chance to lead people, I started observing people silently. Without showing any reaction, letting them be more and more exposed.

I collected events and behaviors, analyzed and discussed these behaviors, concluded the results, and to make the decision making process complete and fool proof, I started getting feedback. The results were positive.

So being a line manager, are you able to identify some precious resources under your supervision who seem to be ordinary?

Common characteristics of these resources

• These people are often too shy to communicate
• They often seek opportunity to add any value to their company, even if they are not satisfied
• They do not show unusual efficiency in the presence of their seniors because of their honesty
• Often they seek for a chance to help their colleagues without expecting any return
• You may find them helping others even if they have their own tough time lines
• If they respect you, they would not tell you, instead they’ll work for you harder
• They’ll contradict you , in your own interest
• Sometimes they fail to meet the time lines because they do not want to compromise on hidden quality, while others do
• They utilize their leisure time in solving some other problems your company may face
• Sometime they silently solve some potential problems which can become a disaster for you in future

How to deal with them

- If their responsibilities are some back office or technical tasks, their weaknesses may be in your favor along with their strengths

- Most probably they would not ask you for appreciation and incentive. You have to identify their micro achievements which may have resolved some macro problems; appreciate them

- Don’t let them get rid of innocence and honesty, appreciate these characteristics

- Be aware of some smart asses under you who can exploit these innocents by taking their credit

- When they lose they time lines because they were helping others, don’t criticize them for it. Just appreciate them and tell them:

• To prioritize the criticality
• To prioritize their own task, if criticality is same
• Or to discuss it with you (supervisor)

Being a line manager, you are not necessarily dealing with managed people. They may lack some skills while having some others. You have to study your resources thoroughly and closely. Identify their actual value instead of the perceived value. May be you would have a different perception after this practice.

Trends in Software Job Market

Following trends have been concluded by me after conducting interviews and discussing with my juniors, peers, seniors, and some students.

• Most of the small software houses have the following hierarchy:

CTO/Dept. Head >> PM >>TL >> SSE >> SE

• Most of the Resource Managers (Team Leads) are planning to become Project Manager
• Senior technical positions–Architect, for instance–are not available for seasoned technical people
• Senior Software Developers are planning to become Team Leads to get raise in benefits instead of focusing on scarce senior technical positions
• Most of the resources have working experience of small-size offshore projects, they don’t have the experience and expertise of Enterprise Solutions
• Most of the fresh graduates prefer better salary on career growth & learning
• After initial 2 years, having some quick job-switches, some of them realize that if they could learn, they could earn more. Then they change their mind to prefer learning over adhoc monitory benefits
• It’s becoming general perception among software industry that to become a project manager is the shortest path to get fat salaries
• Computer Science Graduates are preferring to get admission in MBA instead of MS
• In MS(Computer Science), Project Management is becoming a buzzword
• It seems that in few years, we will have greater number of Managers and lesser number of technical resources, at least in software development

Disclaimer: This are my personal observations, not unnecessarily true.

Laws of Systemantics by John Gall

1. The Primal Scenario or Basic Datum of Experience: Systems in general work poorly or not at all. (Complicated systems seldom exceed five percent efficiency.)
2. The Fundamental Theorem: New systems generate new problems.
3. The Law of Conservation of Anergy{sic}: The total amount of anergy in the universe is constant. (”Anergy” := ‘human energy’)
4. Laws of Growth: Systems tend to grow, and as they grow, they encroach.
5. The Generalized Uncertainty Principle: Systems display antics. (Complicated systems produce unexpected outcomes. The total behavior of large systems cannot be predicted.)
6. Le Chatelier’s Principle: Complex systems tend to oppose their own proper function. As systems grow in complexity, they tend to oppose their stated function.
7. Functionary’s Falsity: People in systems do not do what the system says they are doing.
8. The Operational Fallacy: The system itself does not do what it says it is doing.
9. The Fundamental Law of Administrative Workings (F.L.A.W): Things are what they are reported to be. The real world is what it is reported to be.
10. Systems attract systems-people. (For every human system, there is a type of person adapted to thrive on it or in it.)
11. The bigger the system, the narrower and more specialized the interface with individuals.
12. A complex system cannot be “made” to work. It either works or it doesn’t.
13. A simple system, designed from scratch, sometimes works.
14. Some complex systems actually work.
15. A complex system that works is invariably found to have evolved from a simple system that works.
16. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.
17. The Functional Indeterminacy Theorem (F.I.T.): In complex systems, malfunction and even total non-function may not be detectable for long periods, if ever.
18. The Newtonian Law of Systems Inertia: A system that performs a certain way will continue to operate in that way regardless of the need or of changed conditions.
19. Systems develop goals of their own the instant they come into being.
20. Intrasystem{sic} goals come first.
21. The Fundamental Failure-Mode Theorem (F.F.T.): Complex systems usually operate in failure mode.
22. A complex system can fail in an infinite number of ways. (If anything can go wrong, it will.) (see Murphy’s law)
23. The mode of failure of a complex system cannot ordinarily be predicted from its structure.
24. The crucial variables are discovered by accident.
25. The larger the system, the greater the probability of unexpected failure.
26. “Success” or “Function” in any system may be failure in the larger or smaller systems to which the system is connected.
27. The Fail-Safe Theorem: When a Fail-Safe system fails, it fails by failing to fail safe.
28. Complex systems tend to produce complex response (not solutions) to problems.
29. Great advances are not produced by systems designed to produce great advances.
30. The Vector Theory of Systems: Systems run better when designed to run downhill.
31. Loose systems last longer and work better. (Efficient systems are dangerous to themselves and to others.)
32. As systems grow in size, they tend to lose basic functions.
33. The larger the system, the less the variety in the product.
34. Control of a system is exercised by the element with the greatest variety of behavioral responses.
35. Colossal systems foster colossal errors.
36. Choose your systems with care.

How to get the worst of all worlds

 
This is the story of ancient war between Software Scientist and Software Craftsmen on the ground of Software Engineering
The Scientists

Slogans:
   Let’s reinvent the wheel
   Complexity is charm
   Think out-of-the-box (never look inside)

Whenever company gets a project the developers are in search of well-hyped patterns and practices. Whatever the projects require, whatever the timelines are, they follow impressions, seeking complexities to passionate their lives. The problem is they want to combine the universal truths they get from their gurus, with the hypes. They get the compliance in few of the cases. It becomes a routine that start with complexity and when you stuck, let the things fly.
They often suggest the solutions they think they should learn. According to their point of view: software projects are to create a difference, even if the project fails, even if they do not add any value, if they implement state-of-the-art technologies, they consider it success.

The Craftsmen: the delivery people
Slogans:
We deliver
Quality is just a fantasy, don’t talk about it
Ad-hocism
Research is a synonym of time-wasting;

Fortunately some of the projects who comply with hyped patterns and rigid practices succeeded to achieve the timelines, thanks fortune. And now the support people are ready to show their quick solutions. They’ll show that the tasks completed by the developers in month was just a matter of days. Thanks to encapsulation; no one knows what’s inside J

Till the day the application is safe from the quick solutions of support staff, it shows some stability. And once it gets the first JUGAR—synonym for a careless ad-hoc solution in Urdu language—the application becomes more addicted to their JUGARs and provides more options for support people to prove their problem solving skills.

How to choose from Viewstate, SessionState, Cookies and Cache

Problem with Web Applications

Web applications are stateless, means once a web page is rendered from server to client, nothing in the page remains on server and the next time user submits the page, the page will be called and created from scratch.

ASP.NET provides following solutions to solve this problem:

1- Viewstate
2- Session Variables
3- Application Variables
4- Cache
5- Cookies

Now the question arises that when to use what?

1- Viewstate

Viewstate is a hidden fields in an ASP.NET page, contains state of those controls on a page whose “EnableViewstate” property is “true”.
You can also explicitly add values in it, on an ASP.NET page like:
Viewstate.Add( “TotalStudents”, “87″ );
Viewstate should be used when you want to save a value between different round-trips of a single page as viewstate of a page is not accessible by another page.
Because Viewstate render with the page, it consumes bandwidth, so be careful to use it in applications to be run on low bandwidth.

2- Session Variable

Session variables are usually the most commonly used.
When a user visits a site, it’s sessions starts and when the user become idle or leave the site, the session ends.
Session variables should be used to save and retrieve user specific information required on multiple pages.
Session variables consumes server memory, so if your may have a huge amount visitors, use session very carefully and instead of put large values in it try to put IDs and references

3- Application variables

Application variables are shared variables among all users of a web application
Application variables behave like static variables and they are substitute of static variables as static variables are stateless in web applications
Only shared values should be persisted in Application variables, and as soon as they are not in use they should be removed explicitly.

4- Cache

Cache is probably the least used state feature of ASP.NET.
Cache is basically a resource specific state persistence feature, means unlike session it stick with resource instead of user, for instance: pages, controls etc.
Cache should be used or frequently used pages, controls, and data structures
Data cache can be used to cache frequently used list of values e.g. list of products

6- Cookies

Cookies are some values saved in browsers for a particular website o publicly accessible
The purpose of cookies is to help websites to identify visitors and retrieve their saved preferences
Cookies are also used to facilitate auto login by persisting user id in a cookie save in user’s browser
Because cookies have been saved at client side, they do not create performance issues but may create security issues as they can be hacked from browser

Finally remember the following points on your finger-tips:

1- Viewstate is bandwidth hungry
2- Session variables are memory hungry as per number of users
3- Applications variables are shared
4- Cache is memory hungry as per number of resources
5- Cookies are the least secure

http://www.codeproject.com/KB/aspnet/HowToChoose.aspx

Why Patterns Suck?

Surprised when I heard some people saying “Patterns suck”, I was eager to know why some people hate these precious guidelines which save us from reinventing the wheel, letting us using it.

Fortunately after just few days I had to work with some confident people, known as pattern-lovers. Having a lot of technical knowledge, they were used to remembered the names of patterns–and there authors as well–on finger tips. People, you can speak technobabble with, for not just hours but for days. In the first place, I admired them and found myself among knowledgeable people.

Then I found something strange, besides all their knowledge they had very few success stories and their management was not satisfied with their problem solving skills.

I had started observing the causes of their failure. Mean while I had to design an architecture for a coming enterprise project. I started scaffolding by enhancing and optimizing my legacy libraries and framework with my team. I asked these people to review my approach to let my approach become foolproof.

Geeks love technicalities so I got a prompt response and they started highlighting the weaknesses, I was very glad as I got a chance to improve. But unexpectedly most of the issues identified are as follows:

Geeks: Aren’t you using NHibernate?

Me: Nope, I personally admire NHibernate for it’s pure objects and database independence but I think that this application do not have complex business logic, instead it comprises of complex reports which is not a specialty of NHibernate. While our framework provides Report Factory and configuration as well tiered approach for reporting. Another reason is that our expertise i NHibernate do not allow us to use it in a time-critical project at this stage.

Geek: What? Do you know where NHibernate came from, it’s a port of Hibernate, being used in the most powerful language Java. It has nothing to compete with Microsoft.

Me: Yes, I agree that Jave and it’s platforms are a lot more mature but every language or technology has some of its own specifications and advantages. Our framework and libraries are optimized with the objects provided with .Net. Our wrapper classes exploiting some new features provide in the laster version of .Net.

Geek: Hey don’t use ADO.Net objects, they do nothing but violates layering These objects are a mess. You should use pure objects that’s why I recommended you to use NHibernate.

Me: I think it depends that how are you using them, in our scenario they are completely database independent because they are boxed in generic objects and are created by Abstract Factory so we can enjoy Inversion of Control, Polymorphisms, and Database Independence.

Geeks: These libraries are not open source, you don’t know what they have written in it.

Me: I admire the benefits of open source but these object are rich, free, built-in, tested and performing well in enterprise applications. I do not very often use them but I found them very useful in such kind of applications.

Geeks: You incorrectly applied this pattern; let me show you the documentation.

Me: This pattern like other patterns have different applications, I am following this approach because it performs well in this scenario. This flexibility is also allowed by experts.

Geek: No, patterns should be followed as is. They are not to be changed for performance or whatever. And remember enterprise applications, built on great technologies like EJB, looks graceful even if they are not enough performant.

Geek: Increase your number of layers like we have did in that application. You have not decoupled enough.

Me: Yes previously I do have the same number of layers but I found it as an overkill in this project, so I modified this version for medium-sized performance-hungry applications.

Geek: And why did you coupled these two major tiers, this is an unacceptable violation of N-Tier Architecture

Me: No, these are still two different layers, but I am keeping them in a single project during development as most of the developers are working on both layers. They still can be deployed on different servers.

Geek: I’m still not satisfied, a lot patterns have not been used, recommended by our gurus and we follow them because we know they are the best.

Me: They might have recommended it for some different type of project and this approach may be suitable in that particular scenario.

Geek: We found their practices the best in all type and size of projects, whatever, it’s not that simple you think it is, you have to add a lot more omplexity.

Me: May be you are true as I found you a lot more knowledgeable but I learned and beleive that a complex system that works is invariably found to have evolved from a simple system that

… that’s how I got my answer that “why people hate patterns?”