Experiment and evolve - the best way to improve software company culture

A Short History of Nearly Everything

By Bill Bryson

Experimentation in nature - Burgess Fossils

I am reading Bill Bryson’s (one of my all time favorite author) A short history of nearly everything and came across the discovery of Burgess Shale Fossils. These are fossils (literally thousands of them) that had been discovered in 1909 and scientists have been finding, categorizing and theorizing about them ever since. Even as late as 2015 a whole new set of fossils were found. These fossils are important not because of the sheer number (although that’s always welcome) but because of the extraordinarily preserved state of soft bodied organisms and the extremely wide variety of them found together. They show amazing body shapes and structures that seem to have been completely lost in later ages.

Burgess Shale Fossils

The great biologist from Harvard Stephen Jay Gould wrote an amazing book Wonderful Life in 1989, and made Burgess Shale fossils famous. He suggested in that book that the diversity of the fossils indicates that many of the unique body types were just evolutionary experiments that became extinct because those “models” failed. If you look at the completely out of this world weird nature of the shape and structure of the life forms in the Burgess finds, you’ll probably agree too. If we try to fit it with a modern day design success: it’s as if, instead of hiring the legendary designer John Ive , Steve Jobs just asked his engineers to come up with randomly designed iPhones in millions of different shapes and waited for the best one to come out from that.

Wonderful Life: The Burgess Shale and the Nature of History

By Stephen Jay Gould

Experimentation in the organization

Reading this made me think how an organization’s culture has strong similarities with this idea of random experimentation and evolution. There is almost no sure shot way of making an organizatiio’s culture be good. There are obviously a lot of commons sense ideas and historical facts about what works and what doesn’t. But exactly what steps, behavior, formal and informal rules and policies will work for a particular team in a particular context and in a particular industry is very much a chance thing. In the software space, culture is extremely important. So this is as important a concern as say skills of the team. Yet without any strong process and guidance most companies just seem to gamble away at the culture issue. A lot of the times it’s just how that company picked up the first set of hires or how its CEO thought the world should be. But always pretty random and the success very much given to chance.

I think one huge thing that most companies miss out is the possibility of experimentation. Think through and try out controlled experiments on culture change. See what the results are. Discard if that particular change is bad and keep if it has hope. Just like the Burgess fossils keep changing the models and let the effects decide what stays and what doesn’t. I see most companies staying rigid on culture - “this is how we are”, “this is how it’s always done” etc. I know that for the management, however progressive they are, not having a tried and tested best practice means it’s hard to decide, so they just decide on something and stick with it. Yet I think for fluid and intangible thing like culture staying rigid is the worst thing possible. If the experimentation is allowed, even better if it’s planned and executed there is much higher chance of reaching a better point where culture fits the team and company’s goals the best.

Just as the Burgess fossils must’ve been weird (and wonderful) life that led to much better and yet more sophisticated life forms - experimentation or more importantly allowance for experimentation will lead much better forms of culture at your company. And that’s of vital importance for any software company.

Why software startups fail?

Did you know that most software startups fail?

Yet majority of the startups that fail actually have great business ideas. Take the failed startup Kettlebell Kitchen for example (shut down Nov 2019 after 11 years of trying). If you think about their idea it sounds fantastic - people want to eat well or use a particular diet -> It’s hard to maintain it yourself -> use the software to receive meal kits based on nutritionist’s advice and stay on the program. Takes on the restaurant/food business as well as the health and fitness industry in one single idea.

Yet with more than 30 Million in funding, 11 years of coding (and I’m guessing struggle) we have a company that has always lost money and is now dead. The end result is an email to its customers:

But why do software startups like Kettlebell fail?

That is a fair question. And after helping startups for the past 16 years we have some idea about what works and what doesn’t. Let me try answering that question today.

But before I do I’d like to share an amazing study done on 339 failed startups (and counting). There is so much to learn from these stories and after finding this I ask all my new startup customers to read through them. In entrepreneurship failure is the key to making it big, you fail, you learn a way of not doing something and you move to the next things slightly better at what you do. And what better way than to have a list of why and how others failed - it’s almost like a shortcut through the fail -> learn -> success route (although I think there’s no shortcut in that game :( ).

Source: Top 20 reasons startups fail

OK, back to my original question about why software startups fail and also how we can address that reason. I’d like to use another great article from the same data set where the researchers have tried to go through the stories and pin down the reasons and create a graph of the reasons. I share that on the side to give ourselves a reference based on data. I list our own list of reasons from our experience below, some of which map pretty well with the graphic and some don’t that much. But it’ll give you food for thought.

Forgetting the main goal of a software

Every successful software platform solves a particular pain point. Even Facebook solves a problem (creates others on the way though :) ) of staying in touch with people busy in their daily life. The success of the startup depends on how well the pain point is solved. Many startup founders lose their way during the build out process of a startup and start trying to solve too many things at once or sometimes imaginary pain points that has no use. Having a clear goal about the pain point that the software will solve is essential for startup success. This maps very much to the #1 item in the list above “no market need” - since not solving the pain point leads to exactly that.

Spending too much too early

No one has the crystal ball to tell the future and no startup founder knows what will work and what will not. You have to start with a hunch or a niche and then figure out how much of your initial idea actually was useful. So spending most of your budget on the initial idea, without leaving enough for the changes that need to be made for sure down the line means that the startup never gets the chance to meet the need in the market and dies. Again this maps well with the #2 in the data - “ran out cash”.

Obviously if you plan well you can make your money go a long way and get more out of it and thus get more done all the way through. Being smart with money is the most essential skill in startup leadership. KettleKitchen in my example above died after burning through 30 million in investment and millions in revenue it was earning itself. The fact that it survived for 11 years mean it had something going for it, lack of money management is what killed it.

No wonder a lot of smart startups use software teams like ours to keep their cost in control. They can dial up or dial down the cost as needed as they try things out in the market place. And using a company like ours which offers great rates because of the fact that we are in a low cost country makes a big difference. One of our all time best service product is the “Launch under 10K” we offer to startups.

Getting a software team that’s not a good fit

This is a big one. At the end of the day, whatever idea you have, however much focused you are about your goals if you don’t have a great software team that fits with your work culture and your way of doing things your startup will always fail. So if you are hiring, spend a lot of energy in the hiring process, since you’ll be stuck with this team forever and you make and break based on this team. If you are getting an outside company like us to make the software for your, spend time to find out if the outside team is a good fit for you and your product (and not just the price they are offering). Check out our great little post about this topic: How to select a software vendor?

This is #3 in the list based out of the stories above.

Not having a price for everyone

Every restaurant you go to you’ll see that they have a range of prices. Why? Because they don’t want to turn customers away just because it’s too pricey (or too cheap!). Same for software products, not having a range of options to fit different software budgets is a common mistake. Remember you can always upsell but getting the user to try your product and get to know it is a big deal for an unknown new startup. So have a range of packages, and always, always have a way that the user can try it for free - maybe a free 14 day trial, maybe a free basic edition. That’s essential to remove the barrier of “I don’t want to spend without know if this is what I need”.

Waiting too long to get the “perfect” first product

This is the other big one, especially for first time entrepreneurs. They just won’t release something that’s not perfect. Perfection here is what they have in their mind - an unattainable beast formed out of a hundred other software that the founder has seen, a mixture of Steve Jobs and Bill Gates videos about how software should be and sometime even a book on design. Waiting too long to release your product is sure way for death in this fast paced, fickle reality of the Internet, short attention span and crowded app producers. You just can’t wait, and not only because you want to get things out before your competitors do (or before your marketing message is lost) but also because you need to experiment and find out what you need to change, what you’ve got wrong. Release early, get feedback early, release often.

Not giving enough thought about your UX

With the wide choice out there for users sometime it takes a single bad interface element to put your customers off your product. If startups focus only on the engineering or the features and think of UX as an afterthought thinking that the utility of the software is enough to make it big they are making a big mistake. No software is that important or essential anymore in this world. Sometimes you’ll find great startup success stories that just had very little features at the beginning but good user interface to attract and retain people as they put the features in gradually. I remember using Hubspot when it first came out and thinking it has nothing but look at it now as a business. User UX and that includes the onboarding makes for a successful software startup. Read our UX cheatsheet for startup founders.

Jumping in too early

“Unfortunately, the VR market never developed as quickly as we all had hoped, and we were definitely ahead of our time. As a result, Vreal is shutting down operations and our wonderful team members are moving on to other opportunities.”

— Founder, Vreal

