Sunday, March 17, 2013

This blog has moved to a new house!

We keep getting asked where we have moved our blog or why don't we write anymore. The answer is simple, we have moved to a new blog engine at our new web site:

The focus of the blog has also changed from fun things or techie things at Kaz Software to our thoughts and efforts about creating great place for software development. Although we cover other things too.

We tell stories of fun things at Kaz on our Facebook page:


Techie things we have decided belongs to various blogs, tech sites (e.g. codeproject, msdn) because that way it gets more audience and also contributes to the community in a focused way.


Sunday, November 4, 2012

Outsourcing without code monkeys!

If there is one thing that we are really scared of at Kaz, it is "code monkeys".

Before I elaborate, let me define the exact meaning of the words "code monkey" in the context of  software development outsourcing - since it's not exactly well established expression outside the techie world.

Here is what I get from google if I do a define:"code monkey", courtesy of http://

"A Code monkey is a computer programmer or other person who writes computer code for a living."

Ahem, that doesn't help. Doesn't "...who writes computer code for a living" cover pretty much the entire professional software development community?

Much better are the definitions in this page:

And to be precise, in the context of outsourcing or offshored software development the definition that we are worried about is:

Code monkey:

"A programmer who isn't actually involved in any aspect of conceptual or design work, but simply writes code to specifications given."

Thanks to Phil Hawksworth for the pic.

But I love the other endearing definitions too but they are more about us in general, a downside (or upside - depending on how you look at things) of the profession we chose (or the only profession in which we could fit ourselves in). One very worrying definition on a personal level is the: "One who copies all code from other sources and prays that their code compiles." - how did these guys know about me????

But let me get back to the subject I promised to write about -

How do we manage to do outsourced software development without code monkeys?

That is: without creativity of initial design, without constant criticism of the architecture that they are implementing and eventually without care. Writing code because that's their job rather than writing code because it's their passion.

You might be thinking: "hey that’s a no brainer, you just get involved in conceptualization or architecture or do what you need to do make sure that you are not just blindly following specs whether you like it or not." But see the real problem is in the word "outsourced" in that question. Outsourced software dev would also bring in some if not all of the following concepts with it:
Someone outside your team

· conceptualizes the software.
· designs the architecture.
· does the UX
· writes the spec.
· defines the technology stack.
· etc.

Not so easy now, right? So how do we meet this challenge?

First and foremost, we are pragmatic.

We ARE an outsourcing shop - and by its very definition we would be helping someone outside our team build their software. So it is inherent in the model that someone else will be involved in any or all of the processes that make software possible. The question we ask ourselves is that how can we fit our desire for not being code monkeys in to this scheme and how can our clients benefit from our creativity. Here are some strategies we use:

0. Be open to the client from the very first day.

This is the obvious one - but you'd be surprised by how many companies fail on this. There is a feeling, and I think the biz side is to be blamed for this (sorry, all techies are saints and all things evil is for biz, of course!). Seriously, I think there is a feeling that an outsourcing company needs to give a feeling of extreme cooperation and compliance in every request made by the client. This is a major disservice for the clients. Technology is a field where there is no absolute right or wrong and it is the duty of the technology partner to be brutally frank about everything.

If the design is "**it" in the view of the software developers then it will always stay "**it" for them - it needs to be declared as such and argued out to the point where both sides either compromises or at least knows what are the basis of the decisions taken. 

The way to start this is right at the beginning. This would set the tone of the relationship and open up the culture of expressing thoughts freely. Yes, sometimes, on rare occasions this would be so against the culture or working mode of the client that it will create discords in the project. And I say that in such cases it is good to have that discord right at the start. If the disparity is such that the client leaves - then that is good - since if the fit is not right, an outsourcing project will ALWAYS fail. 

1. Setup a role both on client and our side which is just to air out our thoughts of discontent about design, feature, etc.

