The Art and Science of Website Design

One day whilst at a museum showcasing art by a very famous artist a 7 year old boy stood in front of a painting showing a single brown dot, a blue sinuous line and nothing else. The painting was apparently of a woman sitting by the riverside. The child turns to his parents and says “hey you know I could draw that” much to the laughter of the surrounding patrons. Then what exactly made this painting by such a famous artist so special? Was it the simplicity of subject, idea and form? It was design.

Design is all around us whether natural or man-made. We always try to differentiate something by comparing designs. Whether it is a simple cellphone, a piece of furniture, the home we live in, the food we present and eat, anything we do has aspects of design incorporated in to it. So when it comes to a website that is actually our way of declaring “hey I am here this is me” design plays a pivotal role in capturing the attention of our intended audience as well as communicating your message.

Website design is an art and a science. Why? Well if you look at the millions of websites on the internet all vying for attention it is easy to realize why so much effort is placed into design. Starting from statistics, consumer behavior, psychology etc. elaborate attention to what processes get the largest audience and readership have become a science for website design. If we look from a different perspective attractive websites are no longer simple pictures or texts jumbled together, they contain audio, video, stunning images, and are increasingly interactive all making website design an art.

“To Be Or Not to Be” A Great Website:

So how do we design a great website? Well the first thing to think about while designing your website is what you want to communicate and who you want to communicate that too. That is targeting your audience with the right message. Most people will not spend a lot of time on a website browsing through material so it is important to keep your message concise. Think in terms of branding how do you want your audience to remember you and design your website accordingly. List out the main things that you do or want to express, make sure you do not drift from your main functions as this will dilute any message you wish to convey.

 

“Emotions Are Good” for Website Design:

Good websites are designed to have a personality of their own. It may have humor, be serious but it should invoke in the visitor some kind of emotional response. Employing images, animations, audio or video can easily grab and retain the attention of the audience as well as make it more attractive at an emotional level. Websites with images of faces and people also help to make your visitor feel more at home using sentimentality gives your website a much more personal appeal.  Check out the Moto G Website

 

Simplicity Equals to Sophistication

A great way to really loose the attention of a visitor to your site would be to cram it full of needless information and have a cluttered design that would quickly exasperate any visitor as they tried to navigate the site. Often the simplest designs are the most attractive so don’t go overboard by adding too many elements to your website. Clean designs are something Apple does very well 

 

 

Interactive Website Design

People love to interact with their environment. Adding interactive elements to your website increases its appeal significantly. The user experience becomes more personal leading to a richer more memorable experience for the visitor. Adding elements like sound, or other audio visual stimuli that appeal to one or more of the human senses lead to a positive experience for any visitor. Keeping the visitor involved doing something on your website means that they are bound to spend much more time going through it. Here is a good example... try out their fidgety menu bar!  http://rog.ie/

The People and Process of Website Design

Bringing together the multifarious elements of designing a website can be a daunting task. That is why it is important to have a team who know exactly what needs to be done to get your website up and running. The team should be able to cover all aspects of website design including coding, art, prototyping, customization, testing and validation (etc.) just to name a few.  The ability of a team to create responsive designs, inspirational outlooks and looking at issues from a different perspective all contribute to the designing of a great website.

That is why we at KAZ software have the some of the most experienced professionals from diverse backgrounds dedicated to give you the best website you can have.

Barbecued dog is good for software

Sorry for the show of the bad taste in the title. It is however not completely done for the sake of sensationalism. The idea for the title comes from a trip by the sea that we at Kaz software went to. We did a big barbecue of a whole lamb spit roasted on top of an open fire on the beach. Somehow someone claimed that it could easily pass on as a barbecued dog and that phrase caught on. So in the folksonomy of Kaz a barbecued dog party is where we do a barbecue under the open sky - something that we do at every chance we get.

So why is  it good?

It's good for different reasons. But at the core they are all the same - it brings people together and creates a bonding. There is something in making food together sitting around the open fire with smell of burnt meat in the air that brings out a very innate human bonding. Maybe it's the left over traces of a hunter gatherer tribe, maybe it's the psychological security and assurance we feel in the act. Whatever it is, it works like magic in making friends. And as we are all aware, a gelled team is the biggest factor for a successful software.   


5 Easy steps to kill the deadly PDI in your software team

PDI or power distance index is deadly for your software team.

Don’t know about it? You must read up all about it from our article about the power distance in software teams. Here is how I define power distance in the software teams:

How likely is a junior programmer to tell a senior about an error in the latter’s code?

Teams with large PDI will end up with those errors not discussed and resolved and thus with a buggy and at the end of the day a failed software. Thus it is of utmost importance that PDI be reduced in a software team.

The big question is: is it possible to reduce PDI? A valid question since PDI has been shown to be tied with cultures. But it has been shown that with the right effort and plans the cultural hard wiring can be overridden and PDI can be reduced and lives saved as it turns out:  in the case of Korean Air in late 90s. 

Korean Air had more plane crashes than almost any other airline in the world for a period at the end of the 1990s. This trend was finally pinned down to essentially power distance in the Korean culture which makes co-pilots very deferential towards the pilot and effectively cutting off the check and balance in the cockpit. Korean Air completely changed the trend by recognizing that PDI exists and taking steps to counter it. The success can easily be seen by the sudden reduction of the air disasters from the early 2000.

Although no study has been done in Bangladesh on PDI, but I can tell just by knowing our culture (and also looking at PDI scores of neighboring India) that the story is bad. So we’ve been very careful to take steps to reduce our PDI here at Kaz Software. Over the years we’ve tried lots of things but I can distill them all down to 5 steps that I know works likes magic. Here you go:

1.    Make your team aware about the risks of power distance.

The great thing about software team members is that they are uber smart. If you can make them aware of the risks of power distance and how it affects their work product it immediately has an effect. This is something we do at every chance we get – starting from the day someone joins us and continuing at almost all the team meetings and brainstorming sessions. The awareness gives the team members to speak out when they worry if speaking out against a senior might be being rude. Which takes me to the 2nd step.

2.    Train your team to be rude!

Well at least train them to speak out. Being nice and well behaved is the worst things that a developer can do to his team! Train them to have a strong voice of dissent, of being not nice when it comes to reviewing code or software design. A big tradition at Kaz is to “introduce” a newbie to the fine art of saying “you are dumb” in multiple ways!

