Talent is everything in software

I come across a lot of NDA (non disclosure agreements) in my work with startups with the next big ideas. And NDAs are good since it give both sides a sense of confidence in sharing information. But at it’s core I sometimes find a feeling that it is the idea that’s super precious and a big secret. I think that’s a mistake.

Ideas, are easy - “a dime a dozen”.

It is the implementation of it that makes all the difference.

And it’s the talent that makes the implementation possible.

This might sound controversial. After all if Mark Zuckerberg gave out his idea of a social network that can connect friends and family (and random virtual “friends” who might or might not exist) wouldn’t someone else have built Facebook? Or if Elon Musk told everyone about his electric cars wouldn’t GM be building something called Gelsa today? Not really, you know this right? Friendster (with that golden metric - MAU - monthly active users in the range 3 million as early as 2003) , Myspace, Hi5(?) are just some other equally social and equally good at making strangers friends were already around when FB cam along.

Source: MySpace’s Rise and Fall – A Timeline of Highs and Lows

Actually as late as 2008 when FB was more than 4 years old already, Myspace was the top social networking platform, and consistently beat FB in traffic. Facebook did little harm to Myspace's popularity; at the time, Facebook was targeted only at college students. At its top, when News Corp attempted to merge it with Yahoo! in 2007, Myspace was valued at $12 billion! And if you look at the chart here that shows visitor counts for MySpace, as late as 2011 it was fighting out ( and losing) with respectable numbers.

Myspace is definitely a story of how not to do things. There is a lot to learn from it’s demise and there has been a lot written about it, I urge you to read some. But I digress from today’s topic.

As for stealing Musk’s idea, electric cars are obviously nothing new. There working models even in the early 1960s! For a great video about a quick recap about this space check out the video here.

Anyway, getting back to my point, there was nothing unique or even new about FB or Tesla. They just made it right, their implementation was better than others.

If you look around you would find this to be true for almost any idea you can think of or any successful software startup you see you’ll find that the idea had been around, maybe no one built it or others built it but they built it wrong. Just check out Kickstarter the amazing quality, uniqueness and breadth of some of the ideas are just mind blowing. But how many makes it big? And when they do why? You’ll always find that it’s because of their implementation.

And behind any good implementation is the team that build it. So using simple logic we have:

Talented team -> Great implementation -> Success

This may sound obvious, but you’d be surprise how many startups gets lost in thought that they have the best idea in the world and whatever team works on it, they will make it a big success. I would strongly argue the other way and say:

Hire the best team -> Think of an idea -> Success

OK that probably doesn’t work for a lot of startup owners since obviously its idea first for most founders. But if you believe in that formula of talent first you’ll probably morph into something like below:

Idea -> Hire the best team -> Morph the idea -> Success

That to me is the best formula for a founder thinking of making her ideas come to life. Oh, btw, I have the perfect Dilbert for today’s post…

Do not disturb a software developer in "flow"

“The trouble is, getting into “the zone” is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity.”

— Joel Spolsky

Source: THIS IS WHY YOU SHOULDN'T INTERRUPT A PROGRAMMER

The world is full of distraction, particularly in this point in time. Facebook keeps enticing us with yet another friend’s trip to the tropical paradise we always wanted to go, Twitter pings us about Mr. Trump’s newest normal and that infernal device in our pocket keeps buzzing and beeping. Yet as software developers we are most in need of concentration, we need to think, juggle hundreds of ideas and pointers in our head and let our brain do its magic. A single distraction during this process is like a shrill cry in the middle of the silence in a temple.

I saw an amazing cartoon sometime back that explains this in very funny terms, I’ve copied it over here and keep it as the entire right column for today’s little rant about why coders should not be disturbed yet they are at every possible moment during their typical work day.

Here are some of the things we remind ourselves every day to stop disturbing ourselves and our colleagues at work.

Don’t ask a random question

The random passing question to a code deep in work is the number 1 culprit for distraction and loss of flow. It’s tempting to ask how the party went last night for example but asking it while someone has just managed to understand a weird for loop written years ago is a major sin. Please don’t ask randomly without checking if that person is free or not.