One of the unusual roles that we setup in our project team is that of the "Chief Complaints Officer - CCO". There is a CCO on both sides - client's and ours. And the duty of the CCO is to, you guessed it, listen to complaints and communicate those to his counterpart. This works both ways really - the CCO on the client side would regularly be telling us how their tech or management team thinks that our ideas just won't work etc.  

The CCO is typically the PM on both sides - but having this official unofficial role makes it simple to air out feelings through a proper channel. 

2. Initiation of any project goes through a period of critical analysis.

When we move to a new outsourcing project and a team has been formed for that one of the first thing we do as a team is to do a series of analysis sessions. The subject of the analysis could be whatever is the starting set of objects that we have - be it a feature list, a spec, design diagrams or an existing codebase.

These sessions serve two purposes - a)they give us a better understanding of the outsourced project but more importantly b) they make it possible to make the project "ours". The decisions of the project become "our" decisions rather than "theirs" because we fight it out amongst ourselves (and where needed with the client) and we accept the final set.

This, making things "ours", is critically important to avert the code monkey behavior. When it is yours you give it the love that it deserves and a lot of the times love in dev world is criticism and refactoring :)

3. Begining of any cycle arrange for an internal fight for and against the features, technology and the designs to be used in that cycle.

Same as 2, but on a smaller scale this time.

4. Create and maintain a culture where there is no fear to say what's on your mind.

This is cross cutting across everything we do at Kaz. A philosophical stance, for us. Software just cannot be made where you are not free to say what you feel about that software or anything related to it (well sometimes just about anything really).

Check out our culture page or our FB page for a glimpse of what we are like.

5. Hire people who are strong in airing out their thoughts.

OK. If you want to forget everything I said but want just one idea, this is the one. No plans work without the people implementing the plan. So at the end of the day every strategy is just a set of words unless you have the right people.

We hire the best developers. But one of our unusual interview technique is to see how a person manages arguments and how passionate they are about their views. It's easy to start an argument in the software development profession (with the right kind of people that is) - a simple "this would have taken a min to write in Python. I have no idea why people use C#" or something like this usually does the trick. But in general there are much subtler tacks than that.

Not an easy combination though - finding the right mix of talent and ability to communcate dissent. But it is one of those core challenges that you just have to face in this business.

Let me finish today by escaping this "teacher" tone of this article with a joke I came across when googling for code monkey:

“Q: What do you call a monkey who works in a call centre?”

“A: A who-rang-utang!”


Wednesday, October 31, 2012

The Blog returns

After a long time we are back to our blog! And the sole reason for all the neglect is purely work. We have been working really hard over the last few years just keeping up with the amazing software projects that we are involved in. Our writers and poets (ahem) were all too tied up with with trying to do C++ to C# port or a recursion, and our blog found no one to contribute to it.

There is one other culprit though, it is the ubiquitous Facebook. One of the reasons for writing was to tell our friends and fans what we were up to. Now our facebook page  does that job and does it really well. 

So why is the blog coming back?

Well, the main reason is that we are shifting the focus of the blog. Instead of just covering random things we are doing or curious about the blog will try to cover some of the challenges that we face in our business of making great software. 

There is really a lot to write about because the challenges we face are on a lot of dimensions. Although a lot of people "make software", our challenge doesn't just stop with just that sentence but with many more like the following...

"Making great software."

"Making software with the can do approach."

"Making software as the outsourcing partner - matching the expectation of low cost yet supremely good code."

"Making software with a culture of creativity and no code monkeys."

"Making software in the third world that anticipates the first world needs." 

"Making software because it's downright fun to make software."

"Making software when there is monsoon or heat waves, where there is strike on the streets, when the Internet just trickles in somehow and when power is something optional." (Too embarrassing to highlight - so left it without the bolds :) )

People keep asking us how we do what we do. And this blog reborn will try answering them. But it might also cover old ground of what we are up to - since its just too tempting to leave out!

Wish us luck (and some writing time).

Thursday, February 2, 2012

Yet another win for Agile

We've been talking about how to help our community at Kaz for a long time. Being a bunch of "techies" that’s no easy goal!