With all the hype about the “first movers advantage” many startups feel that it’s never too early to start something new. Yet from our experience you can always start too early, it’s actually hard to be too late! When you are too early on a technology you might have spent up all your budget before you see any revenue, or adopt users or even get any media interest. Take this quote from the founder of a VR startup that failed, Vreal

It’s much harder to fail because you came in too late. Coming in late means the technology and the mass users have ready to accept your product. It’s easier to find what others have made mistakes on and get your product to be launched without those mistakes. It’s easier to market too. Sounds weird, but it’s true. This is why Facebook wasn’t the first social media mover, it’s why Lyft and others still make it with a fight with the uber elephant in this space.

OK, I’ll finish today or this will start getting boring. I’ve put in my top ones above. There are other smaller ones, but if you can fix the ones above you are on the way to success. Starting up a new software business is the most exhilarating and fun thing in the world. Do it! I wish you all the best!

How soon to start coding?

Today’s post will be slightly different from my usual them of “life and times of a product manager”. And it was inspired by my daughter.

The picture above is of my daughter when she was about 2 years old. She started drawing on the walls of our house with her crayon set. Her artwork was absolutely gibberish to us, but she explained that there was a car and a baby shark in her masterpiece. We understood that she has own creative thoughts and her own language and appreciated her uses of different colors.

In the digital age, whenever we hear the “Codes”, we understand the computer languages that we use on a daily basis but don’t mostly understand, such as C, C++, Java, PHP, Swift, and many more. Whenever we hear the phrase “Coding”, we imagine a person sitting on a chair and writing gibberish on a computer screen comes to mind, with years of practices and a college degree.

Similar to a programmer’s code will look absolutely gibberish to you once you see the code below. Fun fact it is a part of the backend of Google search. 

Interestingly, coding is not just about learning a computer programming language and how to write lines of codes. There are so many advantages of coding that support the development amongst growing children.

“I taught myself how to program computers when I was a kid, bought my first computer when I was 10, and sold my first commercial program when I was 12”

— Elon Musk

Advantages of teaching coding to children

Creativity and logic building

Learning to code allows the coders to be creative. Coding also helps to apply different logics to solve a single problem. Learning to code at an early age allows our growing children to be more creative and this can benefit them to apply their creativity to solve an issue. 

Makes a team player

Students get the opportunity of building projects as teams. They have to communicate with each other and this can also help them to get involved in project management in an early age. Project management can help with communication, compromise, discussion and negotiation between the players.

Influence to learn more

Allowing your children to solve an issue their way influences them to learn new ways, and logic. In a way solving one issue gives them more opportunity to learn new things. This also allows children to learn patient and observant.

The ability to understand and share

It highly in children, when they learn about something, they share with you and other. This improves their communication skills and develops them to understand different situation. Sharing also allows them to improve their presentation skills.

Boosting confidence

Once they get to solve an issue, their confidence is boosted to try another issue solving. This way you an introduce to learning materials for them to look into.

How to teach your child coding

It not going to work if you give your 2 years old a book on Java programming for Dummies. But there are a lot of materials in your time that can help them to learn more about coding.

Using Toys

I tried something like this on my daughter when she was just old enough to stand up herself.

A very simple toy to start learning about logics. It took her a long time to get it right but she did. After this we tried the ones with the Alphabets and this allowed her to learn to put the shapes in their rightful holes faster but in the process, she also picked up the English alphabets as well.

Now that she just turned 3, I came across this toy called “Code-a-Pillar”. This toy allows kids from 3-6 years of age to learn about directional logics, solving obstructions in the path.

But with toys, you can allow your kids to learn about coding and other materials faster and they have fun in the process.

There are so many toys available that can help your kids to learn coding at a very early age. The next device I am interested in looking in to is called Cozmo, a robot that listens to you and builds structures with blocks. Face it, I am more interested in it than my daughter. The point is there are so many toys that will allow your kids to learn more than just pushing a car or just dressing up a doll. I read this article and this helped me decide the type of toys that I must introduce my kid. Please give it a read.

https://www.gearhungry.com/coding-toys-for-kids/

Programming languages

I have seen my cousin influence his 5 years old learn programming in a fun way. He used Scratch, a programming language designed by the great minds from MIT specific for kids. Using scratch, I have seen my nephew design a game. And he used logics very creatively that we have to brainstorm for days, at this age.

Arduino, the world’s leading open-source hardware and software ecosystem, is also involved in creating kids smarter and more involved in coding. They have projects those which they have designed for kids to enjoy and learn with, please give this a read as well, Arduino Kids.

There are so many resources out there, like Python, Blockly, JavaScript, Lua (Roblox) and more programming languages out there those which are tailor designed to get the attention of children. Give this article a read, Top 9 Kids Coding Languages of 2020

Code your own robot

“There is a part of a humanity that loves to worry about robots taking over or being weaponized or something like that. We definitely want to counter that narrative. We’re not interested in weaponized robots. ”

— Marc Raibert , ex-CEO BostonDynamics

You may not have to wait that long to start programming those amazing robots you saw from Boston Dynamics! One of their top models, SPOT is now available for sale (there’s even a contact sales button the page :)) with its open source SDK

So those scifi movies that we’ve been consuming all our lives are starting to be not so scifi anymore! We’ve not played with the SDK yet, but would love to if we can ever get our hands on one those dog-robots, but here’s a quick summary of what we know from our reading up. Could be wrong on some and definitely things are moving fast here so keep an eye on their site for news if you are as excited about this as us (and you should be).

The SDK

The SDK is in Python!

The SDK let’s developers and hobbyists to interface with the robot and develop custom applications that lets Spot to do tasks. Developers who doesn’t have the actual robots can still be able to view the SDK and existing early adopters can open source their applications that can then be built upon by the community. With the SDK, developers can create custom API for controlling the robot, io on sensor information and feed into into data analysis tools/AI, and design custom payloads to expand the capabilities.

Googling around gives one example of a company already using the SDK to do something - HoloBuilder is using the SDK to integrate Spot into their existing app - that lets workers use a phone to teach Spot a path around a construction site and then Spot will navigate that path and take 360 images.

Robots can be rented!