Keep developer rooms silent

Noise and particularly the someone speaking on the phone is horrible for anyone trying to concentrate. Developer rooms should follow the silence rule that libraries have. Discussions, debates, phone calls should all be taken out of the dev rooms into the verandas or the meeting rooms.

Open offices are bad

Large open offices where many different teams are working at the same time (and the worst of all developers working with sales teams sitting close by) are bad for concentration. We feel strongly about having semi private offices where only a single small team sits together with their lead in a separate space or room in that area. We’ve written many times about workspace layouts that are good for software companies. Here’s a recent article: To cubicle, or not, that is the question.

Optimize meeting start times

Work meetings in the middle of workdays are a major source of distraction. It prevents developers from concentrating and working on a large piece of software in the fear that they will get distracted in the middle. And most meetings lead to a long time settle back to full concentration. Meetings should be timed at points when the developer has not yet started to pick up tasks (say beginning of the day) or has had a natural break in work (say right after lunch).

Self discipline goes a long way

Last but not least: funnily enough studies show that we ourselves are a major source of distraction. With all the social media and youtube just a click away this isn’t too hard to understand. This is where the self discipline comes in, prioritizing our work and keeping set timeline for launching FB or even checking our emails has a huge impact on our productivity.

5 UX rule every software founder should know about

I’ve found that in my chats with founders I keep coming to some common themes. And it doesn’t matter if the founder has been working on technology all his life or if he has no idea about software. One of those common themes is the discussion about how to make decisions about the actual user interface of the features that she has been dreaming up. For the technically minded founder it becomes a thing of do I use this pattern or that, or a strong bias of of some type (e.g. “less is more”, “pop ups are banned”, or something along those lines) and for the non technical founder it’s usually a more dangerous situation of absolute certainty about how the feature should be (usually with at least 20 buttons and a lot of color). The recurring theme follows a common script where we listen to the instructions, we try suggesting some changes and are met with strong opposition and sometimes dismay and we then suggest we draw this up (hoping that we might tweak things during that process). In most cases at some point we can convince the founder to have an open mind and make decisions about the user interface and interaction based on a rationale and sometimes also a debate. I used to point everyone to my favorite Alan Cooper’s About Face, it’s one of those books that equally valuable to the professionals as it’s to someone with a passing interest in UX. But now I find it easier to point to the amazing https://goodui.org/ as first step about thinking about patterns and rules of thumb in UI/UX (probably a sign that many of our new founders are from a generation that is more used to online content, quick reads and youtube).

Over the years, there are some UX wisdom that kind of made sense the moment we shared them with someone who didn’t know about them (or someone who knew but just haven’t thought about that for a while). These “instant hits” are really good to keep in mind when you are thinking about software interfaces but they are equally good to impress someone over a drink! So I thought it would be a good idea to do a quick and easy list of great UX wisdom today. Here’s my list of 5 of the easiest (and probably greatest too):

1. Fitt’s Law - larger and closer click-ability is better

Simple and logical rule of thumb which says you should always make the clickables (buttons, links, menus, etc.) large and close to where your mouse is currently. It’s so strong and has so much data to support it that it’s a “law” ! To implement Fitt’s law here are the two simple things you have to remember:

• Most used UI elements should be on the edges of the screen. Because the cursor automatically stops at the edges, they will be easier to click on.

• Make clickable areas as large as possible. Larger targets are easier to click on.

Fitt’s law is why tapping on those bigger commonly used buttons at the bottom of the iphone screen (where your thumb is) is so satisfying.

2. Hide your “ejector seat lever”

This one is from Alan Cooper. Again, very simple, you would never put the ejector seat lever button which ejects the pilot from a plane next to a common thing like light switch - just because accidents might happen. Same in software, don’t put major decision action elements (aka… buttons e.g.) next to and in similar level as other lesser ones. See how gmail keeps the trash option far away from the others and make the send button significantly different it’s neighbors? Great job.