We thought, we'll use our experiences of software process to achieve this goal. That immediately led us to some brainstorming sessions, which led to chaos (as usual) and minor ideological war (even more usual), this led to a wiki page for idea submission. But hey that’s the PROCESS!

We got a lot of ideas, some of them phenomenally good and some borderline crazy. We thought we will pick up some of them and start. But that’s where things stopped.

After cycling through this several times we realized that we are really running things classic Waterfall with big design upfront and all of its smelly friends (sorry, you have to forgive me for these weak allusions, but this blog is consumed mostly by software guys). Anyway, we realized we need to go agile and take some baby steps to get something done.

As luck would have it, pretty much around same time of this ground breaking, earth shattering realization that agile is good, a dodgy looking guy dropped in at Kaz. He came as friend of a Kaz guy but it turned out he is a super secret philanthropist who runs a teaching program for street children pretty close to us. This was our chance! We went agile with him.

So the success of this baby step is that we are now proudly providing snacks for every child that turn up for the class - and that acts as very good magnet to keep the children coming. The next baby step is that we do some basic computer skill training to the children (I know, somewhere someplace that machine had to come in). Sadly the secret philanthropist tells us that teaching them C++ (which we feel is a must for anyone touching that machine) won't be very helpful for the kids so we are sticking to the "how to click the start button" path. But we hope that this is a start of bigger and better things - maybe even some of our ideas in the wiki too.

If you feel like making a baby step too, feel free to drop in at the street class at around 4pm on the street that leads from Aziz Super market to Paribag:

So yet another karma point for Agile - this thing is definitely making it to the Nirvana.

Wednesday, November 25, 2009

Extending WCF Part I

by Mosfiqur Rahman

Senior Software Engineer @Kaz


Microsoft WCF Framework (System.ServiceModel) provides several extension points
from where developer can extend the framework when it requires. In this Part I article
I'm going to cover two perspective of extending WCF framework:

1. Lets think about a WPF desktop application or a WPf browser application or a
windows desktop application or a .net web application, built on service oriented
architecture and all the back end services are WCF services. Now for several reasons
you may need to change the server for your service which in turn changes your service
URL or you may need to change the configuration of service bindings/behaviors. If
you change any WCF configuration at the server you need to provide the same bindings/behaviors
configuration to the clients also to work the client-service interaction properly.
And this is very difficult in typical clients like XBAP (WPF Browser application)
clients. My ExtendingWCFPartI.WcfExtentions.dll component provides a solution to
this. You can have an external configuration file (e.g. by downloading it from server
before client application starts up) where service endpoints are configured properly
and use that external configuration file to create the WCF service proxy instances.

2. In many cases we want to get exactly the same exception thrown from WCF service
at WCF client. ExtendingWCFPartI.WcfExtentions.dll component also provides this.


Extending ChannelFactory<T>

This extension is to serve the first introduction item.
In general System.ServiceModel.ChannelFactory<T> provides us the option to
get a proxy instance programmatically instead of using the proxy generated through
svcutil.exe (.NET Framework tool). I've extended this class to write my own ExtendingWCFPartI.WcfExtentions.ExtendedChannelFactory<T>
class to provide the external configuration file functionality.
The constructor argument "configurationPath" should contain the full path of the
external configuration file. Then I override the ChannelFactory<T>.CreateDescription()
method to apply the external configuration file. The external configuration file
looks exactly the same as conventional client's app.config or web.config file. For
sample external configuration, you can look at the ExtendingWCFPartI.Client.WcfClientConfiguration.xml

Extending WCF Service and WCF client behavior

To provide the second introduction item, we need to
extend behavior of service, endpoint and contract.

public class ExtendedServiceErrorHandler:IErrorHandler
#region IErrorHandler Members

bool IErrorHandler.HandleError(Exception error)
if (error is FaultException)
return false; // Let WCF do normal processing
return true; // Fault message is already generated