Great, we have the SDK, but how do we get the robot? The good news is that if you manage to become a member of their Early Adopter program (there must be a million contenders for it already :( ) then you could actually get “leased” robot from them. Here’s them saying it in their own word: “Developers will still need to become part of the Early Adopter Program to lease the robot to execute their code…”.

SPOT is loaded

Spot comes with a lot of features - VR control, automated registration of laser-scanning, connecting Spot’s data to cloud work order services, using Edge computing to help Spot semantically understand its environment, and much more.

The first user conference

In addition to open-sourcing announcing their SDK release BostonDynamics also said they are arranging the first-ever user conference for their platform, Actuate 2020. Set to take place May 12-13 in Boston, Massachusetts. Sadly it will be invite only. But that’s expected. But May is only a few months away.

Exciting times!

An easy way to inject energy in your team

A recent HBR article discussed how having a “Shadow Board” of younger employee empowers and energizes a company. I think this is a brilliant idea, the act of bringing younger staff into limelight and positions of power amplifies their voice and views, engages them in the companies initiatives and injects a huge amount of energy into the company’s every day actions. As the article shows in real life how this injection of energy makes a big difference, the fashion giant Gucci started a shadow board from 2015 composed mainly of Millennials. “The shadow board includes people drawn from different functions”, CEO Mario Bizzarri says “with the most talented people in the organization — many of them very young.” and their feedback has “served as a wakeup call for the executives”. Gucci’s sales have increased by 136% between 2014-2018 during the time this board had been active.

This idea of a shadow board and the idea of empowering the younger members of a team and giving them a role in injecting ideas and direction of the company may be new to large corporations but for many smaller software companies this is pretty much a tried and tested method of making the team dynamic. At Kaz we have been practicing this right from the start. Every new group of “freshers” (or “freshly hatched” as they are called by senior team members as a friendly jest) have had a chance to be part of some important decision making over the years. We have benefited a lot by this injection energy and idea. I want to share how we do this and hope this might give you some ideas to try out at your company.

Making a young “alt tech lead”

As with any software company, Kaz runs with small groups (ideally below 7) or teams developers led by a tech lead. What we encourage actively is for the younger (usually the youngest) members to become a kind of alternative tech lead. An open culture where their is no walls between individual team members obviously help with this. The “alt tech lead” then has a voice and feels like she can point out errors and come up with new ideas much better than the senior members of the team. This alternative voice is excellent in breaking down bias in software design that sometimes creeps in because of the past experience of senior members who tend to drive the same ideas and technology on every new project. Giving the younger members the role of this alt tech lead also encourages her to pick up skills and knowledge that she has to use to defend her ideas. A perfect win win situation, particularly in the fast moving software development world where everything changes in a matter of a few years and keeping up on new technology is a must for every team.

Giving younger members leadership on events

We usually make younger members of the company manager for various events that happen at Kaz. These events can range from tech workshops to multi day trip outside the country. This leadership helps younger members in meeting other staff outside their immediate team and also for developers this is very good opportunity to learn management and collaboration skills for working with non-tech members. This is essential for a software developer since at some time of their career they will have to interact more and more with the customer and other stakeholders of the software project.

Giving junior staff a forum to voice their ideas

This comes in many flavors. At its simplest it’s actually a software forum or group where everyone has a right to say what they feel. We call this the underground - almost like separate power center where the management doesn’t have full control. This is superb to hear new ideas, or more importantly criticisms and gripes about management policy, practices etc. This is an invaluable source of information and acts as pulse to check how things are going and what needs to change.

The ideas and energies of the younger staff members is an amazing source of dynamism for any company. Particularly in software companies the young comes with new ideas and skills about technology that the older staff members just don’t have. Not to harness this power is a big loss, yet I feel it is not utilized as much as it should be. Remember the lines “Eternal sunshine of the spotless mind!”

8 top tips to save your team from burning out

Teams burning out because of a too much work load is a common story in the software industry. Yet if you take some easy measures you can easily avoid this without reducing your team’s productivity (actually increase it sometimes). Here are our top 8 tips that has worked for us and our customers over and over:

1. Manage the workload (obviously)

When the work to do fits with capacity, the team can effectively get their work done and still have time to rest and recover. Remember that a team’s time is not just about the task list, it is split between work in hand, coordinate and communicate, their need to take breaks, their need for professional growth and development among others. So your balancing act between the business’s need to get things done with a deadline and the team’s ability to take on workload has to be much more than a spreadsheet or a fancy project planning device. Apply your EQ and your IQ to find that balance.

When you fear your team’s burnout remember you can always say no - read this superb article on HBR to sharpen your skills of saying no - 9 was to say no busywork and unrealistic deadlines.

2. Let your team have work-life balance

We sometimes burnout when we focus only on work. You as the leader drive that focus. If the life of a coder is to sleep only a few hours and be back at work, with barely any engagement with rest of life that coder will only go down the path of burning out. Even if you are doing for selfish reasons of making the project successful so that you look good you will fail badly - your team will lose their productivity as they go along the path of burning out. Work life balance is the key to team’s ability to take on stress yet stay productive. Keep an eye on the team, even if there is no huge workload, if the sole thing they focus on is work. If they do, talk to them, make them understand that you are OK if they take a break and do something with their family or go play a play a ball game, etc.

3. Take care of life’s little tasks

Little things like filling out form, buying a plane ticket, doing the laundry all take up time of your staff. Without doing them life becomes stressful. If there is any way you can take care of some of them, it does wonders in freeing up your team’s time, reducing their stress. Sometimes this “taking care” is very low cost compared to the high cost of the developer having a “downtime” from getting these done to getting stress about not finishing them. Google offers laundry service, FB has bike repairs , maybe you can’t afford things like giants but you can do something else that makes slightly easier for your team.

4. Make vacations a must

Vacations are essential for software developers. It’s as important as taking a training on a new technology or finishing off the tasks at hand. Vacation recharges them, makes them look forward to coming back to work, helps them think about problems in a new way. Without this regular recharge, refresh and rethink a software team loses it’s edge and individual team members slowly burns out losing enthusiasm and productivity on the way. Vacations should be made mandatory by policy.

5. Set realistic deadlines

Some companies use the mantra like "think big" and set unrealistic deadlines for developers. This may sound great in theory (or in a youtube video about getting rich) but it is a guaranteed way to burn out your team in the long run. Software development is a creative process at the end and you can’t use these artificial work more motivational strategies to get more juice out of the system. It may work one time or two but ultimately it will fail.

The only sane and long term strategy is to set realistic, achievable goals and deadlines for the project.

6. Recognize contribution

Recognizing a teams contribution and achievements go a long way towards the satisfaction and self-worth that a hard working team needs for it’s health. Recognition is simple and honest way of rewarding hard work. And it helps the team come out feeling better about themselves and take them out of the frustrations of working too hard for nothing.

I’ve found many startup founders have an idea that if they recognize the team’s performance their team will become slack, instead putting stress on them, pushing them and reminding them that they failed or might fail gets them to work harder. This is one the biggest mistake that a founder can make. The constant stress and feeling of failure destroys morale and reduces productivity and eventually lead to a burnt out team.

7. Encourage physical activity

Plan on giving enough time with the work day for some kind of physical activity. Even a little time to go for a walk or play a game of foosball is a great help. A break from the computer screen helps refresh the developer's head and allow them to see new solutions. It also helps her stay fit and healthy which eventually leads to a much energized team. And biggest of all it helps avoid burn out.

At Kaz we are big fans of cricket, no work day is complete without our daily cricket match. In winter cricket sometimes is replaced by badminton or something similar.

8. Bring variety in work

You should aim to have mundane or easy project priority tasks mixed with challenging, creative work. This mix helps the developer stay interested in her work. Interest is everything the creative space, if a developer becomes bored with the tasks in hand it will lead to burn out. Doing the same task over and over destroys motivation. Yet, if you mix it with a different set of tasks you’ll see your team producing more yet becoming less burnt out. Paradoxical but very true.

Multi-tasking is a crime (at least in software projects!)

Fact of life: More often than not a software team will have more work than they can juggle. What can a team lead do to get things done in the most efficient way?

Coming from a logical point of view she has the following algorithm:

1. Prioritize things and get the high priority things done first (of course! We have a no brainer here).

2. Given the prioritized list of task from #1 she can get her team members to

   a) do one feature at a time

   or

   b) ask them to multi-task as in work on several features at the same time, switching between them.

The real debate is:

Is multi-tasking better than single tasking?

Multi tasking has been hailed as great solution to modern life’s challenges. Books, articles and research papers have been written showing it’s benefits for efficiency and performance. A little googling will lead you to articles such as this one aimed a entrepreneurs: Why multitasking has become the need of the hour? As you go through these you realize that it may indeed be a good thing and may solve your every day challenge of get different features of a software made (because you need to show different stakeholders different parts) in parallel.

However, in the world of software development there is a strong indication that multi-tasking is harmful. Let me quickly define multi tasking in this context - it is the act of getting the same resource (or a group of resources say a small team) to work on one part of the software and then move to another part within short intervals (hours, days but maybe not weeks). The effect of this kind of multi tasking is context switching - getting the developer(s) to load up one set of code, logic and idea in her brain and then after a while asking her to forget that and load up a completely different set. There is absolutely no question about this, context switching is bad for a software team’s performance.

Source: The Multitasking myth

In the book Quality Software Management: Systems Thinking, Gerald Weinberg writes how context switching affects performance. He showed that just like computers, humans often incur overhead when context switching between multiple parts of code or between multiple projects. He came up with a rule of thumb to calculate the overhead and showed that you lose 20% of your time by just adding one extra new context due to the overhead. And By the time you add a third project, nearly half your time is wasted in task switching.

If you think about it its quite obvious. When you are managing a software team, task switches take a long time. That’s because coding is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at coder. A programmer coding at full speed has in her head a huge amount of random yet useful bits of information that range from variable names, database tables where the variable will go, APIs that she will need to call next, the names of functions the team wrote in the library, the URL of the git directory, a stackoverflow article she read that uses a trick to solve the problem, the list goes on and on. The moment that programmer moves to a different task or worse a different project everything is lost and a complete new set has to take over - incurring that wasted time in the scheme of things.

So multi tasking makes a software team slow rather than fast. Your deliveries come later than sooner. So just like we can say with absolute certainty that cubicles are bad in a software company, we can say without a shadow of doubt that multi tasking is a crime in a software project. Here’s a good Dilbert for today…

When your developers don't speak to you

What do you do when your developers don’t speak to you?

Not that unusual situation in the world of software development. Software developers in general have managed to earn a reputation for being difficult people to lead. A cursory glance at Amazon for software team management book will get you dozens of books dedicated to this subject (with the veiled theme of managing difficult people), including books with titles like “Herding Cats”! If there is a market for that many books then there must definitely be a need.

It’s obviously wrong to generalize and say software engineers are unsocial and don’t usually fit well with non techie rest of the world. That just isn’t true, spending all of my working life of more than 20 years being a developer, then hiring, managing and leading them I know that for sure. However, its also true that more often than not you’ll find it difficult to be friends with techies if you are not one yourself. Yet in an industry like software development, where communications and teamwork is essential to get products out properly, it’s important to have good relationship with team members. So how do you solve this problem? How do you make sure that your software team maintains good relationship with you (you = pretty much any role from an owner to a lead)?