3.    Make self-deprecating humor common

This is slightly more difficult. But if you can plot this with the seniors in the team this becomes the easiest way to break the ice. A common joke at Kaz is that seniors can’t code that well because they are slowly losing their grey matter. It’s brought up at every chance we get when we worry about code – and soon enough the juniors in the team start to use it.

4.    Do events that break down the barriers

These could be during the ubiquitous “team building” events or events specially designed to reduce PDI. The aim is to create a feeling that we all make mistakes – so the goal is different from the usual team building event’s goal – different enough to make special plans for them. The idea is simple, setup a situation (in a game, a show, etc.) where juniors have an edge over the seniors or where the seniors intentionally make a fool of themselves for fun. At Kaz the team leads dressing up as dodgy looking ring masters of a game are a good example.

5.    Make team structures as flat as possible 

This is the most important one. It’s the strongest message that you can send to the team about your intentions of keeping the PDI low. The whole gamut of hierarchy and respect just doesn't work in software and the sooner you kill it the better. 


The deadly power distances in a software company

It all started with a Geert Hofstede, who in the late 60s did extensive experiments to prove that how we operate in a corporate environment is very much a function of our national culture. He measured responses of 117,000 IBM employees (he was working with IBM at the time) across different countries and showed that there are distinct biases about our reactions based on where we are from. He grouped the attitudes he was measuring in four types and called them the cultural dimensions. 

Of these dimensions Power Distance index (PDI) is the most interesting, I think, for software companies. Power distance is in simple terms how submissive (or not) is someone to his superiors in a hierarchy. For a software company it boils down to a simple question:

How likely is a junior programmer to tell a senior team member when he spots an obvious error in the latter's code?

If he is likely scream at the first chance then the power distance is low and if he is more likely to not raise an alert the power distance is high.

Hofstede showed that PDI is directly correlated with the country you are from. And this makes perfect sense - some countries have culture of strict hierarchy where are elders are honored without question. These cultures imbibe its children with that value of respect and submission to seniors that obviously shows up in work culture. Countries with high PDI include India, South Korea, Malaysia (sadly no data for Bangladesh, but it is without doubt a high PDI country). Countries with low PDI are US, UK, New Zealand etc.

So what is wrong with high or low PDI? 

Well, it depends I guess in which work area you are in. I'm sure high PDI is great for families (oh how I wish my word be the law for my two unruly sons - high PDI is definitely welcome at my home!), high PDI is probably good for places like the army (when you tell your soldiers to jump in front of machine gun fire you don't really want them to point out the futility of war, e.g.) but for some industries it's downright a disaster (literally). In 1994 Boeing published safety data showing a correlation between a country’s plane crashes and its score on Hofstede’s dimensions. And it is easy to understand why - in such a complex operation as flying a modern aircraft the chances of error are high for the captain. The first officer's major role is as a second pair of eyes for error detection and mitigation. Yet in high PDI countries the first officers (much lower in the hierarchy of things compared to the captain) finds it difficult to voice their concerns. And when you have that over millions of flights you start getting statistically significant effect of the high PDI causing crashes to happen.