void IErrorHandler.ProvideFault(Exception error,
MessageVersion version,
ref Message fault)
if (error is FaultException)
// Let WCF do normal processing
// Generate fault message manually
MessageFault messageFault = MessageFault.CreateFault(
new FaultCode("Sender"),
new FaultReason(error.Message),
new NetDataContractSerializer());
fault = Message.CreateMessage(version, messageFault, null);

}// end of class

ExtendedServiceErrorHandler should be injected into

error handler list. Then WCF Framework will use our
implemented IErrorHandler.ProvideFault method when any exception is thrown from
service. Inside the method implementation I used the NetDataContractSerializer to
serialize the MessageFault which will be trasmitted to client.

public class ExtendedClientMessageInspector:IClientMessageInspector
#region Methods

/// Reads the soap message to find the
/// node. If found than deserialize it using the
/// NetDataContractSerializer to construct the exception.
private static object ReadFaultDetail(Message reply)
const string detailElementName = "Detail";

using (var reader = reply.GetReaderAtBodyContents())
// Find

while (reader.Read())
if (reader.NodeType == XmlNodeType.Element && reader.LocalName == detailElementName)

// Did we find it?
if (reader.NodeType != XmlNodeType.Element || reader.LocalName != detailElementName)
return null;

// Move to the contents of
if (!reader.Read())
return null;

// Deserialize the fault
var serializer = new NetDataContractSerializer();
return serializer.ReadObject(reader);
catch (FileNotFoundException)
// Serializer was unable to find assembly where exception is defined
return null;


#region IClientMessageInspector Members

/// Create a copy of the original reply to allow
/// default processing of the message. Then its reads
/// the copied reply to find Fault Detail using the ReadFaultDetail method
void IClientMessageInspector.AfterReceiveReply(ref Message reply, object correlationState)
if (reply.IsFault)
// Create a copy of the original reply to allow default processing of the message
var buffer = reply.CreateBufferedCopy(Int32.MaxValue);
var copy = buffer.CreateMessage(); // Create a copy to work with
reply = buffer.CreateMessage(); // Restore the original message

var faultDetail = ReadFaultDetail(copy);
var exception = faultDetail as Exception;
if (exception != null)
throw exception;

object IClientMessageInspector.BeforeSendRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel)
return null;

}// end of class

Now we need to extend the IClientMessageInspector to get back the same exception
at client end. At IClientMessageInspector.AfterReceiveReply method implementation,
NetDataContractSerializer has been used to get desrialize the fault exception and
get the actual exception back again.

public class ExtendedServiceBehavior:Attribute, IServiceBehavior, IEndpointBehavior, IContractBehavior
private void ApplyDispatchBehavior(ChannelDispatcher dispatcher)
// Don't add an error handler if it already exists
foreach (IErrorHandler errorHandler in dispatcher.ErrorHandlers)
if (errorHandler is ExtendedServiceErrorHandler)
dispatcher.ErrorHandlers.Add(new ExtendedServiceErrorHandler());

private void ApplyClientBehavior(ClientRuntime runtime)
// Don't add a message inspector if it already exists
foreach (IClientMessageInspector messageInspector in runtime.MessageInspectors)
if (messageInspector is ExtendedClientMessageInspector)

runtime.MessageInspectors.Add(new ExtendedClientMessageInspector());

To tell the .NET runtime to use my ExtendedServiceErrorHandler at Service end error
handling and ExtendedClientMessageInspector at client error halding we need this
ExtendedServiceBehavior class which implemented service, endpoint and contract behavior.
All behaviors have an AddBindingParameters method, an ApplyDispatchBehavior method,
a Validate method, and an ApplyClientBehavior method with one exception: Because
IServiceBehavior cannot execute in a client, it does not implement ApplyClientBehavior.
For more details you can read the

Using the Code

For simplicity, I've hosted the WCF service at console. To run the sample code and
see it working, follow the steps below:

1. After opening the "ExtendingWCFPartI" application with VS, right click on the
ExtendingWCFPartI.Service project then click Debug -- > Start new instance. Doing
so, you have ensured that the service is running at console host.

