Archive for programming

Tradition vs. Innovation: story of an ancient war

If you notice, you may observe that most of our nonintellectual discussions and conflicts 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 patternsnot 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, at least in our local industry as I see.

1. The Fundamentalist Craftsmen or Blind Followers

There are people who have strong belief in old 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 failure is 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 the on-site front-office team to let them update the documents. In absence of their access on offline documents the local team shares the documents via email with the remote 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 shareing the documents on email. The term coined here is Brute Force approach as Steve McConnell called it

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 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 legacies: 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 in 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. The term coined here is “Silver Bullet” as Steve McConnell says.

3. Engineering Mindset: the most needful

The moderate mindset – or engineering mindset as I say– tends to utilize and exploit the experience, invested by the lots of great minds avoiding useless reinventions but never shy to address the issues with in the particular scenario, if it doesn’t fit with. The mindset says that understand your objective whether it’s 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 it’s a going concern but it’s not the ultimate goal of an engineer instead it’s to deliver the most optimal and economical.

A single practice may have different 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, dont’ 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 believe that I am right all the way; considering that I’ve limited amount of skills, knowledge, experience. You comments and disagreements wil be anticipated hoping they’ll help us having a balanced mindset.

Leave a Comment

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

Leave a Comment

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

Comments (2)

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.

Comments (3)

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

Comments (4)

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?”

Comments (1)