And so it is for software. One of the basic facts in the game of software is that everyone (including the uber geek who has been programming since the 90's - well specially him!) will make silly mistakes. The only way to save a piece of software from these mistakes is by constant double checks. Software QA is a double check for sure, but that as we know is way down the path. The earliest double checks are the screams of team members during the design sessions and coding. And this is why a software company craves (or should crave) for ultra-low PDI. This leads us to a simple statement:

Software can only be made faster and less buggy by having low PDI.

So the most important question for a software company then becomes 

Can PDI be lowered?

  And thankfully the answer to that is 

YES!

The important thing is to recognize that there is a need for lower PDI and then there are many things that can be done to lower it. There are documented proof of such efforts and the resulting wins in the airline industry. We at Kaz Software have been doing that for the past ten years in our little niche! 

How? The answer to that question will be another blog coming soon.

 

Java still loves you - Please wait

You must've got that irritating message popping up when you log-in to your windows where it says there is a new version of Java available (or even worse the windows UAC pop-up with the worrying question of "Do you want to allow the following program to make changes to this computer?" ). Well take solace in the fact you are not the only one in history - Java has been irritating the humans with this for quite some time. Joel even wrote a small article in his blog as far back as 2009 and came up with the wise words

 

"...This whole damn dialog could read

Java Loves You—Please Wait

without any loss in functionality..."

 

Well nothing has changed in the intervening years. The message is exactly the same wildly pompous message of 

“By installing Java, you will be able to experience the power of Java”

Actually somethings have changed - Java is now Oracle and the UI has managed become even worse (how they managed this feat is amazing though, extra brownie points for the red java.com hyperlink).

 

Then ...

Transient

And now ...


PS. Just a quick disclaimer- we are no Java hate group, actually we love it. Kaz Software has a very strong Java team (it has always had one right from our humble beginning). We work and have worked on all sorts of Java based web applications and love the robustness of the platform. 



Burn the cubicles - in the pursuit of happiness

Kaz revolves around the word happiness. It’s around everything we do. We continually ask ourselves: “are we happy?”. We have a rule of thumb about failure that says: if one day we wake up and think of going to work as a pain then we will know that we have failed.

Many question our principle of happiness as the core business philosophy. Many are clearly baffled that this can be true. And many just laugh it away as a triviality – not believing it to be true. But if you think about it it’s the most obvious thing, it’s amazing that so many companies in the world miss something so basic. The pursuit of happiness is inherently a human endeavor. We spend most of our waking life at work, a significant number of modern human relationships are connected with work – given these facts isn’t it obvious that we need work to be based around happiness?

So what does the pursuit of happiness entail at workspace? There is no sure shot formula – you just have to go by your feelings. But if you were to ask us, what is one thing we must do as the first step in the pursuit for happiness – we would scream:

Say NO to cube farms

Cube farms are evil. They are inhuman. They were made by some alien droids that had no concept about being human and living a normal human life. If you want to achieve anything close to being not sad – burn those cubicles.

So if not cube farms then what? People have to work somewhere. Well we believe that the most natural space in our lives is our homes. So if we can mimic anything about our home at workplace that will bring happiness. So that is why we love our office that is not a purpose built open space for cubicle animals. We work in houses built in the 70’s that we have converted to offices ourselves. They are not inhuman multi-storied building but human two storied buildings (amazingly the two building we are based in are exactly the same architecture because they belong to the same family!). They have open space in front with large trees that have real fruits in the summer (an amazing thing by the way in the concrete mess of Dhaka). They retain old mosaic patterns that were very popular in Dhaka during the 70s and 80s.

 

 

Our seating is as asymmetrical as possible – almost chaotic. We try to give large tables that all look a bit different from each other. We sit with the wall at the back – so that it feels safe and we don’t feel watched. Our monitors are kept in a way so that the screen cannot be viewed by someone approaching us – so that we have our privacy. As un-cubicle like, as possible.

So once again, do everything you can to your workspace to stay away from the cube farms. Be happy!

// Shameless plug begins:

Get our expert help in your software projects today!

// End of shameless plug :)

 

 

Lessons in creating a software business

We are ten years old this month. We started out on June morning in 2004 as a “company” where we had no rules, no goals and no clear plan of what we would do to sustain ourselves – we only knew that we just have to make it a place where people are happy. Over the decade we have learnt many lessons on what to do and what not to do in the business of software. And today I want to write about the lessons we value the most. It would have been great if someone gave me this list ten years ago, but I also wonder if I would have believed it enough to follow it!

Creating a company based on a single vision works

For us it was the vision of: “work should be place of happiness”. It sounds nice, it sounds right but is it good enough to carry a company to profit and permanence? I honestly feel it is – in these ten years a lot of things have happened, many business decisions had to be made and many a crisis had to be overcome, but it was always this single vision that guided us in all our thoughts. Having a single vision meant we could easily decide among multiple options that we had in front of us. It gave us the road to travel and the strength to walk that road fast.

I am not sure if our particular vision is important, it was for us and it worked great. But I think any overarching simple vision that you truly believe in, that everyone in the company can understand and embrace would have worked. Having a simple vision is important. Without it (or with too many of them) I feel we would have been lost.

Software business is all about the right people

Selecting the team members in any company is important. But I feel in the business of software this one thing can make it or break it. You could have the lousiest idea about a software product in the world, but if you have the right people they change it into something amazing – and obviously the other way round. I think in no other modern world business is the product of the business is so malleable, so sensitive to the craftsmanship of the people building it.

So, hiring decisions are the most important decisions in a software company. We learnt to be patient, to be more exact and to be more careful when hiring new team members. If this meant that we lost important business we learnt to live with it – that’s how it is in this world.

Think only in the long term

All our decisions that have been based on short term thinking have failed or have haunted us. Somehow this very ephemeral world of software requires a very non-ephemeral structure to stand on. So we learnt that buying this server “just” for this six month project doesn't mean we can compromise on the quality. We learnt that bending the rules “just” this once to meet this deadline backfires pretty soon. There is nothing short term in software business – it’s hard to believe that this is true given how software projects work.

If you are not hiring a great C++ guy now since you don’t have any projects right now, it’s probably a big mistake. If you are saving a few dollars on a server you’ll probably regret it next month. The list is really long and scary – but if you do want to be successful you just have to believe that you will be around for a very long time.

Only thing that works is an environment of trust

Software is so inherently a collaborative effort that only if people feel safe in trusting others that the whole thing works. Otherwise you spend all your energy trying to force external systems and rules to make that collaboration happen – and it keeps failing. Only an environment of trust can achieve software products that are on time, relatively bug free and usable.

An environment of trust builds up primarily from the actions and policies of the company. It builds up from the actions that people in positions of power take and how those actions are perceived. Any system or rule that you bring that has an impact on that perception has to be considered carefully before it is put in place. So if you thought that nifty time tracking tool you just bought will turn the company around, think again, it might be the first nail in the coffin.

Never, ever be “set in stone”

Software is always a moving thing. And no wonder that a software company should also be like that. What works today, what worked so well last time, has every chance of failing to tomorrow. You will always have to adapt your rules, policies and business practices. If you are doing great as a business now, beware tomorrow the technology might change or the customer’s need for a certain feature might evaporate. That’s how it is in this game. And the only way is to be able to adapt.   

people software company


A decade in this software world

June 2014 is the 10th anniversary of Kaz Software!

This is a big milestone for us all. The journey was amazing and the friends we made along the way, the adventures we had, the laughter and tears we shared are unforgettable.

In memory of those beautiful times I want to share today some of our group pictures from the yearly anniversary trips we did in various places.  

 



Cat on a hot software company

If you are curious about the title (and you should be!) the explanation is easy:

The blog is about Ms. Meow the cat - the official Kaz Software mascot. The blog is also tangentially about the importance of making a place of work, particularly a place of creative work, feel like a real human habitation (as opposed artificial "corporate" one). And last but not least the title is a shameless attempt to push a picture of Elizabeth Taylor and Paul Newman in of their finest moments :)

The mascot

Ms. Meow is a cat with a strong personality. She knows what she likes (techies and food) and she knows what she doesn't like (admin droids and banana). She is very conscious about her career improvement, as can be seen below - she learning the art of SQA with full dedication. (I'd like to point out that she is far from an ornamental mascot - she is the savior who protects us from the clutches of the evil mice :)  

WP_20140128_bw.jpg

The workplace like a real human habitation

I agree, this paragraph looks suspiciously like a weak attempt to bring credibility to this blog post. But I assure you it is not. From the day we started ten years ago, we made innumerable decisions to make sure that our place of work feels, as close as possible, like home. This is not an easy task, mind you. It is not as easy as putting some pictures on the wall or setting up a comfy place to sit, etc. Well I should say it not just those things - there are many reasons why home feels like home. The visual aspect is only a small part of this big story. 

But why make it like home at all? Well that is a long tale with no definite story-line. But it is really a point of view (amongst many) about workplace. But it is a view that we at Kaz subscribe to very passionately.

I can't do it justice, so let me quote something I read recently in a book review (and I quote without credit - in the world view that in the post Google world there is very little need for such a thing): 