Here’s the section from the man himself. If you haven’t got this book, buy it, if you have anything to do with software you should treat this as your religious text.

About Face: The Essentials of Interaction Design

By Alan Cooper, Robert Reimann, David Cronin, Christopher Noessel

3. Fewer is always better

GoodUI

Not sure if there is “pattern” with that exact wording, but there are many patterns and rules of thumb that can be distilled into this simple rule of thumb. The rule is just what it says, if you have an option between two sets of UI both of which gets the job done then the better one is the one with fewer elements, fewer actions, fewer buttons, fewer picture, fewer .. ok you get my point. You’ll find many versions of this rule, say if for a form GoodUI just has it as idea #13

This is why Google’s insanely simple home page for search was and is still the winner.

4. Progressive disclosure

Sounds fancy but all this is saying is that you should not show all your features to the user in one go and overwhelm him. Just delay displaying advanced or rarely used features, push them secondary screens, this will make your software easier to learn and keep your users engaged.

By hiding complex things, you are making the initial interfaces clutter free. You are also giving the user the time to learn your software, get small dopamine hits of success as they successfully use the software to get their job done. For some of the features there might be no other way but to get the user to do all the screens, but use this pattern to just split it up and show the screens in steps - keeping the user happy and engaged. The goal is to show only essential information. Then get the users to take the next step. When the user completes a step, reveal the information in that new step, keeping current state visible. By keeping previous steps, users can change what they have put in. Here’s a much more detailed version of this pattern.

5. A clear primary action for every interface

Every interface you build must have a single action that it wants the user to accomplish - the primary action. Focusing on splitting the interfaces up so that they don’t offer a multitude of actions each leading to a new path saves the user from confusion and the complex task of remember where they are within your software. The primary action button (or element) should focused, highlighted and obvious. All the wording, graphics of that interface should support that single primary action.

If the interface is for submitting generating an invoice, there should a big highlighted button called “Generate Invoice” for example. Well, life isn’t always that clear cut, but you’ll find that you can always find a solution that pays respect to this single (or at least clear) primary action. And this makes the interface so much easier to use. Something as complex as gmail’s logged in home screen, that probably has at least 100 clickable elements and action item can still offer that primary action feel. Almost the first thing you notice is that significantly different Compose button that’s inviting you to click it.

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

How to reduce the cost of making a software?

As a custom software development company a common question we get asked is about reducing the cost of development. Software development is expensive. Even using relatively lower cost countries such as Bangladesh or Cambodia, a startup owner is likely to spend the largest portions of her funds on making the software. Yet software is only a piece of the story and usually the one of the first ones, huge costs waits for her in marketing and sales that she has to budget for. Hence cost optimization and reduction is an important strategy for the software development, and if done right can be a deciding factor for the success of the startup.

Here are some strategies we suggest to startups (and even established and large companies) to manage, optimize and reduce their software development costs:

Use an outside development company

Salary cost, particularly development salary cost takes up the largest regular cost of a company. An in house software team is invaluable, there is no question about it but when budgeting becomes tight, using an outside development team that can be dialed up and dialed down on short notice is the single best move a company can take. This gives them immense flexibility to adjust and control the cost on a regular basis and defer the risk of financial commitment of an in house dev team (which I think is essential once the software and business is established).

Source: Inc article

The graphic here shows the social sharing and marketing company Buffer’s average monthly costs. Thanks to Buffer’s open book policy this information is available for a live 7+ million dollar annual revenue company and will give a rough picture of how the costs are laid out. As expected about 69% of cost is spent on salary (for 64 employees when this data was taken).

In case of this example, the company has already produced its flagship product. The initial time when the product was being built would incur a much larger cost. For many software projects and startups this initial injection of fund can a big problem or might lead little or no funds for the marketing effort that will follow the launch of the product.

Finding good software development vendor and utilizing that vendor in an optimal way can give startups a huge edge over its competition yet keep the overall flexibility in its business operations.

Advancing the project tasks by non developers