Here are some tips from our experience that will lead to happy software teams and a team that trusts your leadership:

1. Shelter developers from “business stuff”

“With a software company, the first priority of management needs to be creating that abstraction for the programmers.

If a programmer somewhere is worrying about a broken chair, or waiting on hold with Dell to order a new computer, the abstraction has sprung a leak.”

— Joel Spolsky

OK “business stuff” is a horrible choice of words. What I mean by it is anything that a software company needs to run as a real business in this world. This includes things like sales, marketing, office management, making sure there that the air conditioning is running, even seemingly tech stuff like installing an antivirus or installing a hard drive. The idea is that development is a creative and high focus activity. Making developers do tasks that takes them away from this activity means you are making them lose their focus, it means you are making them do things that they are not good at. So although putting a developer on a sales call with a high profile customer might sound great because she can answer any tech question that can come up, you are actually wasting everyone’s time and making a dent on the developers ability to be effective probably for the whole day. Just as you’d shelter your accountant from debugging the latest issue in the code, shelter your coders from stuff that will only waste their time. You’ll be a star, you’ll make a huge impact on the quality of the code and find that the deliveries are happening on time. Joel call this sheltering the “the development abstraction layer”.

2. Trust your developers

Software development is really a craft. There is always an element of chance, an element of uncertainty in it. Which means there are times your team will be great, make you proud, produce the right piece of software at the right time and sometime they’ll make a total and utter mess. If you give them a feeling of trust - where you basically saying that you trust them to do their best, they in return will do their best. This is common in all team activity - sports for example. Trust empowers a team, makes them comfortable with you as their leader and makes the relationship with you simpler. DeMarco and Lister called it the “Open Kimono” (in their must read book: Peopleware) in a time when that phrase wouldn’t make you cringe. OK, cringe but follow their principle because this trust leads to better relationship and better teamwork.

Page 162, PeopleWare

3. Know that screen time is not equal to software

There is no relationship with the amount of time a developer spends in front of a computer screen with the quality and quantity of code she writes. She will write code that gets the a feature done sometimes in hours and sometimes in minutes - here’s the twist: for the same feature. Many things come into place that determines how much time is actually spent on writing a single piece of functionality. Sometimes it’s fast simply because a library was ready to go, sometimes it’s takes hours because a silly network issue made the IDE freeze, or sometimes it’s fast because a recent blog post by a favorite coder suggested a new algorithm. It’s impossible to predict. Yes definitely there is a tendency of some developers to be much better at coding than others, but that’s a hiring thing, the moment you chose to hire someone your are stuck with that person’s abilities and the inherent uncertainty of the software world. So if you see your coder “wasting” time in the lunch room when a super important bug is waiting to be fixed don’t go on hyper crazy mode - maybe she is just getting her brain to work things out in the background. Never use the quantity of time a developer spends in front of the screen (or even worse stays late for work) as a marker for performance for a developer. Getting out of that mindset will enable you to have a level headed conversation with your team and lead to a much better relationship with the team.

4. Break the ice

This is a big one if you are a non techie. There is an inherent “us and them” in the tech vs. non tech world. This leads to all sorts of weirdness and assumptions. A common misconception of a software team about their non tech manager (or worse old tech manager otherwise known as dinosaurs) is that they just would not understand how things are done. This often leads to a situation where the team is not communicating essential information (e.g. “there is no way in the world we can get that shipped by end of the month”) to you. This happens mainly because the team thinks you are just too different. The only way out for you here is to break the ice somehow. Go to a fun party with the team, make fun of yourself, admit you are indeed a dinosaur, whatever it takes to bring the wall down and make your team think they can talk with you.

5. Defend your team

“...the true price of leadership is the willingness to place the needs of others above your own. Great leaders truly care about those they are privileged to lead and understand that the true cost of the leadership privilege comes at the expense of self-interest.”

— Simon Sinek, Leaders Eat Last: Why Some Teams Pull Together and Others Don't

This is the ultimate one, if you just do one thing then do this. Let your team know that you have their back. You’ll defend them if things go wrong, if the boss screams he will be screaming at you and you’ll take the blame, if you lose the customer you’ll take the pain and not start venting your anger on the team. A good read along these lines is Simon Sinek’s Leader eat last.

The creation of software has so much uncertainty, so many moving parts and so many things that can go wrong that the team will always feel unsure of itself. Having a leader that understands this inherent risk of failure and acts as shield that lets them take that risk without worrying about the failure too much means a world of difference in the performance and morale of a team. And the team will forever be grateful for a leader like that.

OK, I’m off for today. Here’s the stolen Dilbert that does a good job on today’s topic! Good luck with your software team!

Web development in Bangladesh

The software industry in Bangladesh is making huge leaps in recent years. BASIS the lead association for software companies Bangladesh showed that the export earnings was over $600 million in 2017-18 and was approaching $1 billion in financial year of 2018-19 with a CAGR of 39.54 percent. It is expected to grow to $4.6- 4.8 billion by 2025. A significant portion of this export industry is in custom software development in for online services. Apart from the export market the domestic market for web application and thereby web development has been accelerating very fast. This is evident in the growing number of online services that are now coming to the market such as e-commerce sites, social networking sites and forums, business services etc. The corporate sector has also focused mainly on intranet based web solutions served by internal web servers or firewalled clouds. Overall this huge push towards web application has obviously led to a large pool of web developers and designers making Bangladesh an ideal destination for custom web development.

Strength of numbers

Source: Where Are Online Workers Located? The International Division Of Digital Gig Work

In a research piece done by Oxford Internet Institute Bangladesh came out only second to India in availability and scale of freelancers for software development (and also for cumulative skills). And majority of this large skill set is for web development work.

We could not find a similar study on the skills distribution on the current professional software developers in Bangladesh but even from informal discussions, marketing materials of BASIS members it can easily be assumed to be the main skill set they are offering. So it can safely be suggested that the cumulative total for freelancers and professionals for web development skills sets Bangladesh easily as one of the top 3 nations for web development outsourcing.

Breadth of skills

With a substantial pool of resources working on online solutions in thousands of local and international projects the breadth of skills is really large in Bangladesh. We experience this regularly when we search for resources for our projects, almost any web technology weather it is a very exotic Javascript library or brand new unheard of cloud technology there is always resources available. There are two major reasons for this, the first is the substantial freelancing projects that prepare students and junior resources for web technology from projects outsourced to them from all over the world. This exposes resources to new technologies and with a very low barrier to entry into freelancing projects (e.g. with sites like upwork.com or freelancer.com) students and graduates of CS programs around the country find access to such experience easy. This leads to tremendous growth in skills with a wide variety of web development skills.

The other reason for the breadth of skills is the current trend in higher education institutions in Bangladesh to include programs that are job ready (read: web development ready). Whereas most CS departments around the world would treat a course on web development or web design not crucial to it’s program, most CS programs in Bangladesh includes these topics. This is mainly for the “job readiness” need for the programs that students and the parents push for. In a recent study by ADB about the higher education programs for IT in Bangladesh found this correlation with industry.

This double power of numbers matched with breadth of skills makes Bangladesh a powerhouse for web software development projects. Kaz has been in the forefront of this move, with our first project in 2004 on ASP.NET (relatively new technology those days) we have worked on more than a hundred web applications in technologies as diverse as .NET, Python, Node.js, Java, PHP and even Perl. Web is one of our big focus area for skills development. We have also been some of the first companies to work on Azure or AWS working on early adopter projects for our customers. We are happy to keep this tradition of leading the industry in Bangladesh in this exciting area.

4 Software team strategies that work

Flat hierarchy

It's important for the team to feel that they are not bogged down with management. We try to build this into the system by having very flat hierarchy in the teams. Usually a team a has a team lead and everyone reports to her. The team lead can decide pretty much everything as much as day to day operations of the team is concerned. This empowering of the teams help increase both our ingredients. Empowered teams feel more gelled because they feel their actions navigate the whole team and they feel more responsible for the whole group. Less hierarchy makes it easier for the team members to speak out and voice their concerns - increasing openness.

Small Teams

Lines of communications as the team size increases (source: Lines of COMMUNICATION)

Small group sizes are natural. If members of the team cannot know each other on a level where they consider each other friends the team’s ability to cooperate drops. The more people you have in a team the less a single team member contributes to the project - this was known as far back as 1913 when Maximilian Ringelmann discovered that the more people who pulled on a rope, the less effort each individual contributed. 