Understanding that humans biologically evolved to cooperate and that leaders emerged to protect the group, organizations that create environments paralleling those early conditions will bring out the best in us. This means taking steps to avoid the allure of abstraction in modern life by keeping it real and avoiding the perils of scale by keeping team sizes that mimic those of human tribes.

The picture

OK, cutting to the chase, here is the picture. It is from the movie Cat on a hot tin roof made in 1958. When the monochrome was at its best in human history and when nothing could beat the sizzle of Elizabeth Taylor and Paul Newman. (As a last attempt to justify it, I'd like to note that it goes with our theme in this blog of putting up old b&w pics of movies that are notionally connected with the content of the blog).

Elizabeth-taylor-cat-on-a-hot-tin-roof-1958.jpg


 


Experiments in software teams: Camping for the geeks!

Adventure activity and software - not the best combinations those two you'd think. People in software tend to be less the "adventure sort", if I am allowed a sweeping generalization (once a month is ok!).

There is a lot of folklore about what happens between team members in the stresses of an adventure. There are countless stories of old friends fighting it out and separating because of a tough trekking trip. About people changing into very different personalities in the extremes of environment and physical strain. Gurus claim that a group only works in such stresses if the personalities match or complement each other and when there is strong pre-existing bonding between the members. Many have warned that in the dry and lifeless corporate work groups such a strong bonding is not possible and thus it is not advisable for such groups to undertake extreme activities.

We are not famous for listening to sound advice. So we wanted to test this out - as part of our philosophy of experimenting with culture to find that Nirvana of software.

 We wanted to see what really happens when a group of techies with the famous pre-existing bonding of Kaz go through physical stress of a relatively difficult adventure trip. Today's blog is about that experiment. 

The Goal

See how techies function as a group in a physically and mentally challenging adventure. And see how that experience effects their work relationship and team bonding.

The Monkeys

We wanted to test with a diverse group. So we chose a team of six who are:

  • Software Developers
  • SQA Engineers
  • Systems Engineers

The Setting

The trip was to be a 3 day camping trip in Nijhum Dwip - an island at the south of Bangladesh. 

 

The island is, very unusually for Bangladesh, nearly empty. Most of it is forested and there are a lot of deer. No dangerous animal except some dogs who moves around in packs and attacks the deer!

The camp was at the southern-most tip of the island.

There was no road transport to the campsite - the only access was with a boat from the nearest bazaar and then walk across a very muddy path. 

To reach the dwip from Dhaka the route involved a 18 hour trip via an overnight ferry (called লঞ্চ locally) and then an unknown route of reaching the southern tip (the unknowns where intentional parameters in the experiment).

The Parameters

  • The team will not be able to stay in a roofed building (they were given tents).
  • They need to stay far from any inhabited area.
  • They will have to cook all their meals while at the island.
  • They cannot research the area too much for before going to the trip - to bring in an X factor.

The Results

During the trip:

No noticeable fights erupted (sadly!), there were occasional friction between the team members which were at a magnitude higher than the usual workplace friction. We saw the effects of the professional diversity of the team in their roles during the trip. Systems, for example, took up the responsibility of arranging battery power (via solar cell panel they carried their).

After the trip:

The team came back to Dhaka with a great sense of achievement. This sense of well being has continued and has had a noticeable effect on the bonding between the team members. So none of the warning about possible long lasting effect of friction happened - quite the reverse actually.

Let me leave with some pictures of the trip!

 

 

 

 

 

Failing Better - the secret of great software careers

Samuel Beckett's words "Try again. Fail again. Fail better." are one of the best mantra in a software career. 

It may seem counter intuitive, after all doesn't "fail" equate to "crash" or something similar in software? It does, but that crash if timed right (preferably early on in the development cycle and early on in the developer's career :) ) may prove to be the best thing that happened to the software or the person who wrote it. A crash, you see, tells a developer what not to do. It gives her a chance to find a solution in a better way, it teaches her the invaluable lesson of things to avoid the next time she writes her code. The more fails she has, the more experienced she becomes and the more robust her code becomes.

The value of experience in software is not in the fact that this person spent that many years in front of a computer, it is in the fact that this person knows that many ways of not doing something. So if you are in the career of writing code for living, welcome the mistakes you make, learn from them and make sure you avoid making that mistake the next time. 

S. A. Andrée and Knut Frænkel with the crashed balloon on the pack ice, photographed by the third expedition member, Nils Strindberg. The exposed film for this photograph and others from the failed 1897 expedition was recovered in 1930.

S. A. Andrée and Knut Frænkel with the crashed balloon on the pack ice, photographed by the third expedition member, Nils Strindberg. The exposed film for this photograph and others from the failed 1897 expedition was recovered in 1930.

I was recently reminded of this when reading about an Arctic expedition that had failed a long time ago.

It was the Andrée's Arctic balloon expedition of 1897 - where three people attempted to fly to north pole on hydrogen balloon and thereby by passing all the dangers and difficulties of a trip by the seas.

In theory great, but they failed in their planning and their safety precautions. They never returned and for a long time nobody knew what happened to them. At last in 1930 their last camp and remains were found in an island. They left detailed log of what they did and many pictures. From these we know that their balloon crashed on the 3rd day of the trip and they tried to walk their way back to civilization. They may have failed, but they taught future explorers about what not to do, about survivals in the extreme cold environments and, of course, not balloon out to north pole with late nineteenth century technology! 

I'll finish with a definitive quote attributed (sometimes) to that great inventor, Thomas Edision, in the context of his failures with creating the light bulb: “I have not failed. I've just found 10,000 ways that won't work.” 

A software company and a retreat in the sands

Every year we do a trip outside the country to celebrate our anniversary.

This year we went to the white sandy beaches of Krabi, Thailand. For eight blissful days we forgot all about computers, null pointer exceptions and presentation layers! Soaking in the sun, kayaking in caves of the limestone formations that jut out in the crystal clear waters in the Andaman in that region and snorkeling over the corals. 

The value of such a retreat is huge - especially for a software company like us. The retreat relaxes and refreshes us, forming new bonds and strengthening old ones. When we come back we seem to take on our challenges with a fresh burst of energy. The stories and pictures of the retreat form conversation topics for a long time - creating relief and diversion from our daily grind.

We've been doing these trips for the past nine years, and here are some things we are mindful of to make a trip great: 

