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

A Short History of Nearly Everything

By Bill Bryson

Experimentation in nature - Burgess Fossils

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

Burgess Shale Fossils

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

Wonderful Life: The Burgess Shale and the Nature of History

By Stephen Jay Gould

Experimentation in the organization

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

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

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

Why software startups fail?

Did you know that most software startups fail?

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

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

But why do software startups like Kettlebell fail?

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

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

Source: Top 20 reasons startups fail

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

Forgetting the main goal of a software

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

Spending too much too early

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

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

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

Getting a software team that’s not a good fit

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

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

Not having a price for everyone

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

Waiting too long to get the “perfect” first product

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

Not giving enough thought about your UX

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

Jumping in too early

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

— Founder, Vreal

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

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

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

Our top tips for startup product strategy

During the past 16 years (and counting) of our work with hundreds of startups and small businesses we have come across a lot. We’ve seen single students starting with almost no money but amazing skills and dedication make a simple idea become a great success (with a little help from us). We’ve also seen very senior and experienced groups with loads of money with really good software idea fail miserably (and taking us down with them).

Startups represent about half of our everyday business. So they are super important for us and we just love working with them - for the energy and optimism they usually bring, for the quickness in their decisions and the cool technologies they work on. But every new startup we meetup we try to warn them about how difficult the path in front of them are and share our ideas about survival and things we’ve learn works really well for startups. We’ve written about many such tips in the past, here’s a popular one about 5 things that the founder should keep in mind One thing we see a lot is that many startup founders are all over the place about product strategy - how they are going to put up the product, what should they focus on to bring in more customers, etc. Here’s a short list of such strategy advice we share with our customers. These are tips that we know works 100% of the time…
 

Make sure you know the pain point you are solving

Every new technology is (or should be) to solve an existing pain point. If there is no pain to solve, then the new technology and startup that is making it will fail. So first make sure there is a pain point that your solution solves and know it well. That should be the sole focus of everything your software does.

Keep things simple

Your software will be new to users. It’s interface and probably all of it’s features are likely to be alien to every user you manage to acquire. If you don’t keep things simple you’ll lose them fast. Don’t hide your features in complex interfaces with features after features. Show them one thing that you do well (your pain point solution) and only show that. Things like simple UI, obvious CTA buttons, easy to organize dashboards can make or break your software business.

Offer different levels of subscription

Making packages that are modular or subscriptions that offer features that expand upon the base level, allows your software to cover a variety of budgets. You should always, ALWAYS, offer a trial or free level so that the decision for the initial buy is without any barrier.

Offer integration with other applications whenever it makes sense

Your software is not the only thing that your user will use. Your application need to talk with other applications that your user will use. At the very least there should be an export feature of the data. Without the option to integrate or with the fear of locked down with a particular software most new users will decide not to buy.
 

Consider additional services

Always consider if there are any non software services you can include for added value. Things like 24/7 support, or initial customization, or free setup will give you a big leading edge. They sometimes become the reason why customers will take your software instead of your competitor’s.
 

Plan for a great customer service

Ultimately, one thing you know can set you apart from the competition is great customer service. Offering ways to interact with customers, answer questions and guide them to new solutions is a sure way to retain customers, and get new ones via word of mouth. You’d be surprised as to how many startups in out there think of customer service as an after thought (or sometimes not at all) - yet it’s usually the cheapest HR cost in the budgeting.
 

Analytics and data will help you show the right direction

For any new software it’s hard to find out what needs to change to make it better. The hard way to find this out is give it enough time to fail and let your customers complain and leave. A much easier way is to setup data analytics to keep track of the metrics and act on them. Setting up things crash analytics, google analytics for visits, on page statistics are extremely easy and usually takes less than 1% of the full effort of making the software, yet they are extremely important for the survival of the startup at it’s early days.
 

How soon to start coding?

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

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

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

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

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

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

— Elon Musk

Advantages of teaching coding to children

Creativity and logic building

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

Makes a team player

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

Influence to learn more

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

The ability to understand and share

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

Boosting confidence

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

How to teach your child coding

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

Using Toys

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

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

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

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

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

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

Programming languages

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

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

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

Code your own robot

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

— Marc Raibert , ex-CEO BostonDynamics

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

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

The SDK

The SDK is in Python!

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

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

Robots can be rented!

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

SPOT is loaded

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

The first user conference

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

Exciting times!

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 :)