Thursday, August 19, 2010

AutOmatiOn WiLl NeVEr RePlAce mE !!!

In my experience, there are many ways to use automation to assist people with work, and reduce the load needed, but ultimately we always need a human in the loop. Someone should be available to check that the calculation or the change in process is the correct one. Someone also has to be able deviate from what seems to be the rule for some process and override it.

I've seen this in the past in a few places. Once where I worked with a chef trying to automate his ordering process. He was sure that he could input recipes, make guesses about usage, and then inventory constantly, adjusting his predictions and a well designed inventory system would calculate purchase orders for him. I don't know if his predictions were poor, or if the logic wasn't correct, but he didn't ever seem to have as good a hand on his inventory as he needed. I used that as a basis for a liquor inventory system when I was bartending, but took the "recommendations" from the system and adjusted them based on intuition. That seemed to work out much better.

Real life if messy, and often I think we try to simplify it so much with our models that we don't build a system that really works well. I'm of the opinion that technology is here to assist us, not do the work for us, and we need to keep that in mind as we design software. Allow for the experienced professional to override things and use their experience to make the final decision.

Thursday, August 12, 2010

What motivates programmers?

 I will start with a question, if you have a spare £400 in your development budget do you A) Reward your star programmer with a £400 bonus or B) Buy him a 24 Inch 1920x1200 LCD screen?

If you answered 'A' then you need to read on. If you answered 'B' then you understand what motivates programmers but I suggest you still read on and comment later if you have any ideas beyond what I cover.

One of the things that they never teach non-programmer managers is how to motivate programmers. You may think the programmers are motivated by the same things as the rest of your staff, you are WRONG. Programmers tend to be counted within the higher IQ brackets and are therefore harder typically to second guess.

The average programmer may be projecting an image of superiority but non-programmers miss-read this and think it is aimed at them. It is not. You have to understand that programmers rate themselves against other programmers not against anyone else.

This is important when making any decision about how to reward them. If you purchase some new equipment for your sales staff the likely reaction will be ... nothing. If you purchase new equipment for your programming staff they will immediately start analyzing who has got what and by reference who is being rewarded more than others based upon the quality of the equipment. If you think this is not relevant think again.

What this comes down to is that the work environment is generally more important to a programmer than any kind of financial reward (within limits). But managing who gets what within your company is not easy.

You can just take the view (and if you have a big enough budget) that everyone is standardized and that you all get the same equipment. This in practice within a development environment never works because each programmer may require a very specialized setup which breaks the standardization rule and your back to 'who gets what'.

Hardware Cascade

Programmers outwardly will try and give the impression that they are a loose nit bunch who care nothing for standard business practices and certainly not give any importance to the usual office politics of who is above who. This all goes out the window with new equipment because the hardware is seen as a status symbol within the 'non-existent' programmer hierarchy.

So when upgrading machines it is vitally important that you understand the structure of this invisible hierarchy. I typically upgrade at the top of the tree and push machines downwards, this can mean lots of re-installing but most programmers will be very happy to put in extra hours to perform the re-install if the reward is a new machine (or at least a faster machine)

The appeal of solving a problem

Programmers program because they love to solve problems. Remember this rule:

“"If you give a programmer a job that does not involve solving something they will become unhappy."”Solving can mean many things and it is easier (and more important) to understand what classes as a 'non-solving' task. Typically asking a programmer to go fix something would be classed as 'non-solving' as the solution has already been found and you are asking them to re-solve it by having to look at the code again.

What is important is that you find ways of making 'non-solving' tasks into 'solving' tasks. A typical example would be the difference between asking one of your programmers to put together a report (e.g. some usage statistics) by hand or assigning him more time so he can 'solve' something and produce an automated system that will email you the report every day/week/month. Other typical non-solving situations

•Writing documentation

•Creating schedules

•Writing reports

•1st Line Support

All programmers have to perform non-happy-non-solving tasks and some cope better with dealing with a higher 'non-solving' ratio of tasks than others. Understanding your programmers and who can cope with what level of 'non-solving' is important to keeping an overall smooth operation.