Smaller teams lead to more social cohesion, that leads to more individual responsibility and more productive work done per capita.

There is another strong reason for smaller teams: less time spent on communication. There’s a formula for this, the number of ways conversations can flow between person to person is:

n(n – 1) / 2
where n = the number of people in a team

So this builds up very fast as n becomes larger and larger. The graphic here shows this - things get messy quite fast. And the messier it is the more noise there is to get information across the team and thus more time spent in getting things done.

What’s the ideal team size?

It depends of course on the nature of the project. Jeff Bezos has the famous Two Pizza rule that goes - “If you can’t feed a team with two pizzas, it’s too large.” You’ll have to find out your own rule, but as long as you keep the team small you should win.

A great read when you are thinking about the optimal team size is: Productivity and Team Size: Less is More

Culture of openness

Software is all about discussions and debate. No single person, no matter how many years he has been “doing software” or how many fancy places she has worked in, will always have the correct plan. Yes experience helps but sometimes experience leads to “this is how I did it in 1997” type sentences that usually lead to badly designed software. The only way to solve this is to have discussions and debates (we call them “fights”) where everyone has a chance to voice their concerns. Now this only works if everyone has a say, or rather feels free voice their ideas. If the culture of openness is not there in a team, junior members of the team will always stay silent, or people with louder voice will always be the only people speaking. This gets you nowhere. So cultivate the culture of openness in the team. Take steps that make the team members feel free and relaxed. Our strategies are always to take them out of work environment say in a fun party or in one of trips or adventures and break the ice particularly between junior and senior members of team.

Culture of excellence

Cultivating a culture of excellence is very important for the performance of the team. This is why elite commando forces have “we are the best” motto. A culture of excellence builds a bond between team members that is commitment towards keeping the standard up. This is a basic tribal need of humans - we don’t want to let our tribe down. And when the tribe’s culture is being the best at what they do - that is what everyone strives to do. HBR had a great article about the culture of excellence in companies that’s a good read: Creating a purpose driven organization.

And here’s the customary stolen Dilbert…

How to find a good software developer?

Finding good software developers is probably the most important thing for any software venture be it a micro startup, a giant bank starting a new project or software company like us adding new developers to its team.

A good developer makes a software possible, it’s as simple as that. You can find a developer (there are millions out there just go to any jobseeker or freelancer site) with all the certificates in the world, you can pay him well, you can give her the more time than you had planned for, you can give him the best tools that money can buy but the output - the software she makes depends only on one variable - is she good at what she does. In most other professions as long as you get someone who has been trained to do his thing he will get the job done at some point - some faster than others, some better than others but the job will be done. But with software the number of years of training or the number of framed certificates is in no way a guarantee that your software will be made. Some people can make software (without a single certificate on his wall) and others just can’t.

Given this situation, finding a “good” software developer is critical. But how do you find one? How do you know that someone is that “good” developer? Not easy questions to answer and even after 16 years in this business of finding developers we get things wrong sometimes, but I’ll try to share some ideas that might help.

1. Good developers are “get the job done” people

The first thing is to define what is “good”. The easiest is to say “good” software developer is someone who gets the software made :) But we would not know that right at the beginning when she hasn’t had the chance to make the software (and we definitely can’t wait for the project to fail and find out she wasn’t our choice after all). So let’s define “good” based on qualities we are seeking in a coder which we can somehow test:

Good is someone who gets the job done.

“... the duct-tape programmer is not afraid to say, “multiple inheritance sucks. Stop it. Just stop.”

You see, everybody else is too afraid of looking stupid because they just can’t keep enough facts in their head at once to make multiple inheritance, or templates, or COM, or multithreading, or any of that stuff work. So they sheepishly go along with whatever faddish programming craziness has come down from the architecture astronauts who speak at conferences and write books and articles and are so much smarter than us that they don’t realize that the stuff that they’re promoting is too hard for us.”

— Joel Spolsky

In our profession you’ll find many (too many in my opinion) who are at the level of a University professor with deep theoretical knowledge about design patterns or Java history. You do not want them. They are going to waste your time by thinking too much about what’s right and what’s not. You want someone who might know everything about Java but can go into a piece of code, use google to find answers to his questions and put in a band aid like fix without any guilt complex about his lack of knowledge! You need someone who gets the job done. Someone who can play a multi-hatted role in the everyday business of software development. Joel used to call these rare people the “duct tape programmers”. A good read in this line of thinking is Eric Sink’s superb little timeless piece You need developers not programmers.

2. Good developers are not afraid to write code in front of you.

“Would you hire a magician without asking them to show you some magic tricks? Of course not.

Yet, every day, programmers are hired on the basis of an impressive resumé or because the interviewer enjoyed chatting with them.”

— Joel Spolsky

You hire developers to write code. So it is a very natural expectation that they should be able to write code right in front of you, right? You’ll be surprised about how often great resume holding (and of course certificates… OK you get my irrational bias against certificates…) people will just be too scared to write code in front of you (say during an interview). Or they’d just be all over the place with the code and come back to say something like “this will need to be refactored of course” or something fancy like that. Run. Run like mad from any developer who can’t start writing code at a moments notice. Good developers should be better at expressing themselves in code rather than in language.


3. Good developers come with references

Joel Spolsky

Author of the best blog in the world for software development experience www.joelonsoftware.com

This one so obvious that I won’t delve too much into it. But leave by saying that before a developer is called the quality of their reference from someone you can trust (rather than their resume) should be the big marker. You see good developers easily make themselves felt. So every manager, team lead, business owner knows who is good very easily just from experience. Because they have gone through and got (or did not get) their software. Only downside is most manager don’t want to lose their good developers and want to get rid of their bad ones, so you got to be careful about whose words you trust! Our trick has always been to find our own references from peers rather than bosses.

4. Good developers are found in forums

Good developers are often found lurking around in tech forums asking and answering questions. Stackoverflow is definitely the big one, but there are many others. So finding links to their stackoverflow status or contributions should be a good thing and similarly if you are desperate forums are a good place to seek these rare individuals out. Microsoft is infamous with this trick, we’ve lost several of our super stars with MS poaching on them all the way from Redmond. Imagine getting a call from MS one night? Who can fight with the gods? D… the Internet :(

OK before I lose it I’m off. Hope you find your good developer and if you can’t just get us to build your software for you, we are best after all :p

Top 5 things every developer should know about VR

Virtual Reality (VR) is the next big thing. There is no question about it. It is one of the big paradigm shifts in software that is happening right now. It requires as radical a shift in thinking, user behavior and applicability as the shift that happened when smart phones became widely adopted. So now is definitely the time for software developers to start exploring the technology and picking up the skills to future proof their careers.

However, as with any new technology and paradigm shift there are risks to be aware of, well not exactly all of them can be classed as “risk” maybe “issues” is a better word. Being aware of these issues will mean that a professional can make informed decisions about the time and money she is ready to invest on learning the ropes of this new space. Our recent experiences in working in VR projects has highlighted some of these issues to us and we wanted to share them with you. Here are our top 5 issues list:

1. VR is still locked down to separate islands of technology

VR technology and the relevant hardware as of now is very much a story of closed gardened companies fighting out a turf war. With all the major players in action (Apple, MS, FB, PS, etc.) and with newer disruptive players (MagicLeap, HTC Vive, etc.) this is looking like a very nasty war that just about started. And us developers and of course consumers are in the middle of it. This is going to take a while to resolve, for a winner (if at all) to come out and for some sane standards to emerge for developers to work on. There is still no solid standard for different hardware. And there are very little sign of any emerging. OpenVR is a good contender, but we are probably years away from knowing for sure.

So moral of the story is: any programming skills you pick up expect it to be just a temporary thing, just a window of knowing something about the platform rather than something you can use in real life projects for some time. So our advice is just don’t invest too much time on learning any API set yet.

2. Any hardware you buy today will be obsolete pretty soon

There are a multitude of VR hardware option already available and more coming almost every month. Googling will probably lead you to HTC Vive or Oculus Rift if you aiming for something high end, but all of them are pricey and clunky. With wires coming out like a patient in ICU you know these things won’t last. Even the wireless ones that are just emerging every new design involves changes in the hardware MagicLeap with all it’s hype and billions of dollars of funding churned out to be a disappointment which will soon need to be replaced. This is normal for any ground breaking technology such as VR (everything from computers, flat screen tvs to mobiles went through such a early phase). All of these current hardware will be junk in a year or so.

So moral of the story is: Only buy the hardware if you are OK to throw it away pretty soon.

3. VR first design is still in its infancy

VR (and more importantly XR see below) brings in a completely new take on UX. There is a lot to learn and this is a fast developing space. With very detailed research being done by leading institutions this is very much an area to keep an eye on and invest time on. Unlike the tech stack and the hardware, UX design principles are likely to be much more reusable as the technology matures.

So moral of the story is: Invest time on learning VR design ideas as they evolve.

4. VR sickness is a real problem

This is more from the trenches rather than the HQ like the other ones. After hours and hours of developing, trying, testing and debugging that all software require you’ll be seriously feeling the pain that comes with motion sickness like VR sickness It will lead to headaches at the very least. It gets slightly better over time but it still is a real problem when you are developing in this space. As long as you are aware of it, and you take necessary measures to address it (google will tell you some ideas that work) you should be fine. Our strategy is to use 50% vignette around the periphery during all development and taking breaks between headset sessions. Something else might work for you.

So moral of the story is: Read up about VR sickness.

5. XR will be the ultimate winner

I’ve been talking about VR but in all likelihood VR as we know today will not be around. XR is the more generic term that encompasses Augmented Reality (AR), Mixed Reality (MR) and VR. And it is XR that will what people will be using. VR by itself is just too much of the synthetic world where as AR or MR brings in the real possibility of interacting with real life objects overlayed with synthetic content. Wouldn’t you want to change the color of a room to your mood? :) So XR is the right technology to keep in mind and follow. Your current skills of VR will definitely help you get to XR faster but you should grab every chance to try out XR. MagicLeap may have churned out crappy stuff in it’s 1.0 but it’s always worth checking out their SDK and developer doc.