Many software project tasks can be done in house by the founders or members of the existing team. Getting these tasks done would mean that the total effort by the software development team (in house or outside vendor) would be reduced. This leads to higher productivity for the team and obviously less cost per feature.

A great example of project tasks that can be done by a founder herself (or non developers in the team) is the creation of initial product ideas and wire frames. Sometimes founders approach dev teams just a list of ideas say in an email, this means the development or product team has to work to turn those into usable specification. This requirement analysis cycle can be quite prolonged if the founder or key stakeholder hasn’t fleshed out the ideas well and has to go through prolonged sessions involving members of the technical team or the outside vendor. The whole process can be fast forwarded and compressed if the founder can think through the ideas and use an easy to use mockup tool (our favorite is of course balsamiq ) draw out the ideas. The whole requirement process then gets cut down by as much as 80% in our experience.

Non development stakeholders and founders can also help out on many other areas of the software development process like testing, helping with documentation etc. All of these add up to create substantial reduction of costs for making the software.

Keeping the requirements stable

One of the biggest way of increasing cost of a software project is feature creep or constantly changing requirements. When a software development team has a clear specification it can plan and implement the features at a very fast pace. But as soon as those initial specifications start changing or new features start creeping in (because “business demands it”) the cost of rework and changed priorities will also pile up. Over time this single cause lead to cost increases by 100-200% if not controlled in our experience. So this is a single big area to be concerned about and control to keep the cost of software development under control.

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.

How to talk about your software before launch?

Buzz is everything these days. I blame Apple for this, remember those lines to buy an mp3 player called the iPod or worse a mobile phone called iPhone? But to be fair “buzz” as a marketing tool - to build up anticipation about products has always been there. Building up of anticipation leads to people talking and that leads to that most coveted of words “viral”. A famous example is the "Get your free email at Hotmail" that when MS started adding to their customers’ email circa 1996 to “talk and hint” about hotmail led to 12 million users in 1.5 years! Wouldn’t you love that for the software you are bringing out the world tomorrow?

“ ... could you put a message at the bottom of everybody’s screen.?”

“Of course we can technically do it,” Smith said.

“Oh, great,” Draper said. “And it can persist, right? You can put it on one message and if he sends an email to somebody else you can put it on that one, too, right?”

“Yeah, yeah,” Smith said, not convinced.

“So put ‘PS: I love you. Get your free e-mail at Hotmail’ at the bottom....”

— Conversation around how news about Hotmail might leak

So if you want to sell your that piece of software that you’ve been dreaming of, spending most of your time, money and energy on then you a have to talk. But how much do you talk? What do you say? Here’s some of our ideas from our 16 years of helping startups build, launch and market their software.

Always under promise and then over deliver

When you talk about the upcoming product to potential customers they will inevitably imagine that your product will do all kinds of things that it may not actually do. Since you are all hyped up and you obviously think your product is the cure for cancer you transmit that enthusiasm in your description. Which is great but if you aren’t careful the picture that your potential user is getting is beyond anything your product will ever be able to deliver. When you finally deliver the actual product, they are bound to be disappointed. Which will lead to bad reviews by word of mouth or worse over the Internet. This will hurt your sales in ways you cannot control. A recent classic (but completely unavoidable though given the situation) was the MagicLeap product. With billions of funding and amazing stories told the actual first version of the product could only disappoint. But if you consider the product by iteself it still is unique and amazing.

The only solution is to make sure you are under promising with the tacit knowledge that when you over deliver the surprise and delight will help.

Keep your dates flexible as much as you can

If you want to keep your promises, you can’t talk about upcoming release dates unless you’re willing to gamble. Software projects have inherent risks of delay. Something can and usually does go wrong, Murphy’s law always wins. Missed release dates leads to disappointment and frustration. And that leads to disregard. In these days of low attention span, once you’ve lost the attention, there is very little chance of you getting it back. So when you talk about your upcoming product keep those dates fuzzy - well you have to tell at some point obviously but say it as late as possible so that the date you say is a reliable one. “Coming soon” probably is too fuzzy but coming this summer is superb.

Keep the story consistent