2. Then run the ExtendingWCFPartI.Client project under debug mode.

ExtendingWCFPartI.WcfExtentions.dll is the reusable component which is going to
be used at both WCF client and WCF service. Also make sure that you wrote the custom
exceptions in a common assembly which will be used at both WCF client and WCF service.

Using the code at WCF Service

At first let me show you how we can use this component to host our WCF services. You
can host the WCF services at IIS or at Windows Service or at console, no matter
where you host it, add the following section at your app.config or web.config ServiceModel
section. Add a reference the ExtendingWCFPartI.WcfExtentions.dll to your service
host application

<add name="ExtendedServiceBehavior" type="ExtendingWCFPartI.WcfExtentions.ServiceBehaviorExtension, ExtendingWCFPartI.WcfExtentions, Version=, Culture=neutral, PublicKeyToken=null"/>


ExtendingWCFPartI.WcfExtentions.ServiceBehaviorExtension has been used to tell WCF
framework to use ExtendedServiceBehavior at its CreateBehavior() method.


<behavior name="CustomServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceThrottling maxConcurrentCalls="16" maxConcurrentSessions="16" />
<ExtendedServiceBehavior />


Now create a service behavior like the example above. <ExtendedServiceBehavior
/> ensures that this behavior configuration will use the ExtendedServiceBehavior.

<service behaviorConfiguration="CustomServiceBehavior" name="ExtendingWCFPartI.Service.CustomerService">
Your service endpoint's configuration goes here.

Thats all you need to do to host your WCF service which will have the two functionalities
explained at introduction.

Using the code at WCF Client

Add a reference to the ExtendingWCFPartI.WcfExtentions.dll at your client application.
Now create the external configuration file. It may look like following:

<?xml version="1.0" encoding="utf-8" ?>
<add name="ExtendedServiceEndpointBehavior" type="ExtendingWCFPartI.WcfExtentions.ServiceBehaviorExtension, ExtendingWCFPartI.WcfExtentions, Version=, Culture=neutral, PublicKeyToken=null"/>

.. tips: provide the same binding which has been used at service
<behavior name="CustomServiceEndpointBehavior">

<ExtendedServiceEndpointBehavior />
<endpoint address="http://localhost:8036/Services/CustomerService"
binding="wsHttpBinding" bindingConfiguration="CustomWSHttpBinding"
contract="ExtendingWCFPartI.Common.Services.ICustomerService" name="CustomerServiceEndPoint" />


Now save this external configuration file at any location of your hard drive with
.xml or .config extension. e.g. "C:\Temp\MyAppServices.xml".
I've provided a very simple inerface ExtendingWCFPartI.WcfExtentions.WcfClientHelper
to get the instance of proxy.

public static T GetProxy<T>(string externalConfigPath)
var channelFactory = new ExtendedChannelFactory<T>(externalConfigPath);
return channelFactory.CreateChannel();

At client code use this interface to call your service method:

var externalConfigPath = @"C:\Temp\MyAppServices.xml";
var proxy = WcfClientHelper.GetProxy<IMyWCFService>(externalConfigPath);

Points of Interest

There are many more extension points at WCF framework which are very interesting
and usefull. I'll try my best to cover few more examples later in my next article.
In brief, I found the WCF framework so well designed that programmers have almost
all the options to do whatever he wants.

Wednesday, November 4, 2009

Designer = can do XAML !!!

Sunday, October 25, 2009

It means a combination of “Creativity and Coding”. Yes now a Designer can be a coder as well. Perhaps you are thinking that it’s a crap :-). Nope it is real. I never wanted to go to the programming world. I think it is a bit boring and monotonous for a designer. Some couple of month back our CTO comes and requested me to learn XAML. He explained all the prospects of XAML in a positive mode. At that time I was thinking that what my CTO is saying is truly a fantasy web world. One question was hitting repeatedly in my mind and that is “CAN I DO THAT?”.