So moral of the story is: Read up about XR, invest more time on developing for XR if you can.

If I sound ominous and forbidding in this article please forgive me, I definitely don’t mean it. VR is a real exciting technology to get into right now. It’s fun and it’s challenging. We just love it. Here’s our designer (Shihab) imagining himself in the matrix world of VR immersion :)

To cubicle, or not, that is the question.

Most things in life has the Shakespearean ambivalence, but I can say without a shred of doubt that there is no uncertainty about the cubicle:

Cubicles are bad.

So “or not” is the right answer.

But if not cubicle, what?

That is where Shakespeare has the upper hand.

Companies large and small, universities and architectural firms have been trying to answer that question with mixed results. Let’s try to approach this with some data that proves quite strongly two things:

1. Proximity matters even in the age of digital

It has been found over and over that the physical proximity of people bring in more positive interactions and collaboration. Team that has team members on the same floor, same room are more efficient than team where the members are physically disbursed (yet connected with all kinds of communications platforms). MIT media lab has done extensive studies on effects of proximity on collaboration a summary of this was done by one of the researchers as follows:

“…the probability that any two people on a corporate campus will interact physically or digitally is directly proportional to the distance between their desks…”

— Ben Waber, Scientist MIT Media Lab

2. Interaction between different work groups reduces productivity

If there are separate groups within the company that work on completely different projects or areas no benefits come in making them interact more, in fact it reduces overall productivity of both teams. Research carried out in a major German bank showed that increasing interactions between teams undermined performance. So they moved teams into separate rooms. 

If you take the above 2 points as gospel then what is the logical conclusion? Keep individual teams together but separate from other teams. Simple.

A Pattern Language: Towns, Buildings, Construction (Center for Environmental Structure Series)

By Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, Shlomo Angel

And…drum roll please…. we have always known this answer. The answer has been in page 414 of our favorite book on work space design - A Pattern Language by Christopher Alexander.

“The fundamental learning situation is one in which a person learns by helping someone who really knows what he is doing.

…

Therefore:

Arrange the work in every workgroup, industry, and office, in such a way that work and learning go forward hand in hand. Treat every piece of work as an opportunity for learning. To this end, organize work around a tradition of masters and apprentices: and support this form of social organization with a division of the workspace into spatial clusters - one for each master and his apprentices where they can work and meet together.”

With our offices in older brick built houses with small rooms in the older part of Dhaka adopting this pattern has been easy. We can take a group of adjacent rooms (sometimes converting a connecting veranda that is very common in the older designs of Dhaka houses) to form the team space. We try to give the team lead some space of her own, ideally a room all by herself if possible. This makes it easy for her to act as the “mentor” when needed and also acts as the defacto meeting room where conversations (and noisy debates) can happen without disturbing the rest of the team members.

Brick walls ensure that interference from other teams and completely unrelated conversations don’t hinder the flow of the work of the team.

So as I said, Shakespeare has nothing to say to us when it comes to office layout. We got it figured out. But we love him anyway :)

Here’s the famous page 414 btw…

Where is your voice? - Voice design principles

Voice is here to stay. With services like Amazon Voice Service and devices like Alexa or Google home coming up in every home this is the brave new world of software interfaces.

The paradigm shift started when Apple first saved us from the clunky commands in a black DOS prompt back in 1984. This led to the wonderful world of the mouse, the click, the drag and the drop. Then Palm Pilot (remember those green things?) gave the excitement of a tap (more a poke with stylus, but not bad) in 1997. Then Steve Jobs came back to save us again with his iPhone (note to self: do not give a link) in 2007 with it’s fancy touch, pinch, pull and elasticity. We have to thank Jony Ive and his genius for making us humans get closer to technology.

Now is the new shift to two directions - XR with its full immersion on interface where interface is everything to Voice and its invisible interface - Alan Cooper’s dream come true with the most unobtrusive interface imaginable - the no interface.

As with every new design paradigm shift the new world of XR and voice requires us to re-think, re-learn and re-discover the design, development and testing process of software development. We found this with our recent projects in VR in our development and even testing. The same is very much true for voice user interfaces (VUI). A new design principle guides this space - the situational design. Voice apps require that software be designed with:

“Voice First Design”

Voice first design requires us to re-learn our thinking about software interfaces. Here are some pointer to start this re-think:

Expect variability and be adaptable

Each user is different and their use of spoken words is distinct and variable. What works for one, even a group will not work for everyone. All your designs need to take this into consideration, make the interfaces adaptable to user’s change of voice.

…the designer’s job shifts from picking the one label that works best for everyone to providing a range of utterances …

Personalize and individualize

You need to create a personal experience for users, whatever the actual voice device is intended for or your software is used for. The way to accomplish this is very different from what you are used to say for a mobile app where you might have the same popup to display personal data such as list of favorite sites. In voice interactions the interaction must be personalized since the same interaction, say with all the members of a family in the house where your app is running, will feel robotic rather than real and approachable.

Voice-first interactions should offer richer design. They should be predictable yet varied and delightful.

Expect to be called anytime

Gone are the days where users will need to switch on a device, find your app, click on a button to find you and get you to do something for them. They will expect you to be always there, a call away. You have no hierarchy of options - everything is first level, everything is ready to be called at moments notice.

You don’t want to be like those dismal IVRs that keep asking you to press 1 for life and 2 for death, do you?

Converse, be more human

Voice is inherently human like. Users will expect human like behavior from your app. The formality and disconnectedness of an app running in your computer is gone. Users’ expectation will be of a friend ready to be asked something, waiting to help out. Just google what people have been asking Siri. This is the new normal!

OK, done for today, but I have to get Scott Adam’s stab at this new fangled contraption before I go :) As always stolen without a hint of guilt…

How to make software in Bangladesh?

As a custom software development company operating out of Dhaka, Bangladesh for the past 16 years, a question we get asked all the time is “how do we make our software from Bangladesh?”. A variation to this “Wow, I had no idea that Bangladesh is so far ahead in software development". Bangladesh has indeed made huge strides in software development in the past few years.

When we started back in 2004 (feels like ancient times!) there were probably a dozen companies that were actually developing software. We registered as the 248th member at BASIS the official association for software companies in Bangladesh, but of the other 247 most were either dormant shell companies, ISPs, hardware and network equipment companies. The picture is completely different now, with literally hundreds of vibrant active software companies working from IoT to innovative apps, startups with the potential to become the next big thing and many world class custom software consultancies.

In recent report done by USAID - Comprehensive private sector assessment the domain spread of the software companies are described with the graphics below:

This shows how mature and broad the software development industry has become in Bangladesh. So the answer to the question in the title of this article is easy. If you are planning to make your software in Bangladesh you have many choices and you are very likely to find the company that has experience in your business and technology domain. We go over some of your options below:

Use a custom software development company

According to BASIS is there are more than 300+ well established companies who make custom software for their customers. The size varies from a student run small 1-5 person company to major enterprises with hundreds of developers. Accordingly you’ll also find a huge variation in pricing too. Whom you select would be a decision based on your budget and complexity of your software requirement.