Classic feature creep. Need to do a course to understand how to use your remote?

Right at the beginning think through what you are going talk about and how much. Keep to that script. If needed practice it. Every external touch point from the website to your chat with a vendor should stick to the original script. Slipping a product feature out means you better have that product feature just the way you described it - so describing it in different ways with ever so little bells and whistles added on is a disaster waiting to happen.

We see this a lot with new founders, who has been dreaming up their product for a while. The actual product that will go out on a 1.0 is usually just 10% of the founder’s original vision. It is a scoped, sane, planned set of features that led to a project plan and timeline. If the founder now drops in his ideas from the 90% that’s left out he has finds it extremely difficult to leave out - leading to the infamous feature creep that destroys software projects.

I have feeling that most TV remotes around this world are results of crazy CEOs bragging about how many things his TV can do over a drink too many :) I can never figure out what most of those buttons do…

Have a company policy about leaks

I know, most startup products are not as famous as Apple or MS and don’t have to have the dramas of leaving as yet unrevealed phones left on at bars. But still, if you are to stick with your story and your plan of keeping to under promise and over deliver you’ve got to put in a policy of what to share about the upcoming product in the company. Developers or designers working on the product will talk about their work with their friends and family. That’s normal human behavior about creative output. So if you don’t lay out a plan, that better be simple, of what and how much to leak you are likely to face a lot of heartache.

OK, I’m done for today. Here’s a great Dilbert for today’s feature creep fear that every developer has nightmares about.

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!

How to make your own software product by yourself?

The world of entrepreneurship with software solutions is challenging to say the least. Software is expensive to make. Software is difficult to make right. And above all it’s super hard to know if the software you are making is ever going to make you any money. With such risks involved it is always a very hard decision for cash strapped startups (that don’t have a few billion to spare from VCs) to turn their ideas to usable software. In our everyday business of making custom software for our customers a large proportion of whom are startups we get asked the following type of questions a lot:

“Can we make our own software without any coding skills?”

“Can I learn a bit of Python and make this at home?”

“How can I make a prototype to test my idea?”

“Is there a way to make software by myself?”

Although as professionals our first reaction is always to say “no”, but in reality the answer is not so straight forward. In most of cases the answers are probably “yes, but …” The “but” is from the knowledge that getting a customized software solution done without any coding skills is very difficult. However,

it is not impossible

Actually our realization is that in many a cases it is the better thing to do, the better business decision and a better survival idea for a startup. In our experience, here are some of the situations where a founder should invest her time and energy to find out if the first version of the product can be made at home:

• When cash is too low for using a reliable vendor.

• When the idea is to vague and the business case not clear enough.

• When the app’s features and UI feel like something that is very common.

• When all that is required is a quick prototype to get feedback.

In situations like the above, a founder can try making the software himself to get at least to a prototype that he can show to others, to potential users, to possible investors. She can also try out the idea on a small scale, like with her own friends and family to see if this would ever take off. This is of immense value to validate or discard ideas and more importantly to pivot on the original idea to something that would actually work or sell - a fact of life for every idea in this world. Remember, the great Facebook started as a “hot or not?” site for Harvard students ? You just don’t know how much of your idea will change to become a real product that people use or really need. And this process of finding out the changes and pivoting is extremely expensive that most startups find impossible to cross over and great ideas die. Having the ability to do these tests, failures and pivoting at very low cost (mostly of the founders’ time and energy) is really a big thing. And even the act of trying to make the software is a very good learning experience for the would be software owner. It gives non technical founders a feel of what’s involved in the development of software, the challenges and the reality of getting things done.

Great, so how do I make my software again?

Source: Stackoverflow developer survey 2015

:) Well a non technical person can always learn a programming language. Coding isn’t really that difficult as its sometimes portrayed to be. In a survey done by Stackoverflow (probably world’s top most coder forum these days) almost of half the coders didn’t have any formal education in programming and they were self taught - 48% of respondents never received a degree in computer science. And we are talking of top professionals in this field.