Yes XAML is truly a fantasy playground for a designer. After getting 2 months successful training (Thanks to our CTO and special thanks to Taufiq for being an excellent XAML teacher) on XAML I got the confident and started doing coding immediately with the other developers :-). Ok cut off the story of mine and let discuss the prospect of XAML.

XAML is a new descriptive programming language developed by Microsoft to write user interfaces for next generation managed applications. Extensible Application Markup Language or is a new declarative language that is used in Windows Framework and Windows Presentation Foundation. Introduced with .NET Framework 3.0, XAML is harbinger of declarative (in contrast with imperative using coding) programming model. In Workflow Foundation, workflows can be created using code as well as XAML. Even fully XAML-based solutions are possible with no code at all! This not only gives flexibility of no-compilation-needed to applications, it also opens up a window of possibility for entirely non-technical persons (like business analysts) to design workflows. (Though Workflow Foundation is targeted for programmers, experiments are underway around the globe for making it feasible for business analysts to model processes in it).

Let me ask a simple question. Can you build a Combo box on a button? Or can you customize a button for a Combo box? Very difficult or even not possible in other programming languages but it can be done in XAML with a few lines of code. So a Designer can play around wherever he/she wants to. So the bottom line is Designer can now think out of the box, can do outstanding mockups for web or desktop application.


For XAML, we need to have a basic knowledge on XML, CSS. You will get lot of tutorials for XAML on the net. So learn XAML and discover the future.


Thursday, March 12, 2009

Shadows of Sinensis

- Md. Ferdous Bhuiyan

Shadows of Sinensis

Shadows of Sinensis, a memorable trip to Srimongol, will remain afresh in the mind of Kaz family. Fun-loving Kaz Family went on rampage to obtain unlimited ‘Furti’ and relaxation during our 3-day tour to Srimongol from 15 to 17 February, 2009. Eventful Srimongol trip offered us relaxation, fun and most importantly the joy to share with our colleagues and family members. The team of Srimongol trip encompasses each and every one of Kaz Family. Young stars of the team aged 3-month to 3-year provided the team with pure and refreshing entertainment in the lap of nature. All of us along with our spouses and kids looted the unlimited joy by swimming in the pool, climbing the mountains, wandering in the wilderness and having delicious foods.

Shadows of Sinensis

Powered by 41-member, Kaz team reveals the sportive frenzy of Kaz family. Many of our enthusiastic players as well as cheering audiences enjoyed watching and playing Cricket, Badminton, Football and Table Tennis at daylight and even at night using light. Frenzied bedding accompanied by enthusiastic cheering gave the events a special glow.
Silence of the evenings was shattered with the sound of laughter provoked by lively ‘Adda’ and the melody of harmonica and songs sung by us ruled the isolation of night. Monotony or tiered is something that failed to touch the mind even for a second. Luxurious and well-furnished bungalows became the place to spend last few hours of night to start a new day with more enthusiasm.

Shadows of Sinensis

A spur-of-the-moment decision fixed the day scheduled. Going to ‘Lawachara’ or finding out the tea-stall named ‘Nilkantha’ to have multilayered tea was decided within a few minutes with the urge to know the unknown. Such whimsical decisions to visit outside of the Tea Resort made the trip more attractive and gave us the chance to experience something new and adventurous. Those who were more attracted to water of appealing swimming pool were busy with swimming and diving throughout the whole noon.
Delicious Food must be there to color a memorable time. We the KAZ people vowed not to get hungry and have delicious good food with every single chance of celebrating party. There is no exception of this oath even at Srimongol trip. Being the fan of delicious food we grilled chicken and included delicious dishes for a sensational dinner and enjoyed the last night having spicy food and dessert.

Shadows of Sinensis

Sensible traditional ethos of our firm revives with this lovely trip. And it would be no rhetoric to reiterate the truth that ‘Shadows of Sinensis’ is a great step forward for the neatly tied Kaz family to enhance its fellow-feelings and team spirit as ever.

Shadows of Sinensis