Location

A retreat has to be in a place where there is something for everyone (including family and kids). Beach resort towns are big winners (our biggest hits have been Goa, Phuket and Krabi) but other places like mountain resort towns such as Pokhara (Nepal) has also been a success. 

Activity

There needs to be a variety of activity available so that people can choose. Some of the easier ones we arrange beforehand (e.g. trip to a nearby sight) but others we leave people to decide according to their taste. So some of us do Kayaking whereas others go to a nearby museum. 

Food

This is ultra-important - especially because we are Bangladeshis (who are known to live to eat). We aim to be in a spot where there is a great variety of restaurants available. We make sure dietary restrictions such as halal meats, vegan food are covered by some of the places. 

I leave you with some of the pictures of this year's trip. 

 

Foundations for a career in programming

One thing we get asked often is how we train our junior coders. And the answer is never an easy one, since we don't have a set training program for this. But we follow some principles, which over the years have worked remarkably well in creating top professionals. Kaz developers are highly valued in the industry - a sure sign that our principles are working. Here are some of the basic principles we use for developing our younger technical staff.:

Charlie Chaplin - The Kid

Charlie Chaplin - The Kid

The master and the apprentice

Coding is a craft, and it needs to be learnt just like how any other craft in this world is learnt - through working as an apprentice to a master craftsman. Using this as the guiding principle, we put our new recruits into a team where there is a guru lead to guide them through their work. The freshers are put on real projects as soon as possible, typically starting with back-end tools working in a pair with a more senior resource - usually the lead. The pair programming model works like magic and we have noticed that within the first few weeks we can transform a not-so-sure person to a very confident coder who can contribute directly to our code. This master-apprentice approach is really a long term process and as the junior programmer works through a wide range of challenges the professional skills improve greatly.

A Swiss knife 