So learning to code and using that knowledge to make your software is definitely a feasible option. It depends on how committed you are, how much of knack you have for picking up new things particularly technical things. With youtube videos on practically any coding platform in the world or online tutorials and course on sites udemy or couresera anyone can become really good at coding.

The other thing to remember is that programming languages and platforms are getting much easier. The days of C/C++ and black terminals running weird text editors and magical incantations of “greps” and “emacs” are long gone. Most programming interfaces are super user friendly these days and the programming languages are forgiving and less ominous. On top of that there is an advent of visual drag and drop like programming interfaces that takes care of hiding the actual language from the user.

But how about NO CODE?

The nice thing about technology is that it is always expanding. So as time goes by more and more technology is coming up which let’s non technical people create software easily without even learning any code at all. There is a whole family of these “No Code” platforms available now and new ones coming out often. Google will be your friend for this, a search with “no code programming” or similar would give you links to such platforms and videos to give you preview of what’s involved. Some of them are very powerful, to the point that we have started pointing them to people who are interested. Here are some that looks promising:

GoodBarber - No code mobile applications creator with free trials and loads of tutorials. Good for eCommerce apps and if you are thinking of content heavy apps. Really worth exploring before you spend any money on custom dev.

AppSheet - If your app has a lot of data that needs slicing and dicing or lists that needs to be displayed, this is an interesting platform to explore.

AirTable - Has hundreds of templates to start your data heavy apps that can integrate with other APIs. The promises are amazing, but we’ve never tried this out yet.

I’ll finish with my customary stolen Dilbert - a nerdy sideways jab at non techies maybe, but funny nevertheless :)

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…

Documents every successful software project needs

When you start developing a software product, you need an idea of what you want each component of the software to do. From the part 1 in this series on defining products 3 Questions to define a software product, you now know the essential questions you need to ask to define your product. Today I’ll be doing part 2 that goes over how you document the requirements.

Knowing why, what and how your software product will be isn’t the end of the line for the product managers. You need prepare the documents, lists of requirements, UX modelling, etc. to make your development process easier. These, seems like a long process but it also serves over time as well.

If you don’t have your requirements straightened out, then how can you complete your project. And not just you, your developers will often want to freeze their development process based on some initial works of the definition. Once that is cleared out then proceed with development. Some call it the classic waterfall paradigm. This doesn’t work in any situation.

So, what can you do, keeping in mind you are the middle man, your failure to capture the whole product will affect both your customers and your developers?

You create baseline documents of the product you are planning to build.

Baseline Documents

Baseline Documents are documentations of a product that is formally reviewed, revised and accepted in their current forms, to serve as a detailed definition of what needs to be built. A simpler form of explaining would be to say a “blueprint” of the software that you will be developing. These documents may include the following types of requirement specifications:

• Functional requirements

• Non-functional (technical) requirements

Functional requirements

Functional requirement documents help SPMs to understand the characteristics of the product we need to build for our customers. As these types of documentations process helps us to capture the business of the product that the customers are asking for. As SPMs, if your goal is to capture the “why” there is a need of this product you are building and the “what” you can do to solve those needs, then this documentation approach is “THE” way to start.

Sometimes, functional requirements are also referred as “Business requirements”. And definitely don’t forget to share this document with your customers, as they need to confirm that this is what they want you to build. This document will detail the business end of the software product as well as the “requirements”. The requirements take the form of lists and with the help of UX specialists, you can show the outline on how it will work.

Technical requirements

Technical requirement documents will help to understand the “how” that “what” will be build. Someone with technical perspectives, like a software developer, or engineer, or architect, will need to understand the “what” you want him/her to build. They often don’t want to understand the business criteria of the product. But with their help you will be able to create a step-by-step instruction of the product. This will help you to understand the timeline to build and test the product before you release or hand it over to your customer.

Techies will have discussions with regarding the requirements that you have outlined for them to work on and you will go back-and-forth with which requirements have higher priorities and which have lower priorities, in terms for release planning.

The SRS