Read our article on how to choose a good software vendor if you are new to this game.

Use a freelancer based in Bangladesh

There is a large number of freelancers working from home in Bangladesh. Many are excellent software developers who have worked on large international projects. Thus some of the freelancers have huge exposure and have skills comparable to any you can find in an established software company. Site such as upwork can easily get you connected with such freelancers. You can also find potential freelancers in LinkedIn or various developer forums. If your project does not require a team or if the specifications are well developed and you know exactly what you want, freelancers are a great option.

The only run is the long run - building a great software company

If you want to build a great software company, you should only build it with the long term in mind. This may sound counter-intuitive, after all the software world feels very short term with it’s ever changing technology and trends; and this sometimes leads the people who start and run a software company lose the long term view that most other industries have. Yet this is a fundamental mistake, at its heart the creation of software is a craft and sometimes even an art. And like all creative industry, it takes time, patience and resilience to perfect the creative process and culture.

When you have the long term in mind your mindset changes. Every business decisions you take changes. And all these little changes accumulate to a culture, a psyche and a people who value their work and their creation. This is the time honored strategy for all organizations that trades in the creative output. You don’t need it in a factory or say in a product manufacturing plant but you need it in a software company. Solely because a software company is never a product manufacturing plant. You may have heard it differently, you may even have started to believe it as such but it never is. Many have tried to force the “engineering” into a software company and failed. Many will no doubt keep trying, but I believe until we have built perfect AI bots that write software with built in human empathy, they too will fail.

The moment you bring in the long term you bring in decisions like: “it is better to take in a project that will not burn out my people” or “let’s invest a little more on the team’s ability to gel”. All of these lead to happiness - the magic that brings out the best in humans. And you need that best, for them to find the best solution to a next to impossible problem, or the most subtle way to let the user of their software know that they left an entry blank. With happiness you find passion in your software projects, you find people pro-actively participating to make the product better, challenging themselves to strive even higher.

As we start a new year, our 16th as a company, these are the words we keep reminding ourselves. The long term has always been our goal, even when we started with just three people working in a small room. And 16 years later we are happy that we had always stayed with that as our guiding star. It has not been easy, and we don’t expect it to be easy, but the journey has been amazing and that makes all the difference.

Here’s to a great new year. May this year be your greatest. And may we meet years from now and smile that we had taken the road less traveled.

Software without anger: managing yourself

After our first two articles ( Software without anger: managing the development team and Software without anger: managing vendor relationship ) in this series of anger management in software projects we got a lot of feedback asking us about how to manage anger on a personal level. What can we, as software professionals, do to reduce anger in software project? Be it within the team, with stakeholders and even with ourselves ( this last one becomes obvious when you think about how many times you’ve wanted to bang your head on the table when you realized that you should’ve written that generalized class to validate the data before an insert or something along those lines… ).

So today’s article is about us. Us the software professionals (ahem).

We know we can do a lot (and we should’ve done a lot) to make software projects anger and stress free. Maybe we have our own list of those to-dos. Here’s our attempt at that list…

1. Expect and accept anger as normal in software development.

This one is the same for all of the articles... Since the situation is the same, so I’ll do another ctrl+C and ctrl+V from the first article:

In any endeavor where there is a lot of unknowns and yet the risks and cost of getting things wrong are big, anger is natural. Anger is actually sometimes a good sign in software projects - it shows people involved in the process are emotionally attached to what they are doing and they care enough to voice things out. It is the negative aspects of anger like the blame game, shutting off channels of communications, creating bias, etc. that are destructive that you have to be worried about. If you expect and accept the fact that there will be anger, you can take steps to reduce it, manage it or channel its energy to a creative force.

It is the sudden rush of anger that you don’t expect in the otherwise calm and civil workplace (well for some I hear) that makes us go off balance. Instead of managing it we fumble and make it worse by being irrational and in many a case damage our relationships with others in the team and damage the chances of success in a software project.

The moment you expect anger as a natural outcome, you’ll be able to address it with strategies you know that work for you in other circumstances in your life. The particular strategy that works is very personal. Some people just takes a deep breath, someone I know takes a toilet break! For me the best thing is to stop saying whatever I was saying for a minute or so.

But expecting anger as a natural expected “artifact” doesn’t only mean that you can snuff it out when it comes. It also means that you can take steps to make sure situations that create anger do not happen, I discuss some such ideas below. And apart from snuffing it out, or avoiding it completely, anger can be channeled for the good of the project too! Anger is in essence passion and there is always a good use of passion in software projects! Good project managers us this passion all the time in situations like brainstorming or technical architecture discussions.

2. Prioritize, prioritize and prioritize

This is probably the most important single step you can do on a personal level to manage anger in your software project. There will always be way too many tasks coming towards you and there will always be a looming deadline that’s just too close for comfort. The only way to reduce stress (your own and the team’s when others are waiting for your work for theirs to be done) is to know what tasks are the most important.

Prioritize your tasks. Discuss them with your tech lead or manager. Discuss them in your daily stand-up. Scream (ok, maybe not scream in anger, that would defeat things ) if you feel you’ve been told to do something that you feel should not be high priority. Setting the priority of you tasks should be your highest priority :)

3. Read the spec!

OK, I probably mean understand what you are supposed to do in a task before jumping in to code it or test it. This might mean just reading the task ticket, or watching a video that explains things. But investing a little time to understand the task properly saves a lot of your time later on. It sounds very obvious, but I think we all know that we can be drifting with the flow on a lot cases and just jumping in to the code feels a lot easier sometimes rather than talk to a product manager about something that’s confusing. But that is a recipe for a heated conversation somewhere down the line. Not worth it.

4. Keep an open mind

Nothing in our field is set in stone. No technology is the final word and nothing is perfect. And today’s greatest stack will be the trash of tomorrow. That’s how our space is like, we knew it when we got into this. So there is absolutely no reason at all to be a staunch supporter of a technique, stack, idea, “pattern”, DB, __ (fill in the blanks). If you keep reminding yourself this fact then keeping an open mind is easy, and then discussions and debates about technology becomes finding out good solution for the problem at hand with the currently available skills and technology - rather than a religious war that these discussions sometimes warp into :)

5. Remember that there is always a next version

There will always be scope in your work. You will never be able to finish all the things you wanted to do. Scope your work, do what’s needed now and plan the rest for the next iteration. This helps move the project forward, keeps your boss and your teammates happy and you out of anger.

I’ll keep to the pattern of this series of articles by using a 3 stooges picture. This just one of them.

Software without anger: managing the development team

Isn’t that a great title for an article about software development? If you’ve ever been involved in a software development project this would ring bells!

This was the starting in the first article on this series - Software without anger: managing vendor relationship which goes over the distilled wisdom of 15 years or so that we’ve been around in this business of making software for our customers. That was all about how to manage the relationship with the software team that’s outside your company, say for an outsourced project, or for a team of yours that works offsite away from regular face to face interactions. Today’s blog is about managing your in-house team of software developers, designers and QA professionals. I can never decide if it’s easier if the team is in-house, but I think an entrepreneur is just faced with a different set of problems which require a different set of solutions. So here goes…as promised - a list of - “distilled wisdom” :)

1. Expect and accept anger as normal in software development.

Umm, this the same as with the vendor relationship. Since the situation is the same, so I’ll do the infamous ctrl+C and ctrl+V

In any endeavor where there is a lot of unknowns and yet the risks and cost of getting things wrong are big, anger is natural. Anger is actually sometimes a good sign in software projects - it shows people involved in the process are emotionally attached to what they are doing and they care enough to voice things out. It is the negative aspects of anger like the blame game, shutting off channels of communications, creating bias, etc. that are destructive, that you have to be worried about. If you expect and accept the fact that there will be anger, you can take steps to reduce it, manage it or channel its energy to a creative force.

The only thing to add to this for an in-house team is, since you see the anger first hand, as it starts to pick up steam you have to move quickly. You should never leave a conversation that started moving to anger without diffusing it in the direction of a creative conversation. Striking while the iron is hot is the name of the game for this.

2. Create a culture of celebrating a dissenting voice

A dissenting voice is a voice that checks assumptions, tests logic and make the overall process stronger. It is almost always good for a software development process. The only time you don’t want a good “fight” in software discussions is when ego is getting involved and the discussion becomes a war of words rather than a debate based on logic. So you should make it easier for people to voice their concerns, actually make it welcome and celebrated. That way people will speak out, and feel that it is accepted and is part of the healthy brainstorming that goes on in a team all the time. Taking the taboo out of the dissent makes it feel like professional skill and somehow takes away the purely negative “anger” component out from a discussion where two sides have opposing view.