One of the first thing we ensure about freshers is that they are not put in a single technology for too long. The idea is to give them a taste of various technology/programming languages/domains/problem sets so that they can have a balanced view. Our fear is that if a fresher is stuck with a single thing for too long, she might try solving every problem with that single tool rather than choose the correct one (or look for a correct one that she doesn't know about). The aim is to create a Swiss knife rather than a single blade knife. We think after two years of experience in this mode, a resource can be put in a technology where she can start being an expert - by that time she has gained enough experience to know that there are other things out there.

So our freshers go from doing a .NET based auction site this month to a Javascript heavy social app the next month. They may be doing xml conversion the month after. With the wide variety of programming skills available at Kaz this is easily achieved.  

The art of disagreeing 

A major skill in a life in software is the ability to argue well. It is a skill that has to be learnt, practiced and perfected daily. We teach our freshers to be fearless in putting their views across. We teach them to overcome their worry of being wrong - which is typically the biggest block for new comers. We try breaking the ice in every way we can so that they feel comfortable in voicing their disagreements to seniors within the team.    

The loss of ego

Ego kills a great software career - it as simple as that. Ego pushes a person to make irrational decisions about technology. Egos also mean that technology meetings never come to a compromise. Since great coders come with great egos this is a huge problem in the professional software space where teams need to make decisions together and work in harmony.   

It's also one of the hardest thing to get rid of! We try breaking the ego by examples. Our senior resources make a show of displaying that they can be wrong. Saying "Oh I see your point now and I was totally wrong" is something that is pretty common in our culture - and this helps freshers a lot. In some cases individual counseling may also be given - always by someone who is respected for her technical skills.

Creating a tech addict

A life in software is also a life of constantly staying in touch with the latest developments. We take active steps to motivate our freshers to keep reading up new technology and try using those in their work. We move our new recruits into projects that uses new platforms that will challenge them and make them read and learn the new API sets or new paradigm of coding. Our culture of technical excellence also brings in the peer pressure for staying on top of new things - which soon becomes a habit, an addiction! We think this addiction is a must for a great career in software.

So those in short are our secrets for creating great developers. Are we missing anything?  

 

Planning the perfect company event

We've been arranging trips and other company events for the past nine years. And we think we are experts in this field now - at least in arranging  events for software companies.

 We do our yearly anniversary trip which is usually a 8-10 days' trip outside the country, we do a 2-3 days' trip, called the picnic for some long forgotten reason, every year. Apart from these big regular ones, we do several weekend trips to various places within Bangladesh and dozens of smaller events like the borderline insane "hudai party" (see our fb page at fb.com/kazsoftware for more pictures and stories) or more mundane stuff like release dinner parties, training workshops, various sporting events, brainstorming off-sites, etc.

We know pretty well when an event is far from perfect, and we've learnt a few things about what makes a company event approach perfection.

 While planning and finalizing the Thailand trip for this year's anniversary party (Yesssssssssss.... its going to be super cool with 8 days of fun in Ao Nang Beach Krabi) I remembered some of the things we have learnt and thought it would be good to share with my readers. So here goes:

1. Think BIG

It's best to think big. Because if you don't your plan keeps getting budget cuts and will start losing it's charm. Budget will always make things difficult for you whatever the size of company you are - but if you don't aim high the trip/event plan will never be great. So we think seriously big, I mean HUGE and then cut things down one at a time to fit with the money in hand. For example, the moment we thought we could do Thailand this year the first thing we said was that we would never do the old and tired Bangkok-Pattaya thing. It's just not us, 2 days in a crazy city and 2 days in a crowded dirty beach. We searched for the most pristine beach out in Thai coast, found the most expensive looking resort and said we wanted to stay there for 7 days (since 2 days is just too little and saying 8 days would have killed our boss). The resort seemed very happy that about 40 nerdy guys wanted to stay over there, and gave us the cost - a figure which can easily be the deposit for personal jet to fly us out there. So we googled again to find the next best one out on the beach... and the cycle went on.

2. Never underestimate the power of a group

Group travel or group booking does wonders to bring the cost down in any place. Use the group's number to bring down hotel prices, make the bus company give out free seats and make the restaurants give out extra special menus. The power of the group does amazing things to an event plan - use it and over use it. 

3. Have a high up champion 

Make sure someone from the management (or any decision making group) is a strong supporter of the event. Having a powerful champion will solve your problems of fighting the enemy within in the struggle to organize that perfect event. You'll need her support for sure. Since you are thinking big all the time - you will run out of budget, ideas that are real fun may not seem all that good for the company to powerful people, and the list goes on. Your supporter will help you sail through the red tape and make things possible. Without a champion at the right place, you will compromise at all levels and soon end up with an event that is just plain boring.

4. Involve everyone in the group

All decisions should have a feeling that it came from the group. This is vitally important to break the "us and them" feeling that creeps up in company events. The group should be consulted at every point of decision making like venue, things to do etc. This makes the group feel that they are part of the event's planning and that feeling helps them overlook a lot of issues that might otherwise sour the event and draw criticism from the participants. So run surveys, impromptu meetings or just plain group discussions on email to ask for ideas or help.

5. Have an element of surprise

Obviously company events need to be formal to a certain degree. There would be memos describing the event in as boring a way as memos describing appropriate dress code in a business meeting for the nudist resort's website :) But an element of surprise as in the sentence before (hopefully there was one) help liven up the actual event. A surprise could be as simple as ice-cream that wasn't in the menu or a little gift - but it should be done around the beginning to have the right effect.

No longer that much of surprise these days, since we do  it all the time, but we did a branded T-shirt for our trip to Goa a few years back and gave that as gift.

No longer that much of surprise these days, since we do  it all the time, but we did a branded T-shirt for our trip to Goa a few years back and gave that as gift.

6. Create hype

Hype is probably more important than the event itself. The right kind of hype when mixed with the right kind of planning can make a very low budget event a great success. A great thing for a company is that most of the hype can be done for free. Free hype could be as simple as a group emails describing how good the event would be or some aspect of it which is likely to be exciting for the group ("we will see the new VS from MS - still in secret beta!") . Posters in the hallway or even whiteboard screaming out messages can create a lot of hype. But one thing to remember is that hype should be matched somehow in the event itself - or it would be a disaster! So only hype things you know will happen. 

For example, for our Anniversary party at Thailand a series of amazing pictures of sights around Thailand does a great job at building up the excitement which makes the party much more fun.  

 

A picture of the reclining Buddha at Wat Pho in Bangkok, circulated over email or FB page does a great job an creating hype for the upcoming party.

A picture of the reclining Buddha at Wat Pho in Bangkok, circulated over email or FB page does a great job an creating hype for the upcoming party.

7. Create an icon for larger events

Iconography is something people understand. Using a theme, wording and icons help promote an event, makes it more interesting and easier to talk about. For a custom software company like us creating icons, posters and themes is relatively easier since we have our own design teams. Here is our banner for the Thailand trip this month...

 

banner.jpg

Where the wild things are

The title is a tribute to Maurice Sendak whose birthday is today.

Maurice wrote and illustrated amazing children’s books. And his famous “Where the wild things are” is a classic – if you have read it as a child (and actually even as an adult) the images of wild things and the little boy’s reactions to them leaves an indelible mark on you.

Where the wild things are is about a boy (Max) who fell asleep in his room and his dreams. He dreamt that he travelled to a land far away where the wild things are. He conquers the wild things with his look and becomes their king. But he starts missing his home and decides to come back home. When he wakes up he finds his supper waiting in his room.

So what’s the connection between a custom software company in Bangladesh and the children’s picture book? There isn’t a lot really, but I really wanted to introduce Maurice (many of my readers are based in Bangladesh and may not know him that well) and made up my own little connection.

The land of the wild things represents our fears. For a software company like us, that hires the best in the market, the biggest fear is the fear of loss. Our fear of losing our talents to other companies locally is not that great – because we are genuinely a great place to work in Bangladesh and thus represent a top choice for people to work. Thus we rarely lose our talents to other Bangladeshi companies. But those wild software companies in far off lands in the West are a different thing altogether :(

The West has a magical hold on the imagination of people living in developing countries. We tend to think of the West as the fairy tale land where every wish comes true. Our constant exposure to western media from movies to songs to news enhances that magic every day. And in the tiny world of software, is there any other monster more awe inspiring than the likes of Google or Microsoft or thousands of other fabulous software companies that we read about, hear about and watch pictures of everyday?

So where the wild things are for us is the West – those beautiful magical shores of California or fiery autumn forests in New England. And the wild things are those monster software companies that live in that land.

See that’s a good connection! And to extend the connection even more, I hope that our children will one day come back from the land of wild things again to their own little rooms in their own land where their supper waits for them.  

Side note: So how many of our talents have we lost to the wild things? Too painful to answer accurately, so let me just say “many”. We’ve lost so many to the wild things like Microsoft, Amazon or LinkedIn  that I keep seeing their logos on Maurice’s drawings every time I turn open his book to read to my sons…

 

The boy in the picture (second character with the crown) is Max who goes to where the wild things are in the story and he represents our lost talent.

Custom Carrom Board for a Custom Software Company

Our annual Kaz Carrom League is in the offing. Carrom is a game we love to concentrate our passion on during the rainy months of June and July. If you know anything about Bangladesh's rain you'd know why :)

With the carrom fever coming up we've been in search of the perfect carrom board since our old ones are dying out. But one of life's lessons was the fact that there are no perfect carrom boards out there.

Just as some problems in this world just needs a custom software, we needed a custom built carrom board.

So work is in progress for that perfect board. I list some of the spec items for this perfect board for your reference.

 

kaz-carrom-league.png

custom-carrom-board-varnish.JPG

Varnished sides with grains that contrasts well with carrom men

Did you know that the carrom disks are called men?  They are are and they deserve the proper varnished sides to settle down.


Extra wide sides

Because you need need your hands to relax while you wait for your turn.  Basic primal requirement.

custom carrom board extra wide edges

custom carrom board corners

Smooth rounded edges

There is no insult in life greater than being pronged by the sharp edge of the board when you've just missed your chance to grab the queen


custom-carrom-board-joints.JPG

Strong joints to last a lifetime

Some people say that the strength of the joints transmit to the spirit of the game. 


custom carrom board back

Extra strong back support

These boards will last a long time as will Kaz and we want to make sure posterity remembers us.  

N.B. Just in case you are new here: we are a custom software company  in Bangladesh making custom web, desktop and mobile apps for other companies and being very good at it! Check out this page to know more about our software development work culture and environment.

Offshore software development in Bangladesh

Today I will make a case for outsourcing software projects to Bangladesh.

The new offshoring destination in the block

Bangladesh is fast becoming a major player in software development outsourcing. The volume of software projects offshored here has doubled almost every year for the last couple of years. More than twenty thousand people are now working in software or IT services industry. The software industry in Bangladesh is mainly involved with exporting services like custom software development, SQA, design and graphics to European and North American markets.

Micro offshoring revolution! 

Separate to this formal sector, a huge informal sector of Bangladeshi freelancers are driving a micro-sourcing and micro offshoring revolution! Bangladesh consistently tops the freelance work location on sites like oDesk, eLance. This is really an amazing phenomenon, driven mostly by teenagers

Average cost of a 25 people software project.  Source: KPMG study

Average cost of a 25 people software project. 

Source: KPMG study

Bottomless resource pool

Bangladesh is the 8th most populous country in the world. There is a huge supply of young, trained and English speaking (English being taught from day one at our schools - a side effect of being an ex-British colony) resources. The total cost operation for a typical software offshoring operation is almost 40% lower than countries like India or Philippines. Apart from resource costs other costs like infrastructure, support and management the price advantage with competing outsourcing destinations is significant. Cost of living in India for example is fast becoming comparable with countries like Malaysia or Thailand and thus the future of outsourcing advantage to India is decreasing every year.

This is where Bangladesh outshines others - with very similar educational standards, Bangladeshi resource pool is not fully tapped and its potential to become a major software outsourcing destination is exactly like India of the 90's. A recent KPMG study is a very good read to get an idea about this. 

Maturity of the industry

Software organizations are also becoming mature and standardized. Companies like us that has been doing software development outsourcing from Bangladesh since 2004 have gained huge experience over time. The wide range of projects that we (and other companies around us) have done exposed our developers, testers and mangers to the challenges of software development process. This has created a strong base of experienced, mature and skilled resource who in turn mentors new comers in the profession. A lot of our alumnus has formed separate companies of their own to do offshored software projects, and have carried on the maturity and experience into new areas of works. This migration has also had an effect of evolution on the culture of workplace and software creativity that Kaz values.

More such companies are being setup with proper development  process and management required for outsourcing needs. The creative culture for software development of such organizations are also noteworthy.

We look forward to a great future in software outsourcing in Bangladesh.

 

N.B. Just in case you are new here: we are a custom software company  in Bangladesh making custom web, desktop and mobile apps for other companies and being very good at it! Check out this page to know more about our software development work culture and environment.

What, where, when and how of customized software

Living and breathing software sometimes I forget how the rest of the world perceives this entire space. Sometimes a question from a friend brings me back to reality and makes me think that our world is just another secret world of black magic, potion, secret recipes and spells. 

In those moments of lucidity, I can almost see why our world of custom software development can be something mysterious to people outside this world.

People understand software from the high level of course - they just have to these days. They understand Microsoft is where Word comes from. But when it comes to small shops, like ours, that do one off mobile apps or custom designed software it's hard to understand. The questions that come out are at different levels, the obvious ones are: Why is there a need for such custom software? Who in the world would want one? How would we ever make one? 

So today I will write a small article that sums up the answers from a craftsman's point of view. Note that it is really an attempt by a craftsman to explain is craft and his shop to someone outside his craft - so our techie readers may find this a bit irritating and may well jump ship now! 

 

Getafix and his cauldron of magic potion.

Getafix and his cauldron of magic potion.

What?

A customized software is a piece of software written according to the requirements of a customer. It is specific to his needs and if written right it solves just his problems.

Where?

A customized software is usually written at the software company and not at the customer's site. But sometimes the requirements are such that it makes sense to move the developers to write the software at the customer's place. 

When? 

A custom software application should only be written if there are no off-the-shelf software available that does the job. Simply because its much cheaper and much faster to get an off the shelf software. And writing a customized solution would just be waste of effort and money.  For example if you wanted to make MS Word it would probably cost you a few billion dollars (by the way does anyone know the real figure? Googling didn't help).

 

How?

 The process of writing the software can vary. It starts with some initial discussions about what is needed - the requirements. These requirements are then usually put into one or more documents called the specs. Most of the times some pictures would be drawn up to show how the software would solve the problems and meet the requirements. A half working version of the software can also be made quickly to give the customer a feel of the software. Then the work is split up in smaller parts and the software is made it phases. There is a lot of to-and-fro between the customer and software group to see if things are working or not. All throughout testers check if there bugs in the system and the developers fix those bugs. At the end the custom solution is given to the customer - the deployment.

So that is roughly a quick description of the world of custom software. Hope I've not put too many jargon in.  

N.B. Just in case you are new here: we are a custom software company  in Bangladesh making custom web, desktop and mobile apps for other companies and being very good at it! Check out this page to know more about our software development work culture and environment.

Interface between technology and business

The interface between technology and the business side of the team is always something similar to friction between plates in the theory of plate tectonics and with very similar side effects! 

If you search the Internet on this topic you are bound to come to the swing in a tree cartoon. It describes the situation very well in pictures and I give an example below. (Side note: There is surprisingly a lot of variation of these cartoons, from black and white to color with variations on the actual content too. They seem to have been around from the pre-computer age and have just been adapted to the newfangled contraption and all the problems associated with its management. This tells us once again that the management of IT projects is just a new variation on an old theme. Here is a very interesting account on the swing cartoons and their origin.)

software project swing cartoon.png

So the question is how to make the interface between technology team and business teams friction-less? And I think the answer lies in first accepting that you can't - you can only try making it better lubricated. With this first acceptance in mind, here are some of the things we as a custom software development company do to keep the interfaces lubricated well.
  

1. Let there always be a middle man

If there is a middle man in between the business and the technology teams then that middle man can translate each other's language. The classic middle man is the CTO or project managers but smaller projects we set one of the roles as the middle man role. We have seen that the putting on the middle man or interface layer hat changes the mindset of even hard-core developers and pretty much everyone can do the job but obviously the project managers tend to be better at it since they have more experience. Note one thing though, our project managers are always ex-developers so they can speak the techie language well and so it works pretty well for us. If you are one of those unlucky places where the PMs of software projects is not a techie, then this might just add to the friction, so be careful.

2. Let everyone speak a lot before anything is done

Sounds obvious right? But you'd be surprised at how many projects this is not done properly. We let every member in the team talk a lot about requirements - breaking the rules of not having prolonged meetings. We do these meetings as many times as possible at the cost of making everyone irritated and bored. We have found that this is a small cost to pay when you compare it with the benefit of a better understood set of requirements.  

3. Always do a "prototype" 

Sometimes the "prototype" is not something you'd call a prototype in a tech crowd! It could be half working quick and dirty app, or it could be just a bunch of pictures glued together in html pages some parts of which are clickable. But whatever it is, it helps clarify a lot of issues and makes the business teams see how things will look like or may work. It gives them the chance to scream or modify their expectation or modify their plans.  

4. Have regular meetings to show case the product in its current state

We call these internal product demos. Ideally they should be done with the project manager showing it to the business people as potential customers! The whole tech team should be there, to see the reaction and hear the feedback. It gives directions and food for thought about what is being built for the whole team - business and tech alike. 

5. Let business team see the product at any time

This is the classic Agile recommendation that the stakeholders should be able to see the current state of the product at any time without going through any red tape. This is actually very easy these days with build systems and automated deployments frameworks in place. The whole thing should be automated, so that at the click of a button the business guys can run the app and check things out.  

 

N.B. Just in case you are new here: we are a custom software company  in Bangladesh making custom web, desktop and mobile apps for other companies and being very good at it! Check out this page to know more about our software development work culture and environment.

Workspace design for a software company

We are fanatical about our culture, we think as a custom software company this is our biggest strength that we can offer to our clients. A good workplace culture brings in great software, the equation is that simple. And the first thing in creating a good workplace culture is create a setting for it - creating the right physical environment that signals the values that we care about. Workspace design is key to a great software company. It is just as easily as important as the software development IDEs and tools. And this is not something new and specific to this space, a craftsman's workplace has always been important, his craft is enhance by the right choice of environment, the right arrangement of things. 

We realized this importance right from the beginning, and the first chance we got to setup our environment was in 2005 when we moved from our makeshift offices to a place that we could mold to our needs. We decided to call that place the Nirvana - because that was exactly what we wanted to make our place. 

We laid down our goals about workplace as follows and those goals have never changed for us, they define all decisions we take about modifying our environment.

  • Workplace has to feel like home.
  • Workplace has to be somewhere you can relax.
  • Workplace has to be fun. 
  • Workplace has to have places where you can always find a quiet place to sit and think. 

We read up all there was to read (or rather all that Google knew about). At the end two resources helped us a lot in our quest for the perfect workplace for software development. 

The first and by far the most important one (over the years) is the amazing book The Pattern Language by Christopher Alexander - which is a list of patterns that make great places of comfort. This obviously appealed to us as software engineers - great fans of design patterns in software design (there is actually a direct link between the two - with the pattern language book influencing the need for design patterns. Here is a link where Prof. Alexandar made a keynote speech at ACM conference on OOP that tells the story from his side.). This book gave us almost step by step instruction of what to do.

The next resource that was a great help was our guru's blog at joelonsoftware.com a lot of his writing guided us, but the must read was the bionic office, read also his updated one (when they moved to their new place). Joel is very opinionated. And that helps, he puts is logic in strong terms and you tend agree or disagree with him pretty early on. A lot of his stuff we followed blindly but a lot we did not and some we initially did but over time realized that there are better ways of doing things and changed.

What we started in 2005 has been an on going thing for us. Because no design is perfect, as we tried out various ideas some worked like magic but some needed subtle changes. Over the years, we have grown much larger in size and got hold of more space next to the original Nirvana. We adapted our workspace design ideas to fit with what we got from feedback from our people. And today at the middle of 2013 we have a set of rules for setting up things which are slightly different from our original and we know for sure it will change over time too. 

I describe below what we have now - our workspace design plans, office layouts and placement of different objects within our working environment. I will do most of it in pictures with little notes to go over the rationales or things we have learnt that are important about the elements in the layout. 

 

The work desk

  • We feel strongly about the pattern that there should be a wall at the back and that you cannot be approached only from the front. This creates a feeling of safety and it is one thing we never compromise on.
  • We place the seats so that you are looking out to the room at other people working on the same project as you are (another pattern). 
  • We are against Joel's single developer working alone in room model and also against Googleplex like or Agile war room like setup. But if a team wants to adopt a war room setup for limited time that is ok too. 
  • Desk space is vital for a proper mess. And a proper mess is vital for some developers, SQA engineers and designers! 
  • Pair programming needs elbow space! 
desk.png

Transition Spaces

  • Transition spaces like corridors are vitally important for a software company. They are where most solutions are found and most designs are finalized. So they need big whiteboards with markers.
  • The zen view pattern says points of beauty should be in transition spaces so that it leaves a good memory when you go to your ultimate destination. We agree and try putting in all sorts of points of interest like artwork, aquariums, etc.  
  • Not in the pic below, but transition spaces need to be dark with splashes of light (another pattern) - this helps the traveler feel they have reached home when they reach their room which are typically brightly lit. (Bit off the rocker statement I agree but we seriously believe this).
corridor.png

Meeting Spaces

  • We make the meeting spaces cozy so that people feel comfortable being there.
  • We make sure there are no unnatural obstructions like tables in between people. 
  • We put strong colors in one or more walls - this is gives a jolt to the group when them first go into the room. A jolt sometimes helps people think out of the box. Strong colors also make people confident and help them take bold decisions. 
meetingroom.png

Eating Together

  • We eat together because that feels like a family.
  • We make the room where we eat feel like a dining room at home, with pictures of our kids, little decorations we've picked up from our trips around the world, etc. 
  • We make the center of the table well lit and the sides a bit darker to heighten the feeling of grouping. 
eating.png

A Place to Contemplate or to Meet 

  • A place with a view; so that you can sit, relax your eyes a bit and think about things.
  • Some comfy chairs ideally cane to make it feel more like a garden patio.
  • A point of interest - like a big earthen bowl with water and aquatic plants in them, etc. 
ip.png

N.B. Just in case you are new here: we are a custom software company  in Bangladesh making custom web, desktop and mobile apps for other companies and being very good at it! Check out this page to know more about our software development work culture and environment.