You can store both of these requirement documentation in to a singular document called the Software Requirement Specification (SRS) documentation. This will be helpful for the whole project as you can outline the requirements in priorities, from higher to lower, for the release plans. Developers will also be benefited from this document as it contains all.

Additionally, SRS documents can may also include several other software, hardware, stakeholders and interface requirement specification to fully define the baseline’s component. The goal is to provide customers and the developers with a clear understanding of exactly what is intended to go into the upcoming releases. This practice of storing requirements in a solution allows you to maintain an aggregated set of both present and future release commitments.

I’ll finish with WC’s tradition today of stealing and posting a Dilbert strip without feeling any sense of moral turpitude!

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…

A/B Testing the culture of your company

Wouldn’t it be great if you could A/B test the policies that you take for your company just like you A/B test user adoption for your designs? If we could somehow try our decisions out and then take the one that works better it would take the heartache out of a lot of everyday decisions.

Let’s face it, the way we run our companies, and I’m talking about everyone - from the mini startup to the mega corp., is purely a version of gambling. Let me break down some of the common “rationale” for our policies for the company -

Excuses for bad policies:

“That’s the way it’s done everywhere”

And probably that’s why most companies have dismal work cultures.

“If we don’t do this now, things will go out of control”

As if it’s a kindergarten we are running or worse a prison :(

“There must be checks and balances”

Yeah, but when you have to say it out to justify a policy chances are you are forcing something in that’s no check and no balance.

Anyway, you get the picture (and this is just a rant post). Getting back to my point, A/B Testing - most of the times we are never sure if the policy we are putting in place is a good policy that makes the company efficient and makes the people happy (yes, you can have them both!) or if it will just sap the soul out of the people and lead to inefficiencies and backstabbing. Take the classic “Performance Review” the classic “That’s the way it’s done everywhere” thing. Is it good or bad? Without a performance review your best people will not feel they are being prized or valued. But with performance review aren’t you bringing in competitiveness? Particularly in software development doesn’t the best coder in the world go through a patch of really bad performance (which is offset by 10X performance at other times)? There is no solid gold answer - only “buts” and “ifs” and “depends”. btw if I’ve got you riled up here’s a good read from HBR - Why More and More Companies Are Ditching Performance Ratings

So if we just had a simple way of trying out a policy (maybe in part of the company) and trying something different (with another part) and the checking for the results and pick the one that’s better. Anyway without a foolproof system for A/B testing here’s what we do at Kaz whenever we we trying to put a new policy in place or change an existing one:

Have a “feel out” phase

Every policy we adopt goes through a “feel out” phase where it’s discussed formally and informally during team meetings, lunches even hallway discussions. This gives early feedback about the policy, get amazing ideas of what might work and what might not work and works as great PR campaign for the policy.

Introduce incrementally

All policies are introduced very slowly and in parts. This makes it easy for us to find our mistakes and fix them without making a huge mess. It’s amazing how many times we have fallen face in even when the plan sounded great during our feel out.

Seek feedback

This is the important one - seek feedback from the people who are most affected by the change. There might be some very good ideas about tweaks that might work.

Be prepared to change or roll back

Nothing should be set in stone. As long as we achieve the goal we should not bother about how we achieve it. So if something doesn’t work just change it or roll back. Remember that it’s not a prison that you are running and there is absolutely nothing wrong for a company to admit that it was wrong.

Measure company culture

Now this is hard one. If you can’t measure and put numbers on culture you can’t find out if something is working better or making things worse. But it’s not easy and some would say next to impossible. Our thinking is that you don’t really need perfect system (there is none), as long as you have some measure it’s better than none. So a simple poll might be a good way out, or you can go the full Titanium card path and try something like MIT’s sociometrics (MIT being MIT had to come up with device to measure culture):

We wrote a series sometime back on how we do and did things in quantifying culture The method doesn’t matter as long as you have some way of understanding the effects that you policy changes are causing.

But still, we would love a scheme where we could do those A/B tests easily. Maybe MIT will come up with something? :)

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…

3 Questions to define a software product