It’s a delicate balance, but once you create that culture life becomes so much better and your software too!

3. Have a clear and readily available set of requirements at all times

When I say requirements, I don’t exactly mean like spec documents or a bunch of mock-ups. I mean at any point of time the team should have access to resources that make it crystal clear what they are supposed to be making at that point in time. So, to do that you’ll probably need a task management system (e.g. a Jira board), a set of mock-ups that have been scoped and discussed for the task in hand, a meeting or two beforehand that clearly goes over what you are trying to build over next few days/weeks, etc.

As soon as the team knows exactly what they should be making you’ll find that the destructive anger that comes from confusion and that always leads to a blame game goes away. That’s the type of anger you can never manage and resolve easily. Take that out and half of your job is done in anger management in a software project!

4. Always have a confident “supreme court” for final decisions

That’s probably the team lead or the founder or even the designer. It’s not very important who it is as long as there is only one at all time, whose decisions, people know, cannot be overturned and obviously someone who is just (most of the times).

Most tech debates (aka anger) have multiple possible resolutions. Usually more than one of the solutions being debated works great as long as everyone accepts it. But tech debates comes with people who are married to their ideas (“I’ve got a unique solution that no one has thought of”), philosophies (“Java is the best”), past (“It worked for the last project”) and the worst - latest fads (“micro-services is the future”). Many times the only way out of a prolonged discussion, that starts to loop over the same few arguments, is a judge making a call and putting an end to the debate. Not easy to find a judge who can instill that confidence but it’s not impossible.

5. A gelled team is the only way out

At the end, nothing is better than a team that trusts each other, considers each other as friends and are happy to work with each other - a gelled team. Just as in a family or a group of friends high emotions and anger fizzle out because of the strength of their relationships, a gelled team can absorb and diffuse any anger. We have written extensively about gelled teams. This is our big mantra, our grand unified theory, our secret sauce at Kaz Software. This is what makes us good at what we do over and over. Read some of our past blogs for some idea, Two ingredient recipe for a great software team or 5 Easy steps to kill the deadly PDI in your software team or Burn the cubicles - in the pursuit of happiness or the ever so famous Barbecued dog is good for software :)

Since I have the 3 stooges always fighting in this series, let me end with one where they are a happy gelled team which they actually are.

Software without anger: managing vendor relationship

Isn’t that a great title for an article about software development? If you’ve ever been involved in a software development project this would ring bells! And if you have not been, but you are thinking of starting a software company or working with a vendor to make a software you should definitely learn about this. Because want it or not, anger will come. You’d be very lucky if it’s only once in a while that people are angry, it could easily be that the whole project is a series of angry exchanges!

FEAR NOT.

This is a problem that can easily be managed (if not completely avoided) if you take some simple steps. So here goes our strategies for anger managed software project. I want to split these strategies up in separate articles, one about managing anger between you and the outside software development partner, one about strategies to use to manage anger when your developers are in house and the last one about strategies to manage your own anger (remember, you are sometimes one of those angry people)!

Today’s article is about strategies for managing software projects that are outsourced to custom software development company like us.

1. Expect and accept anger as normal in software development.

   In any endeavor where there is a lot of unknowns and yet the risks and cost of getting things wrong are big anger is natural. Anger is actually sometimes good sign in software projects - it shows people involved in the process are emotionally attached to what they are doing and they care enough to voice things out. It is the negative aspects of anger like the blame game, shutting off channels of communications, creating bias, etc. that are destructive that you have to be worried about. If you expect and accept the fact that there will be anger, you can take steps to reduce it, manage it or channel its energy to a creative force.

2. Know that software development is a fluid process.

   The top thing you need to understand when you are managing anger or designing a process to reduce it, is that software development is inherently a fluid process. You just can’t have it structured as precision engineering process (e.g. like a building a bridge) where everything is thought out and can be measured. Every step of the software development process involves reviewing what you initially thought needed to be done and changing it. Remember why Agile process is so successful - “embrace change”. So all your contracts, documents, dev cycles, demos, monitoring, analysis of work should have the possibility of change taken into account. For example your software development contracts with the vendor should have clauses to cover situation where there are changes. Timeline and delivery milestones should have padding for inevitable change. The list goes on.

3. Scope, scope and scope.

   The full software will probably do a lot of things one day (maybe even change the world) but for the small block of time that you are working on, or the immediate delivery you are waiting for will only be for a small section of those things. So you’ll need to first identify clearly what you want to achieve, define and document those features and then communicate that to the developers. You are scoping the limits of a delivery. If you do that clearly, right up front and stick to it (as much as possible without harming your business) you’ll get rid of most of the destructive anger in a software project.

4. Have regular scheduled meetings.

   As the software is being built offsite by a team that is not always in touch with you regularly things can easily go in the wrong direction. It’s essential to have regular meetings at short intervals. That makes it easy to find errors early, give feedback early and get the development back on track faster. Bunching up a lot of development work to be reviewed in one go is a recipe for disaster and fights. It is counter productive and actually wastes much more of your time than the time you thought you were saving but not doing regular meetings. How regular? Depends on the nature of the project, but I will say the meetings should never be more than weeks apart.

5. Create an environment of trust and collaboration.

   For a software project that is outsourced this is a really big one, and most of the responsibility fall on you as you are the ultimate customer as much as the software team is concerned. You set the tone of the collaboration. If you set it so that it’s always combative then you’ll have your vendor always trying to be defensive. They will hide things from you, be less proactive, less likely to point out errors on your part. Set the tone from the start that you have trust and that the project is a collaboration. That will make way for conversations that addresses issues with reason rather than emotion or subterfuge.

6. Always celebrate victories.

   Make deliveries and reaching milestones a big thing. Treat your team to a party, give them some symbolic gifts (even a congratulatory email goes a long way). This celebration renews the relationship, gives it the time to rest and prepare for the next cycle. And most importantly this celebration makes it easy for people to forget bad feelings and make them move on with renewed energy. It is like the restart button on a game gone wrong!

That’s all for today, wait a bit for my other one about keeping your in house development process happy. By the way this article was my chance once again to use old black and white pics stolen from the web particularly of the three stooges. We used to have this as a tradition for all our articles some years ago!

Mobile games development in Bangladesh

At Kaz we’ve been developing mobile applications for ages. When we did our first few apps way back in 2008 (scary!) we learnt our first lessons about how different the mobile space was. We blogged about our experiences.

Over the years we’ve honed our skills and learnt the art of making cool mobile apps that hits the spot. Mobile apps just have to be enough to get your job done without fuss and no more. And while it’s being not fussy, it needs to be uber stylish! Easy we say these days, and love any new mobile app that comes our way. With more than 30 apps under our belt we can certainly say we’ve been around the block!

Today’s blog will be a bit unusual. I’ll just put up some random thoughts and mini-wisdom that we’ve picked up over the years working as the mobile games developer based in Bangladesh.

Mobile games are a different beast

Now in the wide world of mobile apps, games are the most fun to make. But as the title says, they are a different beast altogether. There’s a bunch of things that you just have to get right to make a superb game.

Graphics and play

You’ve got to get the flow just perfect with graphics that oozes with fun and gaming moves that are fun and swift.

Performance

If you have those sorted out then you get into the wonderful world of performance tuning. Making the game fast in a wide variety of devices (if you are covering Android then some historic junks in that mix too!) is a real challenge.

Store presence

And once all of that is done and dusted you have the challenge of making it stand out in the super crowded marketplace. We are a full service mobile apps developer, so we help our customers with everything related to getting the game on store which includes all those cool videos and screenshots that need to get people to download. Probably the hardest part in the story if you ask me!

Now enter in this story the new phenomenon of

hyper casual games

The italic, bold and large casing for this class of mobile games is intentional. They are a Universe on their own. The magic word in this space “fast“. How fast can you churn out a concept and get it live to try out download? See in this world there is no known formula, even the best ideas can die in a matter of minutes. The only thing that a software partner for mobile apps can help is to make the games as fast as possible. We help our customers with these projects by brainstorming out the bare basic game that has the main element of fun in the game play. We get this built in a matter of weeks (usually days) and get them out to the play store for testing out user adoption. The holy grail is user download and retention on day 1 and 5 (hopefully).

New rules for a new ball game.

Anyway, gotta go. Told you today’s blog would be weird one. But if you are looking for a uber cool, super fast software development company for mobile apps give us a ping. We think we can help you. Use the form below to get a free quote for the mobile app you want to make. You’ll be surprised!