Programmers see meetings as wastes of time. Most communication between programmers is done via email or by a quick wander to another desk to clarify something that is beyond the scope of an email. Therefore any time within a meeting room is 'unhappy time' and unhappiness increases exponentially with the length of the meeting. So at all costs if you do need to drag your development team into a meeting either include some form of Lego to play with (I am serious) or keep them very short.

Why bother with _any_ programming language?

After reading a question on HN, I started thinking again about programming languages. Does it matter if you know one or plenty? Can you know 5 languages equally well? Or even well enough to claim that you actually know them?..

What's the actual difference?

If we're talking just of statically-typed, object-oriented languages, there's not much difference. Only thing you should always be aware of, is memory management. If there's a garbage collector, you don't really care about pointers and disposing objects yourself. You also sacrifice part of performance and memory (not always true, for certain, since Garbage Collection most of time allows you to avoid memory fragmentation / segmentation, and you always get single slice of allocated data, and free memory for further allocations). Although, better understanding of heap and stack, pointers, values, passing messages comes from languages, where GC is not available by default. Hence, in c++ you still can use Boehm GC, but existing patterns such as smart pointers and pools are quite useful, and you can get far enough without GC, and remain certain you have your memory managed, and can be certain about when the object gets freed. So, you have stuff to learn from both worlds. You get to know, how to manage your memory, and how to delegate management. Quite useful, isn't it?

Moving to dynamic dispatch, and loosing certainty of method existence prior to execution is a tough goal. Dynamic languages bring up a whole new world of expanding your object, making system more flexible, mixing in, extending natives and so on. Ruby gives an ability to do hardcore mixins through modules, which is widely used all around Rails. Active Record found a perfect use for method_missing, which certainly is a great idea. Kernel.autoload is a good idea. It also seems to me that these are patterns, or templates rather than simple methods or extensions. Something you can benefit of. Same thing is relevant to Scala Traits. Ruby Gems and Python Packages are both great ideas, even though Ruby guys went further and made it easier. Lisp s-expressions were picked up by Microsoft guys and turned into beautiful expression trees in C#, that changed a lot of things, when LINQ broke the ground.

Code reading and practice comprehension

Code reading skills are essential for all the developers. Know several people who'd stick to their language, and would never even try to expose the unknown. Is it that bad, though? Not quite. Let's think of programming for a bit more. At first, looking on a new language, try not to get to the situation when you're diving too deep into the framework, rather than language itself. The thing is that if you see that there's a framework, wonderfully written and performing well and it's open-source, you can take a look on the code, read it up and get to know some practices. But without language knowledge it's going to be not that easy. You all know that story about alias_method_chain in Rails / Ruby community. Some practices came out of tutorials, and lot a of people never thought of the better way of doing that. Most likely, same exact thing happened to .NET postback-oriented model and ViewState, when people have forgotten of a web way of persisting state. Same thing happened to default position of Django models and views in Python, that are kept in a single file. For some reason, a whole lot of people do not want or even do not know how to separate them.