Imagine you are in charge of creating a clear specification for a new software product. On one side you have your customer - a a high energy, super smart non-techie who flies off in tangents in every discussion yet has the most amazing business idea that needs a web and mobile app. On your other side you have software developers who want a precise software definition that goes over the nitty gritty of what the software needs to do.

What do you do?

Let me go over how we do this with our 3 question approach. This is part 1 in my series on defining software.

Back to the your problem:

How to define a software product?

Every software product we see on the market started from an idea. The idea came from the need. The need presented itself when there is a lacking of carrying out tasks.

This is where the software product management - SPM shines. Understanding the “needs” is the primary goal for any product manager. We use software solutions every day without understanding the true value of it. Mostly because we have it already. There was a time we didn’t have the most basic solution known to mankind, Emails. We can’t imagine that time when it took up to months to send a message, or “mail”, to another person living in a distance.

Then someone asked the question “why?”, the first step to designing a great solution is born with a word. Questioning the limits and vulnerability of the existing solutions. Once it was determined that the existing mail communication is ineffective, the new idea is born.

Then they asked the question “what?”, which is the second most important step to designing any solution. Now knowing the issues with the existing solution, questioning what can be done to improve it will give them more ways to think to replace the existing solution, or system, of communication.

Once they figured out what needed to be done, they asked the question “how?” they can replace the system. The final question to designing any solution, looking for the answers on how to replace the system gave them the access to the tools those were need to create the new solution.

The “why” the “what” and the “how”, the three fundamental questions to defining any products, or solutions. Understanding this paradigm can help any product managers gain confidence for defining products. Product managers’ lives becomes very easy when they understand the answers for these questions. To define a product that you are building, you must go through these questions in step-by-step process.

Understanding the “Why?”

First, the “why” will help you to understand the actual need of the software you are trying to build, for your customers.

The key to understand a product that you are defining, designing and developing, is to understand the need for that product. Without a clear statement of the need if you jump in to the “how” based on some rough ideas on the “why”, it will often result in a product with that don’t address the stakeholders’ requests (no matter how good they look and function well). Most of the time product managers can assume what the customers/stakeholders are talking about when they mention their need but to master it you must start with diving in to details at the beginning of your conversation with them. Ask them why do they need this software/solution, why don’t their current system/process isn’t working, how do they want to their current system/process to function, etc. once you gather the initial needs of your customer, document them to understand their lacking. Investigate the system that they are currently using. Research the answers that you might think is valuable to them and easier for you to design.

The ”why” often usually helps to describe the vision of the product.

OK, the comic strip on the right is just a joke but a really good one, the why should always be aimed at the end user not company that’s profiting from the software!

Awesome “Why?” joke thanks to rstevens

Planning for the “What?”

The next step is to find out “what” can you do to provide a solution (or a product as a solution) for customers to overcome their difficulties. A very good practice is to investigate the process on the Internet and see how many have solved this need. It always helps to learn from your competitors. One bad practice is to jump to the development phase. In this way you may not know for sure, that the solution you have provided to your customers will serve them longer, or they can get any value out of using it, with the tools and technology you used to build the product for the customers. You must be able to plan more than one solution for a single need and try to understand the flaws in them. You can also use the help of UX and other interaction professionals to develop mockups or wireframes to show how concept of the product you need to build.

The “what’ part of the process helps you to capture the requirements, feature specification and milestones.

Deciding the “How”

Now that you know why and what you are doing, you can now jump to code. The third step gets easier when you have finalized what you will be building and why. Now comes the challenge on “how” to build what you have defined. With all the materials, such as business requirements, feature requirements, UX, models, your life becomes more easier to decide on the technology you will be using and design milestones in building the product you defined. This part is where you can race to code to build the product that your customers desire. Developers and architects should be given the freedom to make decisions regarding the implementation process.

In another way of saying, the “how” helps “what” is required to be built.

Concluding

To put a product on the (hypothetical) shelf, product managers have to be very precise in what they define as their product, both for the customers and the engineers. Using the “why”, “what” and “how” approach will help you to achieve that more efficiently and precisely.

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.