Next time, when you start looking for another framework, whatever you're working on, just ask yourself, if you _can_ write it yourself. If not, dig into it, understand the way it's written and reasons behind it (I realize, that it's not always possible, but Open Source World extends every single day). And do not learn the framework. Learn language. APIs change, some other day you may be even forced to extend or modify it for your own needs. What's your first though when your hacky selectors do not work in your favorite JS library? Googling solution only gets a half of a problem solved. The other part remains untouched: an ability to perceive the code, read it up, debug it, understand the root and fix a cause with your own hands.


New languages are cool. They make you think of syntax again, and force you to shift your paradigm. You start looking on your own code from a different point of view, just by thinking of what would it look like if it's in any other language. You think of garbage collection, or freeing memory, whether it's relevant for certain cases, and may checkout implementations of things in other languages too. So, my IMHO is that any other language may help you to get to know lots of new things about the one you're currently using.

Wednesday, August 11, 2010

The Month of Ramadan

Ramadan  is the ninth month of the Islamic calendar, and the month in which the Qur'an was revealed.
Ramadan is the holiest of months in the Islamic calendar. Fasting in the month of Ramadan is one of the five pillars of Islam. The month is spent by Muslims fasting during the daylight hours from dawn to sunset. The name came from the time before the Islamic calendar, when the month of Ramadan fell in the summer. Fasting during this month is often thought figuratively to burn away all sins. Muslims believe that the Qur'an was sent down to the lowest heaven during this month thus being prepared for gradual revelation by angel Gibril (Gabriel) to the Prophet Muhammad (Peace be upon him). Furthermore, the Prophet Muhammad (Peace be upon him)told his followers that the gates of Heaven would be open all the month and the gates of Hell would be closed.

The first day of the next month is spent in celebrations and is observed as the ‘Festival of Breaking Fast’ or `Eid ul-Fitr.


  • Ramadan is observed by Muslims during the entire lunar month by the same name. The month of religious observances consists of fasting and extra prayers.
    • 10 Ramadan, death of Khadija – first wife of Prophet Muhammad (Peace be upon him).
    • 12 Ramadan,
    • 15 Ramadan, birth of Hasan ibn Ali.
    • 17 Ramadan, the Battle of Badr was won by the Muslims.
    • 19 Ramadan, Ali bin Abi Talib was struck with a poison-coated sword, used by an assassin.
    • 21 Ramadan, Ali bin Abi Talib died due to the poison and injuries he sustained by the sword.
    • Laylat al-Qadr is observed during one of the last ten odd numbered days of the month. Muslims believe that this night which is also known as The Night of Power is better than a thousand months. This is often interpreted as praying throughout this night is rewarded equally with praying for a thousand months (just over 83 years i.e. a lifetime). Many Muslims spend the entire night in prayer.

Managing IIS Pipeline Mode for Backward Compatibility

Ever since the induction of IIS 7, there came a cool new feature for developers to leverage called Integrated Pipeline. This feature in a short explanation closely couples ASP.NET and IIS more closely. It allows allows writing of IIS Modules in managed code, how neat is that? This also slightly changes the behavior of ASP.NET, such as introducing new events on the HttpApplication (Global.asax) and the event cycle. A classic example is where in Integrated mode you cannot access the current request using HttpContext.Current.Request during theApplication_Start event, which makes sense.

Now for obvious reasons this can break existing applications, and cannot be used for applications that will be installed in mixed environments, such as Server 2003 and Server 2008. Fortunately, IIS 7 make it easy to switch it back back to its old behavior using the Classic Pipeline by configuring the IIS AppPool. Most commonly, if you make a web-based product then your application will usually require Classic Pipeline to stay backwards compatible.

Even if you have a detailed instruction manual, this can be an easy step to miss - and results in some icky error messages. Wouldn't it be nice if you could display an nice error message to your customers that their pipeline is configured improperly?

Well fortunately there is a way to do that. Ironically, we will be using part of the Integrated Pipeline to get that accomplished with the help of an HttpModule.

What we will be doing is writing an HttpModule that will basically stop the current request, write out a friendly message that links to a Knowledge Base article, and only do this if our application is running in Integrated Pipeline. The module to get this done is pretty simple, we would write it like any other HttpModule. Here is the code for mine:

using System;

using System.Web;

namespace MyWebApplication


public sealed class IisPiplineCheckModule : IHttpModule


public void Init(HttpApplication context)


context.BeginRequest += context_BeginRequest;


private void context_BeginRequest(object sender, EventArgs e)






public void Dispose()





As you can see, there is nothing particularly difficult. It just hooks into the BeginRequest event of the Application, and writes a file called pipeline.htm to the response stream and closes the response. Pretty simple, right?

Well the final trick is getting this to work only in Integrated Pipeline. Unusually, there is no easy way to do this with the .NET Framework (that I was able to find). However we will leverage the web.config to accomplish this.

For IIS 7, there is a new section in the web.config file called . This is one of the sections that IIS 7 pays attention to. What we will do is introduce our module into IIS 7's Integrated Pipeline, but not into the old that has been existing for a long time. Let's look at our new section and examine it.

There are two interesting points here. The first is actually adding out module. Notice the preCondition. This is telling IIS 7 that our module should only be running in Integrated Pipeline by specifying the integratedMode flag. For the Type we just set the full namespace and class to our HttpModule and the assembly it is located in.

The second interesting point is that if you have standard HttpModules registered in the configuration/system.web/httpModules section IIS 7 will point out that there are modules in there that are not in the system.webServer configuration. We can, if we want, disable that through the validation element.

And ta-da, we now have a module that writes out a file, but only for Integrated Pipeline. You can customize the pipeline.htm file as much as you'd like. As far as I can tell, this is the only easy way to determine if your application is in Integrated or Classic Pipeline. The alternative is to WMI query the IIS metabase, which is a little more high risk and more complex.

Vitamin D, Sunshine, and Rainbows

My past employer's office have windows next to each individual cabin. There I had the good fortune of working next to a window in our office.

Though the joke around the office is we’re going to suffer from a Vitamin D deficiency. Why? It’s because there is no window or place that natural light gets in.

I never really considered how much of a difference it makes, I always wanted to think “lamps are good enough”. Honestly though, I found myself having more energy and being much perkier in natural light.

 I’m not usually one known to be “perky” either.

So I want opinions, how important is a window in the office to you?

Tuesday, August 10, 2010

The Sad Truth About Best Practices

… is that most of the time, they won’t work for you or me. They worked for somebody, some time, in some situation, in the past. Sure, the idea of best practices is attractive. Supposedly you or I can follow along, obediently, and succeed using so-called best practices. Too bad it doesn’t work.
For example, Jim Collins’ blockbuster business book Good to Great, published in 2001, featured 11 supposedly great companies. All of them did extraordinarily well on the stock market for 10-20 years. But by 2008, when Steven Levitt posted Good to Great to Below Average on Freakonomics, two of them had died. He wrote:
Nine of the eleven companies remain more or less intact. Of these, Nucor is the only one that has dramatically outperformed the stock market since the book came out. Abbott Labs and Wells Fargo have done okay. Overall, a portfolio of the “good to great” companies looks like it would have underperformed the S&P 500.
I don’t mean to criticize Jim Collins, his book, or his methodology. I do mean to question the whole idea of so-called best practices. There are so many built-in problems. What works in one case is hard to translate to the next case. It’s different times, places, people, resources, problems, and so forth.
The best use of the so-called best practices is as generator of new practices, new ideas, new possibilities for you, in your business, that you might be able to take in, digest, and adopt to your situation. It’s a lot like business cases and business stories, not intended as recipes to be followed, but rather as examples of what other people did.
However, you have to be careful. Don’t ever just blindly follow. You always think about it, consider the options, how it might be different in your case, and then, if it still sounds good, try it. Carefully.
If I ever give you any advice, I want you to please never take it without thinking first, analyzing, and deciding for yourself whether or not, and how, and to what extent what I say fits your situation.

Look into yourself

You have learnt so much

And read a thousand books.

Have you ever read your Self?

You have gone to mosque and temple.

Have you ever visited your soul?

You are busy fighting Satan.

Have you ever fought your

Ill intentions?

You have reached into the skies,

But you have failed to reach

What's in your heart!

(Baba Bulleh Shah)

12 Things A Software Engineer Really Needs To Know

How do you answer the question, “what do I need to learn to be a good programmer?” I have written posts trying to answer that question, typically focusing on the languages that you should learn or the algorithms and other techniques you need to know. What about the rest of a programmer’s life? This is a less serious look at the life of a programmer. So, what does a programmer really need to know?

1.Caffeine – You need to find your preferred caffeine delivery system. Mine is black coffee, early and often. Others may prefer diet soda throughout the day. There are always the classics as well, Mountain Dew and Jolt.

2.Logic – As a programmer, you deal with logic constantly. Your true mettle will be defined by how you deal with the insanity (real or perceived) of the customer. The customer could be your project manager, the business analyst or the users. For any given project, you can count on someone sounding completely insane.

3.Hours – Expect to be working a lot of them. Programming is one of those jobs that refuses to follow the 9 to 5 path. As you get closer to your deadline, the hours you work will increase quickly. Just hope that you can work from home sometimes. Also, weekends and time off are for management, and you need to be available at all times.

4.Corporate Leash – You may not have any power to make decisions, but that does not mean the company cannot give you a leash. The ability of constant communication is too much for companies to pass on so you will likely get a crackberry, a pager (people still use them), or some other company provided cell phone. No, your leash will not be an iPhone, this is not meant for fun this is business.

5.Blame – As a programmer, you are the low man (or woman) on the totem poll. Just remember that shit rolls downhill, the buck stops with you and if there is a defect it is obviously the programmer’s fault.

6.Sleep – More importantly it is the lack of sleep that you need to be concerned with. As your hours increase, you will find there is less time to sleep. You will have to call into a conference call at 7AM with your offshore team, or support a 5AM deployment on Saturday.

7.Skills – Your skills typically do not matter in the corporate environment. There are plenty of programmers that do not have jobs and could fill your position. Your expertise in the business domain is not important because there are business analysts that are supposed to be the experts in the business. You are replaceable, you are just a part in the corporate machine.

8.Odors – As the hours get longer and management reads something about the productivity of team rooms, the odors start to get worse. We are not talking about someone heating up their lunch. We are talking about the stereotypical, unkempt programmer sitting in a room full of other unkempt programmers. After some time, the room starts to smell like a camel, and it is not pretty.

9.24/7 support – Yes, you will be pulled into support at various times, even for something like a customer service site. The application may not be life threatening or revenue threatening, it is just job threatening. So, your corporate leash will ring at the worst possible moment and you will have to get on a conference call with 10 people who have no idea how to fix the problem but need to be involved from the management perspective and one other person that might be able to help you.

10.Stress – Project failure is never an option. You cannot miss the deadline even though it was not the deadline you proposed. No, you cannot remove features from the application in order to make the deadline either. You need to deliver the entire application by the deadline, or the entire team could be fired. Nothing like a little pressure with your morning coffee.

11.Non technical managers – These people are considered the bane of most programmer’s existence. They need to manage a group of programmers, but they do not understand what they do for a living besides “they write code”. They typically overpromise, underdeliver and treat their programmers like cattle or “resources”.

12.Political battles – This is one of those things that programmers are rarely directly involved in. However, your project and even the whole team could become the casualty of some political war. You have no power to prevent any of it, but you are definitely involved. Keep listening to the rumors so that you have some warning that something bad could happen.

Obviously, these ideas will not happen everywhere and are much more of a worst-case scenario. If you see several of these things at your current employer or even a prospective employer, you may want to run the other way. Given that you already carry a cell phone anyway, don’t worry about the corporate leash, they will just want your current cell phone number.

Game I am playing these days

It's the year 1942 and a strike force of commandos is sent for a task in Nazi-occupied France. The team consists of Colonel Brown, the "spy", Captain O'Brien, the "muscle", and Lieutenant Hawkins, the "sniper". After France they are sent to Norway, and then to Stalingrad, where the game ends.

Below are some Screen Shots.

Monday, August 9, 2010

My open source project contributions

 I was thinking for a long time to contribute, to an open source project, for the betterment of other people. I just found Microsoft's powered website and started to contribute in two projects
Each project's description is given as under.

Sea Quail is a library for building SQL queries using objects in .Net. It's intended to work with any mainstream RDBMS. Add/remove tables, columns, and foreign keys, insert, update, delete, and select programmatically, without string building. It's developed in C#.

Fractal is a os that is designed to be fast, and Graphical.