A full year of WFH

Last Friday marked a full year of WFH for Kaz Software. On March 19, 2020 we turned from a zero work from home company to a 100% one.

The WFH move

We were one of the first few companies to move to WFH because of the pandemic. There were a lot of unknowns, both about operations and about the business. There were very valid concerns of performance, our ability to work from home without any experience in managing software projects from home. We mitigated the risks by careful planning, our blog post from that day outlines some of the strategies we took: Adapting to COVID reality and posts from the time we started thinking about the challenges and how to manage the risks are also very interesting to read: 10 Tips for effective work from home, Remote work - what can go wrong? The title itself shows what was going on in our head :)

First two months of WFH

To our great relief we found that the transition from 0% WFH to 100% WFH was almost completely frictionless. Our risk mitigation strategies proved to be very effective. We had almost no hiccups and was hit the ground running from the first day. That is not say that we didn’t have any problem at all, over the first few weeks we started coming across some wrinkles that we ironed out with our planning. We wrote about our experience in the two month mark: WFH - our experience so far We soon learnt that the work environment setup at home needed to be right for better WFH and we resolved that constantly providing tech and facilities support from the office to individual developers at their home. This included supplying them with the chairs, monitors, etc. resolving technical issues on their home computers, if needed supplying them with their work computers and monitors, etc. We also realized that the office cannot be fully closed as access was required on emergency situations - so we had staff (properly isolated) living at or near the office building so that any resource can come over to the office when needed.

One year down

Now we are on our full year of WFH. And we can say with certainty that the WFH model has worked very well for us. We have absolutely no delays or work lapses that was directly because of WFH. We believe we have improved our overall performance by saving time on travel. We do however feel that for a collaborative work of software development a purely WFH model is not right, there is huge value in face to face interactions in software. Our current state is a mixed mode of WFH and work at office. We have made it optional for resources to work at the office if they are vaccinated or if they have taken enough precaution and ensure that they follow the health guidelines. This mixed model of WFH and work at office is proving to be quite successful. As the situation improves with wider vaccination we will see how much of this model we can retain permanently - so I’ll be back with another post about what we are doing!

Bye for now, stay safe!

Software to the rescue

Accidents and natural disasters are facts of life. We never want them to happen but we know they will happen. There isn’t much we can do to stop them. But when they do happen we can take actions that can mitigate the harm. How fast we respond after a disaster man made or nature made is extremely important. It can be the difference between life and death of many.

Software is increasingly playing a significant role in such disaster response. Over the past few years the use of innovative approaches on software on such disasters is proving to be a big factor in reducing the harm and mitigating the effects of such disasters. The use of concepts in technology such as AI, social network, push notification, GPS, crowdsourcing, peer to peer networks, etc. are all being put to use in disaster mitigation solutions. Today’s post is to highlight some that we may have heard of and some that aren’t that famous. But all of them are examples of how human innovations in one space can save lives and improve things in other spaces.

Social Network

The 2015 earthquake in Nepal was one of the deadliest in recent history. As the death toll increased over few days after the 7.8 scale earthquake help in finding and identifying missing people became the biggest challenge. This is where the social network driven platforms came in to the rescue. Google and Facebook deployed network driven, cellphone-based tools to help track victims. Facebook’s Safety Check let users affected by the earthquake to log onto the site and mark themselves as “safe.” At the same time users around the world could use FB to check if their family and friends are in the impacted area. Google’s person finder was deployed to connect people in Nepal with their friends and family around the world. The platform basically provides a massive, open platform to collaboratively track missing persons’ reports. It has been used in the past to help victims of Typhoon Haiyan and after the Boston bombing.

There are other social network driven disaster response/rescue software and apps coming out based on networks like Whatsapp, Snapchat and even Skype. The existing network helps quickly identify the contact network in such situations and makes it possible for the emergency services to jump ahead in the tracking and recording process during a disaster.

Crowdsourced Alert

Disaster response is also taking the advantage of the concept of crowdsourced information. When a disaster can be wholly averted or at least the damage contained by early detection this is an essential concept. Why rely on limited equipment and personnel when the entire population can be utilized for early disaster detection.

The classic example is forest fires. The earlier they are detected the faster they can be contained or at least the damage can be mitigated. Even a few years ago forest fire detection was solely dependent on equipment laid out on possible locations and also on hope of 911 calls. This changed after the major 2019 forest fire in California, which was the most destructive wildfire in the state’s history, burning the entire town of Paradise and killing 86 people. A new platform utilizing the concepts of crowdsourcing was put together called the ALERTWildfire. It is a platform that users use to send and receive real-time images and information. It also leverages instruments, cameras and sensors in California, Nevada, Oregon, Washington and Idaho. This information then published on the ALERTWildfire website. With a platform such as this anyone can be monitoring the wildfire situation by selecting a certain area in any of those five states, and monitoring what’s happening. Hence it essentially magnifies the network of monitoring to potentially millions of individuals instead of a few dozen that were usually doing this job. Crowdsourcing at it’s best.

Information Aggregators and AI

With the huge amount of information available on millions of data sources public and private the possibility of using aggregators to bring the data together and AI to make sense of the data to create alerts and other response actions is huge. A leader in this space is Pacific Disaster Center (PDC). Their publicly available disaster monitoring tool shows in one page everything from floods to droughts, wildfire to pandemic outbreaks and everything in between. This and other tools by PDC has supported the governments and nonprofits worldwide, helping save lives and reduce disaster risk. Built and run out of a research center at the University of Hawaii, they are making new technologies and tools for disaster alert and rescue based on data analytics and AI.

The Purple Cow Tribe in Software

I’m a big fan of Seth Godin (who isn’t?). And one of his best books is the The Purple Cow which has a simple enough story line: you don’t look at ordinary things (the run of the mill black and white cows) you look and talk about remarkable things (the purple cows). So to find success in any business you should aim for the remarkable - and that applies to marketing and it applies to product offering. Couple this idea with his other big idea about tribes laid out in yet another of his best sellers Tribes and you have the magic formula for any software startup success (IMHO).

Purple cow + Tribes = Successful software

Purple Cow: Transform Your Business by Being Remarkable

By Godin, Seth

Tribes: We Need You to Lead Us

By Godin, Seth

The problem

At this day and age we are just inundated with options. Thanks to the ease of digital offerings and the speed of the Internet we are just spoilt for choice. Online food ordering? There’s at least a dozen in your neighbourhood, buying clothes online? you probably have a hundred that’s just a click away. This list is endless. So if you are to bring out a new product in this mix, you are lost immediately in the noise. You don’t stand a chance. It’s extremely difficult to get noticed and even harder to get people to pay you for your software products. Free is the norm. Consumers expect almost everything digital to be easy, free and perfect.

In this crazy state of things you cannot make a product that’s ordinary and still make it big. But on the other hand it’s extremely difficult (or expensive or both) to make a unique remarkable product.

So how what do you do?

The solution using Seth’s two idea is to make something that would appeal to only a small group of people. Your software would be useless for 99% of the consumers but maybe 1% would find it super useful. Sounds counter-intuitive, but that’s how things are - if you tried to make a software that would appeal to 99% of consumers you’d either have to make it over the top complicated to appeal to different people’s needs or make it so useless that no one finds it worth the time. So going back to the idea, you make something that’s super useful for 1% - and then that 1% starts talking about your software, they would find it remarkable and they would become your “super fans”. You would then create a tribe. A tribe of people who relates to your software and would keep coming back to it.

What do you think? Not convinced? Read the book or at least check out some of Seth’s many videos and see if those change your mind.

Freemium model for software sales

Monetization of a software product is key focus for any software company. The big question is “how?”. Gone are the days when you could make a software, burn it into a CD and sell the CD for a price - making the intangible tangible. It was great while it lasted, as it was an easy concept to comprehend, consumers are used to buying a product that they can hold or touch. A CD would give them that feel and then installing the software just felt like part of setting up the tangible product. In the mental model of consumers the CD was the product.

CDs don’t make sense anymore. Even downloads and installs are outdated. Consumers expect software to be online and ready to go and worst of all “free”. Can you imagine paying for a basic email service? The likes of gmail, yahoo and hotmail has destroyed the concept that you have to pay for a thing like an email. So the direct “here is your product give me the money” days are out. What’s come in are new and innovative ways of selling software services. Freemium is one such model that has gained grounds as the main model these days for monetizing software products.

What is Freemium?

Freemium model is a process where users get basic features of a software for free and can access special or upgraded features for a subscription fee. The “FREE” part attracts users to the software, so it is essentially a marketing spend for the software company and the “premium” part of the freemium word is the part that actually gets the software company the money. Most of the services around us are essentially one form or another of freemium e.g. networking with LinkedIn, shared files through Dropbox even emailing with gmail are all freemium models in action. “Gmail?” you say, that’s not freemium, but it is. As soon as you reach their limit on storage (which I promise you will reach one day) you get this:

Which eventually lead you to this:

Why Freemium?

Several things make freemium the perfect model for selling software. Free features are a powerful marketing tool, essentially an immersive advertisement for your software that draws customers in. The model is great because it allows a new software company to scale up and attract a user base without using resources on costly ad campaigns or a traditional sales force. Under a freemium, a software gives away a service, that obviously costs money for a company, at no cost to the consumer as a way to establish the foundation for future payments. So in essence it can be thought of as deferred payment. By offering basic-level services for free, companies build relationships with customers, eventually ensuring payment from them for advanced services, add-ons, enhanced storage or usage limits, or an ad-free user experience. It’s a great win-win. Companies win because they can get customers onboard easily without huge marketing spend, and customers win because they get to use the software before buying.

Does it work?

Definitely. That’s the sole reason for it’s wide adoption. If you want to look at results do a search on google and you’ll probably find a thousand sites that prove that it’s a working business model. Dropbox is a great example. When it launched, in 2008, it was mainly a service for backing up files. It then began offering shared folders, making it a collaboration tool. Newer features allow for automatic syncing of smartphones and other devices and for automatic uploading of photos. Over time the user interface has improved as well. Each new feature has increased the value of the premium offering. And in their 2018 filing they showed that they had more than 500 million free users and they were earning more than $1 billion in revenue!

As consumers ourselves we would also agree that freemium is a great model for software. It lets us explore a software without making financial commitments right away. It let’s us compare multiple services and select the best one. So if you are thinking of software monetization think of the freemium model before you consider anything else.

Software reality: Multiple ways of solving the same problem

If you learn one thing in software after spending your entire working life in it, it is:

There is no single answer to any problem

It is something you find out over and over in your software career. Any software solution you are working on, from a simple algorithm to creating an architecture for a large enterprise platform - you’ll find that there at least a few if not hundred ways to solve the problem. And the funny thing is that every one of those ways are good in some aspect and bad in others. Your job as software practitioner is to come up with “A Solution” by considering a few alternatives and hope for the best. But it’s super important to come up with a solution though, many a times I’ve found that a team gets so tied up with considering various alternatives, fighting it out with each other to decide what is good or bad in each of those alternatives that they run out of time or just can’t decide at all - and this is the biggest software development disease of all time: the dreaded :

“Analysis Paralysis” of software death.

Today’s post is little journey on the tips and tricks of avoiding the analysis paralysis picked up from decades in treating this dreaded disease.

Ego is the biggest problem in software

If you want a single rule, this is the one: don’t take it personally.

Don’t feel that anyone in your team is attacking you directly, as a person. You are a professional and it’s your job to voice out your concerns and find solutions. That’s what you do. It’s not about you, it’s about finding that solution.

If you try to defend your ideas just for the sake of being right, you will always lose as a professional. That is not the goal. Your ego is not what needs to be maintained. Being a developer is a concrete job where you have to create value. Therefore, you (and your ego), personally, are out of the equation.

It’s easy to see if you argue for the sake of being right or if you don’t: just listen to you arguments. If they feel weak, stop the discussion and try to find good arguments to defend your ideas if it’s worth defending. Never think about being wrong as something negative.

Has anyone solved this already?

You’ll find that most software problems are already solved by someone somewhere. You are just a google search away from finding those examples and trying to fit that solution to yours. In most cases you’ll not only find the solution but also the effect of implementing that solution. Stackoverflow threads will usually overtime build up on people who have tried something, worked or failed. Reading through such threads will save you from a lot of pain, and save you time and money.

“In my view the Gang of Four is the best book ever written on object-oriented design - possibly of any style of design.”

— Martin Fowler

Design Patterns: Elements of Reusable Object-Oriented Software

By Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

When you defend an idea, find examples, or suggestions by authorities, quote somebody who agrees with you. Authorities are great, a big name like Martin Fowler can easily solve a stalemate situation in a software paralysis situation. More examples you have the stronger your argumentation will be. It’s not your ideas against somebody else’s anymore, it’s influencer’s proven-to-be-right-ideas against ideas with less weight.

The must in this authority or example world are design patterns. Read, re-read, memorize GOF’s book there is nothing as final in a software discussion than a design pattern number or name from GOF.

Use Data

If you have some kind of data to prove your point or support your idea always use it. Don’t hesitate to use statistical data, survey results and scientific studies. You’d be surprised how much data is available about systems and practices in software. For example, even how productivity of software developers get better or worse by their table and sitting positions has got scientific data to support a certain way of layouts.

You’ll find loads of data and survey done by universities on correct software architecture, or algorithm or even productivity of developers. Use such data to support your thesis, to drive your solution home. When you have data on your side, from a reputable source it’s easy to come to a decision for the team and you get the whole team out from the analysis paralysis world.

Use Your experience

It is always OK to use your own experience to support a logic. But remember that it needs to be honest and without any ego. If you don’t have any concrete example or scientific data to support your suggestion, you can speak about your own experiences. Make sure you are very precise for people to connect your experience with the problem in hand. More connection you can draw between the experience you are relating and the present context the more effective you will be.

A team like stories. If you have a good one to share that goes over your experience and that your team will relate to, then use it. Trying to stay clear and using logic to explain how your experience relates to the solution of the current problem is key.

Stay open minded

No team can find the perfect solution to a problem just because there is no such thing as perfect solution. So keeping an open mind is crucial for finding the best fit solution. Even if the team reaches a conclusion, and obviously if they haven’t keep the options open for further testing and checking of the suggested solution. Here are some of the things that you can do to keep things flexible and to test out the solution you agreed on (but always a bit skeptical about):

• If you can create a low cost prototype to test some functionalities or to test if it does indeed work. A quick test project can solve an analysis paralysis decision easily.

• If possible run low cost A/B testing to see which of the multiple solution is a better option. Get two opposing groups to come up with low cost tests to prove or disprove things.

• Run surveys to check your theory. Ask customers if they agree with what your proposing, or if it’s too technical ask other software developers or teams.

Software that looks at animal footprints

Software is everywhere. Our lives are run by software these days, from the very moment we get woken up by the alarm on our mobile to the time we go to sleep listening to music playing on some software. So it’s hard to surprise we with yet another new take on the uses of software, but a recent read about a new way of tracking animals caught me off guard.

Called footprint-identification system (FIT) these systems analyze the picture of an animal’s footprint to find identifying marks, uses a global database of such marks to pinpoint animals, their age, sex and other properties.

The idea came from working with local trackers in Zimbabwe. These footprint reading experts can look at footprint on the mud and actually identify an individual animal. This led Sky Alibhai, co-founder of WildTrack to come up with a software solution that utilizes the strategies of the indigenous trackers by leveraging the AI and data crunching abilities of a software system. The working system WildTrack is now operational and is being used by scientists to track Rhinos and keep them safe from poachers who kill them (did you know that as recent as 1960 there were more than 100,000 black rhinos and yet by 1995 that got to less than 2,500?).

To use the system, scientists gather rhino footprint images with their smartphones and then use an app on the phone to upload the pictures to the serverside system. The FIT software on the serverside then processes that picture, compares it against it’s large database of pictures to identify the individual animal and store it’s current location and other geographic data that comes from the smartphone app.

What an amazing innovation, check it out at: How the FIT works

Digital Medicine

2020 and COVID has taught us that we need to be more adaptive and creative with technology. One of the obvious extension of our existing technology was to use it for virtual doctor visits. The core technology for virtual meetings has been around for decades (fun fact: the first working video conference call technology came in 1936) but the consistent and planned use of the technology for medical services has always been very spotty. Telemedicine as concept usually went towards providing only specialist medicine rather than everyday doctor’s appointments. COVID pushed it that way, and more and more we see all kinds of doctor visits are being pushed towards possible virtual visits whether it be with full on video conferences or be through mobile apps that connect patients with doctors or medical care givers.

But apart from this push towards adoption of existing technology for use towards medical visits there is a significant new trend of new software and devices that can provide medical diagnosis, advice, therapy and treatment. This is the new generation of software platforms that will most likely be the new frontier - both for software space and medicine.

Collectively termed “digital medicine” - these innovative platforms leverages mobile devices to record data such as users hear rate, electrolytic conditions of user’s skin or sweat, facial expressions, exercise, sleep, even texting activity and apply artificial intelligence on the data to flag possible onset of conditions or facilitate treatment. Some smart watches (apple watch being the leader in this space) has been putting in all kinds of sensors and opening up the data for those sensors so that app developers can develop innovative apps from heart attack alerts to health monitoring. In recent times this space is heating up with a new generation of platforms that go beyond simple heart rate monitoring. Let me go over some early stars in this space.

The first FDA approved digital therapeutic is reSET which is described as Prescription Digital Therapeutic (PDT) for Substance Use Disorder (SUD) intended to provide cognitive behavioral therapy (CBT). It gives clinicians real-time data on their patients’ cravings and triggers. Also from the same company is Somryst the first and only prescription digital therapeutic indicated to treat chronic insomnia. Somryst is intended to improve insomnia symptoms by providing neurobehavioral intervention (cognitive behavioral therapy for insomnia – CBT-I) to adults 22 years of age and older with chronic insomnia. EndeavorRX is a video game based therapy platform for children with attention deficit hyperactivity disorder. This one is also FDA approved and operational. All these platforms are administering therapy and treatment that even a few years ago would only be administered by doctors and nurses taking up time and effort and obviously were expensive to run.

Another rising star in this new generation is the health startup Odin one of their successful product is a product called Hemoflow, which is a non-invasive device that helps doctors save lives by providing real time and trending blood flow monitoring of injured limbs. It is placed on the injured limb at the ankle or wrist. Light emitters & detectors are used to collect 32 data points a second. The data is then used by the software with artificial intelligence capabilities to determine the blood flow characteristics in the limb. The data can be shown in realtime on mobile apps and other devices and transmitted online.

Another interesting thing to note that the digital medicine space is not only for new startups. Old hands like Microsoft is making huge strides in this space too. Azure Health Bot is a fully functional cloud service that M$ is running and it has played an important role during the pandemic with governments and hospitals leveraging it’s features. It is fully customizable and programmable (as you’d expect!) thus it opens up the possibility of innovation in this space without reinventing the wheel every time.

Another technology that is fast reaching release ready are wearable stickers that monitor health conditions. One of the leaders in this space is BodyNet which coming from a Stanford lab but is industry ready. An early start on this was from a tech called AmpStrip which won a CES award in 2015 but suddenly went secretive to pivot into something else (which isn’t out yet). There are others popping up all around based on this skin level sticker technology that then connects to a device via AR.

Multicloud - the big trend of 2021

Cloud is everything. There is no question about it. In 2021 no sane software platform can be made without thinking of using some kind of cloud infrastructure. Cloud opens up the infinite opportunities of scalability without the infinite need for time, effort and resources. Cloud only approach was an obvious technical eventuality that the world was heading to anyway but the 2020 pandemic made sure that it happened fast and there were no turning back.

However there is a dark cloud (couldn’t resist it :) ) in this cloudy future - vendor lockdown and single point of failure.

OK, the single point of failure would have been laughed at by the proponents of the cloud as it is one of the big the selling point for all cloud strategies that they are distributed and are NOT a single point of failure architecture but Google’s blackout in the middle of December 2020 (to cap off a very strange year) makes it a bit harder to laugh these days. A single outage by a single “cloud“ probably took down more than half of the entire world’s workforce. Dependency on a single vendor is always bad, and it doesn’t matter if that single vendor is one of the world richest company or the world’s ex- “don’t be evil” company.

This is where the multi in the multicloud buzzword comes in. Simply put it’s a strategy to use multiple independent cloud platforms so that you are not dependent on any single all powerful platform. AWS owns the cloud space by 32% market share but that doesn’t mean AWS is the only show in town. Microsoft is and Google is making it’s mark with 19% and 7% market share and the new kid on the block is Alibaba Cloud which is predicted to come behind Google as the 4th big player. Apart from these major players there already exists a whole ecosystem of smaller players and private clouds. So there is absolutely no reason to be dependent solely on a single cloud and be their slave forever. This is reflected in smart decision of multicloud strategies that companies are now starting to take - the recent big one was CIA with their multi-billion dollar multicloud strategy.

Even the great AWS is starting to realize that multicloud is the way forward and not accepting it and not having interoperability with other clouds may lead to them being like Microsoft on their old desktop strategy a long time back. This was reflected when AWS quietly joined the multicloud movement - The Information reported in October 2020 with AWS planning a multicloud service during re:Invent. ECS Anywhere and EKS Anywhere coming this year is a definite step towards the multicloud space that AWS is being forced to take.

A quote from someone inside AWS says it all:

"AWS realizes that they are not the be-all and end-all in the cloud. They are pushing hard to make sure they can manage services across cloud providers,"

So the giant is accepting the truth! Better late than never…

MS and Google has always been very interested about multicloud probably because they realized how late they got into this cloud business and most companies of the world probably already have some kind of AWS relationship anyway. Azure Arc is their future planning laid bare and Google Cloud's Anthos product, is the other giant’s way of accepting multicloud.

Multicloud is here to stay. So follow this trend closely. We’ll keep you posted too.

Making your software: Step 3 - Ball Park Estimates

Priya, our fictional software entrepreneur from the previous chapters on this series has a dream to make “Designly” a software platform for interior designs. She has followed our suggestions on writing down her features in the specific format that software developers love as step 1 in her journey to make her software. She has then gone through the methodical approach of finding possible software developers using a simple yet effective process using the method laid out in step 2 - find software developer She now has a shortlisted software developers who are likely to be a good fit in terms of skills, capability and communication. Now is the big question of money,

“How much will it cost?”

But costing a software development project is not as simple as just saying oh these are the materials, this is how much it will be. That is because there are a multitude of unknowns in a software project. If you take Priya’s situation you’ll know what I mean. She only has an idea of software and some features. Roughly she is looking for a software that will:

a) Let users try out interior design in their room.

b) Take pictures of those designs and ask for feedback from friends and family.

But is that all? If you dig even a little bit further a hundred new features starts coming up that are essential. For example:

c) users will need registration, password management, trial access, etc.

d) there will be a need for a payments

e) priya will need administration interface for managing her users and also for stats.

f) ….

And we haven’t really even scratched the surface yet. For example, how does a user do the first feature of trying out interior design? Will there be little furniture pictures that users will be able to arrange? Will the user have ability to change colors of the walls and furniture? Will there be a library of furniture pictures? …

Each of these questions and their answers lead to features and work which leads to change in the cost. The actual requirement analysis is by itself a big part of the software development work and it takes time and effort to do. So for any sane software company it just doesn’t make sense to go through the whole process without getting paid or without some assurance of getting the full project. But on the other side Priya needs to have at least a rough idea about the costing of the project - will it be a few thousand or a few hundred thousand? And the answer to this predicament is

The ballpark estimate

An estimate that can be wrong in the actual number when all the requirement is done and dusted but which is at least in the same order of magnitude. So it’s like a software developer saying “hey, Priya, your software will cost something around 50K” and the actual final cost might be 80K, but it wouldn’t be 500K for example.

For any software company with experience and skill, coming up with a ball park is relatively easy. It will probably require some effort - maybe a day or two (and even a week) of going over what’s known and trying to guess the effort. But it’s far better than spending weeks on scoping and estimation work without knowing for sure if the project will be awarded to them or not.

So most software companies are OK in the little investment of coming up with a ball park number.

The art of estimating the ballpark number

Ballpark numbers are very rough cost estimates based on the specification you give to the developers. This number helps you figure out costs and plan your funds. To get a reliable ballpark you’ll need to spend some time with the developer to go through your concept, answer their questions etc. And obviously you can only do that with only a few.

Most software companies will guide you through the ballpark estimation process by asking questions. But from your side you need to take some action too to make sure that the right questions are asked and that certain concepts are clear to the software developers. Here’s our list questions that we make sure we ask and clarify:

• What is the closest thing like your software currently available? Can you give us a link?

• Do you have any preference on colors and themes? Can you give us an example site/app?

• Where do you expect your users to use the software the most - on their browsers or their mobile devices?

• Do you want a mobile app too? If so do you want them on both iOS and Android? Why?

• Tell us in your own words how your users will use the software.

• Tell us in your own words how you expect to manage the software, users, accounting, etc.

• Tell us about your potential users. Would your users be computer savvy? Would they have good internet connections? Would they have good devices?

• What would be the language preference of your users? Do you expect your software to be multi-lingual?

• What’s your “drop dead” deadline? When do you need your software by to survive as a business?

• If you were to choose just one feature, what would be that feature?

• Going forward what is your expected cost of maintaining the software?

• Who is going to maintain the software? What sort of skills does she have?

Looking out for a brave new world

2020 was a strange year.

It was a horror movie that ran in slow motion and was in permanent automatic loop. We’ve lost so many around us and we have lost our faith in so many things, in just one year. A single year has shown us how helpless we are to nature’s whims, how fragile is our system of knowledge and skills, how thin is our veneer of social propriety. Yet, beyond all these and many other darkness, a clear and bright light has also shone throughout the year. The light of human resilience, of human bonding and of human ingenuity. We’ve proven that together we can win. We’ve proven that we can take on calamities and adapt in a multitude of ways and survive. And we have several vaccines out before the end of year and we are once again standing our ground.

For us at Kaz, the greatest win was the adaption to working from home. We made the jump early on in March, and haven’t missed a single beat in our stride by doing so. On the very first day we were up and running with our project, as if nothing was any different - yet we were working, for the first time, completely remotely. By the first few days we had ironed out the wrinkles, our systems and facilities team working round the clock supplying everyone with computers, monitors, devices and even chairs. Within the first week we were confident enough to say that there would be no delays in any of our project deadlines. And there hasn’t been any because of the virus. This to me is a huge win. It shows that our way of working is the right way. It shows the focus that Kaz has on team building and culture helps create a company that is resilient, strong at its core, with its bonds running deep and its ability to evolve and adapt very agile. It assures me that we are on the right path. Our way of running a software company is the way towards a resilient and happy company.

This is what I want to take to 2021. As we find ourselves back, as we stand tall as before, as we become the way we were, I want to say out loud that we faced the pandemic with a brave face, we took the right decisions and we survived.

May the new year bring us back to safety, to freedom and to the old normal. May the new year refresh us and bring us a brave new world. Happy New Year.

Data privacy regulations 101

Data privacy is obviously very important. With large companies gather huge amount of data of it’s users and with the great advancement on data mining and data analytics technologies data privacy has become one of the biggest concerns for all consumers. If you are not that concerned about this, you should be, here’s a quick read to get your concern raised - a quick survey of what data FB or google already has about you.

This concern is reflected by the various regulatory bodies and governments stepping up their regulations about what companies can do with the data, how they can share it and how they have protect it.

The problem is that the online world has not autocracy! And in those rare cases in this world where autocracies are great this is one place all software creators wish there was one single autocratic power giving out a single set of rules to abide by :) Sadly that’s not the case and a software developer that wants to serve customers around the world (i.e. every software company in the world) now has to understand a plethora of data privacy rules and regulations, create interfaces for seeking consent, show text for displaying warnings, create processes for managing the security and the privacy. This is why every website we visit today has a confusing range of popups, highlights, texts, footers and headers asking us to accept this or decline that or warn us that we will lose our soul if we don’t do this or that. In general, all this chaos has just created a fatigue in the consumers who just click accept where ever they see it just to get to the page. But that is another story.

Today’s post is for the software developers and software founders who wants to get a quick overview of where things stand now and how to navigate in this jungle.

HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) is a Privacy, Security, and Breach Notification Rules protect the privacy and security of health information and provide individuals with certain rights to their health information.

If your software has anything to do with healthcare, medical services even pharmaceuticals and drugs you should be concerned about HIPPA compliance. It’s a US standard but complying with this basically ensures that you comply with any of the national rules you are likely to encounter in other countries.

Software developers play a vital role in protecting the privacy and security of patient information that comes in through thousands of software systems and interfaces in an increasingly digitalized healthcare world.

At its core HIPAA is pretty simple and based on the following 3 parts:

• Privacy

  This deals with protection, authorization and access. It sets rules for when and how any personal health information can be disclosed and used. It also gives users the ownership of their health records, the right to access them and request modifications as needed.

  So any system you develop needs to have the flexibility and security built on top of the data store.

• Security

  This is the obvious section on the standards for the security of technology used to access, store, transmit, or process any personal health information. This part is the big thing that you as the software developer need to focus on. Certain implementation specifications are either required, meaning that its mandatory to build them in your software, and some are addressable. Addressable are ones in which either you need to 1) implement the specifics as written, OR 2) implement an alternative solution, OR 3) not implement anything for that specific requirements because it is not reasonable or necessary to do so. As with most things in HIPAA, the important thing is that decisions related to addressable specifications are documented.

• Simplified Process

  This part relates to the accepted coding for data exchanged in healthcare. The transactions this applies to are financial related (claims, eligibility, enrollment, etc). To comply with this part you have to make it administratively easier to exchange data by not having to keep track of an endless number of code sets. (What’s a code set?)

GLBA

The Gramm-Leach-Bliley Act (GLBA) is a US law for control on personal financial data managed by financial institutions, and how these institutions deal with a consumer’s non-public personal information (NPI). There is a lot of very private personal financial data that organizations like banks, insurance companies etc. collect when providing a financial product or service and GLBA is the overarching rule that gives users protection on the use of that data.

If you have anything to do with a fintech app or any platform that is used by a bank or an insurance company it’s very likely you’d need to know about GLBA and comply with the it’s guidance.

From a bird’s eye level GLBA has three main parts:

• Privacy Rule

  This regulates the collection and use of NPI. This is the part you as the software developer need to focus the most. It’s pretty comprehensive and there are lots and lots of issues that you have address in this area - so you’ll need to spend time in getting to know the rules. Wikipedia article on the privacy rule does a good job in getting you a quick background.

• The Safeguards Rule

  This part requires financial institutions to implement a security program to protect NPI. So this more on the side of the institutions and their network but doesn’t stop just at physical security so intelligent monitoring of data and transactions is something software developers will probably need to integrate with other solutions within the infrastructure.

• Pretexting provisions

  This prohibits access to NPI under false pretense and is more of a legal concern for the organization and it’s workflow processes. As a software developer you will need to ensure access control and several layers of authorization and monitoring of access.

COPPA

Children's Online Privacy Protection Act (COPPA) is a set of rules that prohibits online software such as websites, apps and games from collecting personal information from children without first providing notice to parents and obtaining their consent. The rule also provides parents with the right to find out about stored data collected from or about their children, and to refuse further data collection and use.

If you are building any software that is primarily directed towards children then you need to be aware about COPPA. Although a US rule it is a rule that was used by most national rules to create their own children protection acts. COPPA is super important for game developers particularly for mobile games - as any failure may lead to a permanent ban from platforms such as apple appstore or google play. Here’s a great primar for game developers

If you didn’t know the story, a recent example where COPPA non compliance led to a big fine was Tiktok, which was fined $5,700,000 in February 2020

Here’s a bird’s eye view of different parts of COPPA you need to be aware of:

• Privacy Policy

  You need a clear and detailed privacy policy and it must be linked clearly on highly visible location within your application, especially where personal information is collected. The privacy policy need to include all information you collect from children, details about how such which the information is used, and whether it is shared with any third parties. You must also reveal the names and addresses of the owners of the software so that may be contacted by parents.

• Parent Opt in

  You need to provide parents of the child user with a message and obtain their consent before using personal information of their child. You need to tell parents that you collected information about their children, describe the information, explain what manner it may be disclosed, and that parental consent is required to do so, and also provide a link to your privacy policy, provide a way to give consent, and let them know you will delete their information if you do not receive their consent.

• Disclosure to Third Parties

  If any information collected by the software will be disclosed to others, you will need to provide a stronger method for consent, such as a signed form, or a contact number. After giving consent, parents must have access to the data for reviewing and deleting their child’s information.

SOX

Sarbanes-Oxley Act (SOX) is a set of regulations that sets the compliance needs and deadlines for public companies. SOX came out necessity when corporate America was broiled with scandals from giants like Enron, WorldCom, and Tyco. The regulation protects the general public and shareholders from accounting errors, fraud in enterprises, and it helps to improve the accuracy of corporate disclosures.

SOX is a big responsibility for public companies but for software developers there is a need to understand the basics so that the systems they build and more importantly the process they follow comply with SOX. If you are employed by a public company in US you should be aware of SOX and as with the other regulations complying with SOX probably means you comply with other national rules modelled around SOX. One of the most important thing for software developers for this regulation is that a software developer should not have any kind of write access to production systems that can affect the financial reporting of the corporation. This is not always easy to comply with and you require a proper process which separates roles of development from system administration to achieve this.

Remember SOX precludes software developers from administrating of systems they write.

Here are some of the main areas of SOX that you should know about:

• Responsibility

  Top management is directly responsible for the accuracy, documentation, and submission of all financial reports. CEOs and CFOs risk imprisonment and penalties for failures. Phew… it’s all on the bosses here unless you are one of them :)

• Internal Control

  Adequate internal control structure for their financial records. Any shortcomings must be reported up the chain as quickly as possible for transparency. As a software project lead your responsibility will be to identify lapses or possible gaps in the reporting structure for software failure.

• Data security policies

  Policies for data security and consistent enforcement of those policies is the key requirement. Companies need to develop and implement a comprehensive data security strategy.

• Independent Audit

  Companies need to maintain and provide documentation proving they are compliant and that they are continuously monitoring and measuring compliance for independent audit. This is where the software developers get involved a lot, as they are the ones that have to build audit logs, configurations, versioned histories of data, etc. required to comply.

GDPR

This is the big one, specially because of wide adoption and the fact that it’s recent. The General Data Protection Regulation (GDPR), agreed upon by the European Parliament is a European Union law that creates new rules for companies that offer goods and services to or that collect and analyze data tied to citizens of the European Union.

As EU citizens are a sizable portion of any application available online (which is every app out there) you as a software developer will need to comply with this rule. It’s pretty detailed and has all sorts of side rules to satisfy the multiple national rules within EU. As a developer you probably don’t need to know all the details to it’s fullest but here are some that you should be concerned with.

• Consent

  GDPR requires that all software you write seeks consent from the user before collecting any information. An explicit consent by statement or action signifying agreement to the processing of their personal data needs to be clearly laid out to the users. Remember that data here is wide enough to cover even cookies (and hence all those “accept cookies” forms we see these days).
  
  

• Access control

  This gives the right to the user to have access to the data that is stored in any organization. As a developer this has the huge implication of making it flexible to access data even historical ones when the user requires it.
  
  

• Data Portability

  This requires the organization in control of the data to provide the data in a format that allows for easy use with another controller. As a developer this boils down to following standard data exchange formats

• Right to be Forgotten

  This entitles the users to have the a company erase his/her personal data, cease further dissemination of the data, and potentially have third parties cease processing of the data. And for the software developer this means creating interfaces and technology that makes this possible. One huge concern for the software people in this space is that a delete essentially mean a full delete from everywhere - including historical files, backups, shadow copies, the full works.
  
  

CCPA

This is the new kid on the block and as such is becoming the new thing that every software developer is getting worried about.

California Consumer Privacy Act. (CCPA) went into effect on January 1, 2020, with a six-month grace period for companies, giving them time to comply. If a company doesn’t comply, Californians can file private lawsuits pursuing civil penalties for violations. And as California owns the software world every software company in the world are reading CCPA carefully!

For software developers the good news is that if you are covering GDPR many of the issues on CCPA is also covered, although not perfectly. So you’ll still need to double check. Here’s a great article that compares these two: GDPR vs. CCPA here’s a screen grab from there comparing them:

Software team structures

A common question we get asked by new companies in our field is:

What’s the best team structure in a software company?

Our answer to this question had been an easy one: “as flat as possible” meaning a structure where there are that many levels - ideally no middle managers just the software developers or other technical roles reporting directly to the team lead who barely ever needs to report to anyone above.

This is a great answer. It takes away the biggest problems in software development companies and introduces creativity, ownership and most importantly collaboration. But this answer is by itself not good enough. As a company grows, as it takes in more and more projects requiring larger number of teams which then collaborates with each other the flatness that gave all the flexibilities in a smaller organization starts to introduce confusion and chaos. So some more structure is needed. What that ideal structure might be is a question that’s very specific to the nature of the company in question and the culture that it embraces. For us at Kaz it’s been moving towards more independently operating teams that operate under groups or wings of technology. We call them companies under companies under companies. This may not work for everyone. Today let’s go over some common software roles we hear about and try coming up with generalized views about what those roles are supposed to do. This might give us some ideas about what roles our own companies might require and where to fit them.

Common Software Roles

Some of the common software roles we see in the industry worldwide are as follows:

Chief Technical Officer (CTO)

CTO is a confusing role, it’s a role that requires purely technical skills most of the time but sometimes it needs to be as non-technical as can be. At startups, the CTO is often a technical cofounder and that role is all about jumping into coding and jumping out to join a marketing meeting. But the same CTO role is a large organizations is very different. A CTO at such an organization is mostly outward facing - looking at clients, product and marketing teams and giving a voice to technical angle on all business conversations. Rarely does a CTO at large organization ever dive into the code or even participates in technical architecture. They participate in business development meetings, frequently helping to land large partnerships or sales. Many spend a lot of time evangelizing the development activities of the organization to the wider world: sharing the company’s innovations and discovering opportunities in the market which match up well with the company’s core competencies.

VP of Engineering or Director of Engineering

The Director of engineering’s role is what most people usually think of CTO’s role. This role is frequently responsible for building the engineering team, creating work process of the technical team and establishing the engineering culture and operations. While CTOs often face outwards - towards business and clients, the Director of Engineering faces inward - towards the technical workforce, their daily needs.

The best directors of Engineering constantly monitor the team’s progress, process and culture. She encourages the technical staff to use the right tools, the right platforms, even the right programming libraries. She may have strong views about how the teams should operation, how the meetings should be run, hold specific kinds of meetings at specific times in order to foster better collaboration with fewer interruptions.

In smaller organization it doesn’t makes sense to increase hierarchy by having separate CTO and director of technology. These two roles can easily be fused together in such organizations but as soon as business starts to expand this is one role that needs to split first.

Chief Architect & Software Architect

The architects in a software organization are usually the uber geeks. They are the super star programmers who never wants to be in any kind of management role and want to stay as close to coding as possible. In small organizations, the chief architect is sometimes the technical co-founder who knows that she never wants the responsibilities of a CTO as the company grows. They are just not interested to take all the hassles of customer facing, project facing, investor facing and team management facing responsibilities that comes with the CTO or even the director of engineering roles.

The architect is the person responsible for selecting technology stacks, planning technical solutions, designing collaborations and interfaces between systems, etc. As the company matures, the chief architect may also need to work closely with the CTO and at many companies, the CTO also serves as the chief architect.

Project Manager

This is the big difficult role. Sometimes this is the role that everyone in company is looking at. In most companies this is the role where a technical staff decides the future of her career - does she want to stay in development and aim for architect roles or does she want to go more towards management roles.

A project manger is in charge of managing the workflow of an engineering team. She interfaces with both product leaders and an engineering leader such as director of Engineering or the CTO to manage the work backlogs, monitor the progress of tasks, create detailed progress reports, track milestone, manage burn down charts, etc. In smaller companies the project manager is the multi-hatted role of a director of technology and team lead.

Technical Lead/Team Lead

The Team Lead is the leader of a small number of technical staff that forms a particular team in the project’s workflow. Typically a team lead is a senior engineer who takes on the role of mentors and guides for the rest of the team. Usually, developers report to a team lead who then reports to the project manager to give a summary of what his team is doing. The team lead is usually coding all the time and the team lead role is a more a part-time role she has to take up when the time comes. In some companies she may be responsible for the team’s code quality, code reviews and managing the team’s output standards.

Various software engineering roles

At the team level are the real workers in a software company - the people who really make it all happen. Based on different levels of experience you have some of the following roles.

• Principal Software Engineer

• Senior Software Engineer

• Software Engineer/Developer

• Junior Software Engineer/Developer

• Trainee Software Engineer/Developer

These are the people who gets things done, who write the code according to spec, fix bugs and creates solutions to problems.

So these are some of the basic roles. But what happens when we look at the giants like MS or Google? With technical teams that are size of small towns obviously having just few levels in the roles isn’t enough. So for Software Development Engineering (SDE) roles there are hierarchies and more levels and structure. Just to get a glimpse, I’ll close it up today with a comparison of the software roles at our 3 giant friend’s.

Introducing new features in your released software

Imagine this: you have released your software. As with any software releases, you had cut corners, last minute compromises had to be made, features had to go out without all the bell and whistles, etc. Yet, you users loved the software, and they have started to use it. As you start getting new users, you are also starting to get requests for features you had compromised on during the release. And people are complaining a bit about the UX, there were things you had thought made sense but it’s not so obvious for your users. You now realize that you have to update your software with a new version.

The good news is that it’s a web app, so updating is just releasing a new version overnight, making sure people’s data isn’t lost and you are done. But the bad news is that your UX fixes and new features mean you’ll need to revamp how the software will be used and the interface is likely to be completely redone. It’s bad news because you know that some people will get confused with your new UI because they’ve learnt your current interface and are using it.

What do you do?

Here are some strategies that we’ve been advising our clients with and they come from working on hundreds of app releases and update.

Release often, but only at the start

“Be agile; release early; release often.” that’s the the drill. But it is strategically wise to keep rolling out features only at the beginning of a product roll out when you don’t have that many users. When your product reaches a certain size, a certain number of users, you don’t want to risk the integrity of your application with every new minor release. The worst thing that can happen to your product is that loyal users, customers who have been using that one little feature consistently over the years, suddenly aren’t able to use it in the same convenient way. The change might empower users more, but the experience becomes less straightforward. Frustration and anxiety enter social media quickly and suddenly, and the pressure on customer support to respond meaningfully and in time increases with every minute. Of course, we don’t want to roll out new features only to realize that they actually hurt loyal users.

So the plan should be:

Release early, release often only at the beginning of product’s life

Announce the release

You should have a list of its current users. Use that list to communicate that changes are coming so people are prepared. Plan on sending an email announcement, explaining your new upcoming plans, with dates and list of feature changes.

Create a video showing what’s going to be new and more importantly how it will improve things for your users. Remember, this not just a boring news of updated software but it’s an advertising to get your users excited about the new features. That excitement will help ease the pain of learning and adapting to the new interface or the new way of doing things. A lot of people are visual learners and this preview will make the changes feel less unknown the next time they use your software. Sometimes even a animated gif does the job well. Here’s google introducing a new feature with a very short animated gif.

Or basecamp doing a in app popup letting people know about changes that are about to happen. Trello does something similar with their “New stuff!!” fox at the top.

Have app Tours & Walkthroughs for new features

When your users use your app all day long a new update can greatly affect your efficiency. You can easily address that negative by providing a short and easy in app tour to re-teach user behavior and help users with missing or moved features. There are different types of tours, but the ones that point out and walk users through how to use a new feature and answer any common questions works the best in our experience. Gmail has a great one that you must’ve seen. Here’s one I saw recently that I liked.

The good news is that it’s easy to add these in app tours. There are several great products out there that makes it pretty easy. Try out Stonly or Intercom for a start.

Have a “I’ll try later” option

This may not be the easiest option from a dev point of view, but it would be wonderful if you can do it somehow - the option that let’s users use the old interface for a while. Very useful when your users have something urgent to work on and you come in with your all new shiny interface where nothing is where it was! Facebook has them all the time when they do their big UI shifts, but they are Facebook. But you don’t always need thousands of developers in your team to do this. Nifty tricks like having the older version still available on a server and click to redirect users to that version might suffice in some cases :)

Ask for feedback

Sometimes all it needs for your users to be OK with your changes is a simple “sorry for the changes, we welcome your feedback” message somewhere. This humanizes the software and let’s your users know that you are putting them in trouble and that you are willing to listen to them.

Remember how angry we would get every time MS would drastically change their interfaces? We learnt the new way of doing things but we were looking for some way to tell MS what then shouldn’t have done!

Anyway, software is always going to be updated, so you’ll just need a way to make those updates less obtrusive to your users. This is a fact of life! Happy software development…

Living with bugs in released software products

Bugs are the reality of software. We hate them, we do everything we can to get rid of them but they are always there and we have to learn to live with them - that is we have to manage the bugs and fix them in a sane way. This is important. Actually trillion dollar important. in study done by the Austrian software testing firm Tricentis, software failures cost the worldwide economy over $1 trillion annually!

The same report also found that software failures have caused more than 315 years of lost time and have affected approximately 4.4 billion customers. Software failures also have a massive negative impact on the reputation of companies. The companies surveyed by Tricentis lost an average of $2.3 billion of shareholder value just on the first day after announcing a software failure. No wonder that so many companies keep quiet about bugs. Yet that is probably the biggest mistake. The trick is to learn live with the bugs as a reality and have a practical and realistic process for managing bugs in live products. Today’s post is an attempt to summarize some of the strategies we found as the best for managing bugs on live products.

Accept bugs

This may sound obvious, but you’d be surprised how many companies treat bugs as something totally unacceptable and creates all kinds of penalties and punishments when bugs start surfacing on a product. This behavior comes from not understanding the nature of software products. Yes, the goal is always to have a bug free software release, but the reality is that there will always be some. So the goal should be:

“Release with as few deadly bugs as possible”

Accepting bugs opens up the possibility of a realistic software development process with healthy bug identification and resolution strategy. So this is the first step - for the management and for the technical team leadership.

Make finding and reporting bugs easy

Real life story:

A group of security researchers were prepping for a major reveal in 2013: They planned to disclose at a D.C. cybersecurity conference how a security flaw in luxury vehicles could let bad guys break in without keys and start the cars.

But Volkswagen stopped them, winning an injunction in a British court after arguing that publishing a paper detailing the problem would "allow someone, especially a sophisticated criminal gang with the right tools, to break the security and steal a car,"

https://www.theguardian.com/technology/2013/jul/26/scientist-banned-revealing-codes-cars

After you’ve accepted that there will always be bugs the released products your next sane thing is to setup a process and workflow for identifying and resolving bugs. It’s just crazy how many software companies out there try to hide their bugs or try their best to make it difficult for people to report them. There are literally hundreds of known cases where large companies tried to stop reporting bugs in their software - just making their users suffer even more.

This line of thinking is stupidity defined. You just cannot stop people from finding bugs. What you should do is make it easy for people to find them for you. Have easy ways for reporting such bugs - such as customer support emails that can easily turn into bug reports, a bug reporting page like Facebook’s Report a Bug feature.

On your development team’s side also have the tools for keeping track of all bugs that are being reported - both by customers and your QA teams. Tools such as Jira are absolutely essential, just as important as the software development tools or issue trackers when the actual software was being developed.

Involve customers in the bug finding journey

This needs to be a management and marketing level decision - involve your customers in the bug finding process. Ask them for feedback, have formal ways of checking back for issues, reward them with freebies when they find bugs. Customers are the ideal QA of a software, they use it everyday and they use in ways that your dev team would not even think about using a software (e.g using MS Word for image editing or Power point to make web pages!).

Microsoft has a thing called bug bounty which literally inspires users to spend time to find bugs and be rewarded for such efforts. Google has it’s various reward programs for finding defects, these are all examples of far sighted companies who have not only accepted bugs in live products and made it easy to report - they are actively involving the customers in their journey to find and ultimately fix those bugs.

Have workflow for updating users about bugs

As you accept bugs as reality, your wording and communication will let your users also accept them and make them expect you to come up with fixes as soon as they are found. They also expect you to be mature about bugs found in the current system and have a place to know about such bugs and the status of those fixes. User forums are great for such things and modern ones like Zendesk or Uservoice and many others like them do a great job of updating users about bugs, getting their feedback and letting them know when things are fixed. They have also the feel of user communities and can lead to bigger and better things such as users helping each other out and users forming their own groups to teach each other.

Create a culture for celebrating finding and fixing bugs

Finally, the most important thing of all - within your company and your development team create a culture of celebrating the finding of each bug and fixing them. Some companies make the fatal mistake of making the dev team feel bad each time a bug is found - this creates the negative emotion that takes away the enthusiasm and spirit the team needs to polish off a released product over time. To a dev team the release product is their own creation - any bug would sound bad to them anyway, it defeats the purpose if the company culture is to make them feel worse. The culture should be that bugs are unfortunate yet inevitable - but once found how fast they are resolved and an updated software is released is the true sign of a great software company.

Trust me on this, after more than two decades in this bug creation, I mean software development business, this culture fix is the biggest thing that differentiates a great software company from the others.

Life is too short for bad software

Great title, isn’t it? Not original, of course (what is, these days of Google?), taken from a talk given by Lew Cirne, founder and CEO of New Relic about his journey about software entrepreneurship. But it’s just too good a line to be stuck to just that, so I’m repurposing for my topic today about bad UX design in software and how that destroys people’s lives.

“One guy’s bad software is another guy’s full time job”

We had a poster up on our social media page today that seems to have hit a nerve of a lot of people. I’ve copied it here, for those of my readers who don’t speak Bangla the text just says something like: “One guy’s bad software is another guy’s full time job”. The expression on the guy’s face says it all.

It’s an easy picture to relate with. With most of our work these days tied with working with one software or another - a bad software - which usually just means a bad user interaction design - really is a hated thing. Us, developers of software, are definitely the ones to take the blame for the bad software but a fun fact is that we too face the same problems. We use clunky IDEs (integrated development environments) to code, we use numerous “wannabe” issue trackers and “agile” project management tools to manage our work. Some of us even have to rely on time tracking tools that are always misbehaving for some reason.

Bad UX is a real problem and life is really just too short for it.

The cumulative cost per year of lost efficiency because of bad software design must be some humongous number enough to buy a thousand Jeff Bezos (erm.. maybe a hundred of him).

However, bad software can kill, too.

Tragic Design: The Impact of Bad Product Design and How to Fix It

By Shariat, Jonathan, Saucier, Cynthia Savard

We learnt this the hard way in the recent software glitch that led to the 737 Max crashes or when when an Ebola patient was sent home because of bad UX design

The sad truth is that good UX isn’t rocket science. Anyone can get to a state of learning the basics - common sense level basic UX in a matter of days if not hours. A simple google search will lead you to a hundred good pages that tell you most of the tricks. There are books after books piling up on good design. Here’s one that caught my eye recently for making the point very drastically and then showing the way out.

And no discussion on UX design goes online from me without a mention to the guru whose book About Face taught me that there is a thing like interaction design!

So let us, software people say once and for all that bad design is our public enemy no. 1. And we will get rid of it wherever we find it!

A software UX design story

This is a story taken from real life. One our customers from the Netherlands approached us with a very interesting idea of a software for gamifying trainings they run. They run trainings for big corporations - stuff like corporate policy, safe working habits, HR good practices, etc. The problem was that the topics were just not interesting enough to keep the attendees engaged. They needed something that would bring in more interest and engagement from the people attending the trainings. And their solution was to gamify the training sessions. They had rough outline of what would work in their heads but nothing in form of documentations. The big challenge thrown to us was capture all the ideas they had, pin them down to software features and also think of ways to make the software usable. This led to a requirements capture and UX design story I’m about to relate…

Chapter 1: Finding the need

We held multiple sessions with the clients and their presenters to gather information about their current working procedures and business needs and singled out the three major requirements:

Chapter 2: Brainstorming

After multiple session of individual and group brainstorming on possibilities, we landed on the idea of developing a gamified presentation eco-system that would include 3 to 5 minutes of lectures or video presentations followed by pop quizzes about the current segment. The participants can engage with quiz live from their mobile device, competing with their peers, gaining points with the goal of being among the top scorer on a live leaderboard.

We came up with four major components

Some key concepts for the components were

Editor:
Create, configure and manage Shows
A show editor
Schedule, share and manage sessions

Projector:
Host's screen:  
* Initiate and navigating a session
Projector screen:
* Showing slides including presentation part and quiz part
* Live responses from users on quiz sessions
* A Live leader board.

Controller: 
A responsive and contextual version of the projected show
Interaction with the quiz slides
Questions, comments and feedback on a slide 

Auditor
View results of a session
Generate reports

Chapter 3: Personas, Use cases and Storyboarding

The next step in our design process was to identify the personas - the typical users of the system. This exercise was done mostly within the design team with a summary session with the customer to get their feedback - we had enough notes from our original brainstorming to identify the typical users of the system.

We then moved on to defining the various uses cases for each personas where we drew up how a persona would use the system to get their job done. For example: How Tom, Dick and Harry, with different personalities will access the show in their own ways.

Instead of just writing them down in spreadsheet or document, which is the standard practice, we decided to do a more graphical representation as this would aid in faster communication of the ideas.

Chapter 4: Prototyping prototyping prototyping

Now that we had a solid idea about how the system would work, we moved on to building prototypes.

We started with horizontal prototyping capturing the global bird’s eye view of the whole system then vertical prototyping drilling down to specific features. Constantly evaluating and refining and gradually moving up from low-fidelity wireframes to a high-fidelity deliverable. 

Chapter 5: Evaluation and hand over to development

The prototypes helped us evaluate the product concept without a single line of code being written. We iterated over multiple version of the prototype by incorporating feedback from the customers and possible users of the system.

With the final version of the mockups done with a graphical prototype acting as a very clear spec document, the dev team moved in to develop the product but that's not the end of the design cycle. With feedback from real users and various stakeholder of the system, we had to to go through a few re-iteration of the design till all in the comfort zone that it was done right (enough).

Great story isn’t it?

Adapted from the original at: https://www.dpixelman.com/ by one the best man to lead our design team, Zahid, who has now moved on to newer things.

Usability testing: How not to strangle your customers

Picture this: your website has a section for the charging plans for car rentals. The page looks awesome, the letters are bold and colorful; the buttons are functioning as they should. Yet, Customer retention is falling like Corona beer share value. And Poof!  your competitor has overtaken you. And your investors are shaky all of a sudden.

Scary, huh?  What if I told you there is simple test that could have saved you? A test which could have warned you about the visitors’ discomfort about the entire process. Perhaps, they are getting lost half way through their buying journey. Seeing varying rates when choosing the rentals and feeling suspicious. Maybe the wrong words are bold and the colors are causing them to shift to night mode. These and other such concerns are the focus of a class of testing call the usability testing.

The importance of usability is known and felt to those who are competing in the highly contested market. While it is expensive and time consuming even for other QA testing processes but people come to realize usability plays crucial role to attract or retain customers only too late. It’s surprising how much of the software world is largely unaware of this and does not make their clients aware of this important aspect.

This is a quick guide to approach the world of usability testing.

1. Consider the business of the project:

Usability is essential to every product. That being said in the out sourcing market usability makes more sense for some particular projects than others. For example: for client facing projects have crucial importance for usability testing while business to business products might want to explore the aspect at a later stage. The right people will benefit from integrating this test in even the pilot as first impression lasts longest.

2. Adapt the process to Sprints:

In the agile development process is fast and do not take any prisoners. Therefore the tests should be tied to the specific Sprints. It will also help to minimize and control the number of tests that need to be conducted. As the per the sprint goal the project manager can assign the tests. This will ensure that the development process is not hampered.

3.   Bake it into QA and UX:

Usability testing is a UXR tool that is used to determine the UX experience. It can be purely an UX task to help improve change and adapt the system. The task can be distributed to the QA team and involve UX team as audience. It can also be vice versa if the task is considered a QA task.

4. Clear deliverables:

There should be a clear deliverable for the test that should be made clear to the client. The test should result in providing a qualitative assessment of the application through a metric. The metric should contain clear scores which are understandable to you.  Also the tests should produce usability issues that should be tracked into the issue tracker. The issues should be streamlined into the sprints.

5. Scale according to budget:

Usability testing could be conducted remotely or on site. It could include 20 people in groups of five or surveys in field. According to the need of the project the companies should offer the plan to find out what is essential and how to acquire it. If the budget makes sense only the test is possible.

Usability testing done well can give you the edge just like performance testing. Be sure to consider it before plunging head first into the ocean of startups; make sure your life jackets have no holes in them! Here’s a stolen Dilbert to make you smile :)

Top Web Developer

How do you become a great web developer?

A question that we get often. Here’s our quick round up of the skills necessary to become a top web developer in Bangladesh (well anywhere, but we speak from the context of Bangladesh).

Foundation Coding Skills

As a professional web developer you will be learning many technologies and programming languages but some things are foundational. They are the absolute musts and you build everything off those. In other words you can never be a top web developer in Bangladesh or anywhere in the world without these coding skills:

HTML

The web is HTML. So you better be an expert of this. Simple.

Regardless of the platform, programming language, framework or library you use HTML is what you are going to work with on the user’s view (read interface, read front end) side.

HTML (HyperText Markup Language) is the standard markup language for creating websites, and HTML documents made with little sections that are marked by “tags”. Although there are close to a 100 official tags, you only need a few most of the time (here’s a great page that lists their top 10). Learn them and the rest you can just google whenever you are confused.

CSS

CSS or Cascading Style Sheets are the styling structure for all web pages. As such you can’t live without them. Every beautiful web page you see from Google to Facebook has CSS in the story. So you have to learn it. This is the 2nd area where you have to invest your energy well. The skills you learn on this investment will stay with you forever.

Great thing about CSS is that it saves you time. Things like CSS selector classes, can let you manage the style of multiple pages from just one place.

Just as HTML there’s a lot of CSS things to learn, but you can get away by learning the top ones and use Google for the rest of your web development career! Here’s a great list of must know CSS.

JavaScript

Javascript is a browser side computer language that makes web pages interactive. There are other languages that you’ll need for web application development, like PHP or C#, you’ll need to know them when you work on the back end but for front end Javascript is the only language that matters.

When you start learning a language like Javascript you start thinking like a programmer. This means that this is where you encounter algorithmic thinking, which is the bases for solving all the problems you will face as a programmer.

Tool Skills

Once you’ve mastered the foundational coding skill above learning the tools that you use is essential. The graphics here shows the most popular IDE (Integrated development environment) tools (source: Stack Overflow).

What you learn will depend very much on what code you are working on, so you don’t usually get much option there. But if you are learning on your own then you might use this to decide to pick up the tool that is most used. At the top of the list is Visual Studio. Makes sense as in the last couple of years, it is the tool that has made the most progress and is the most frequently updated. The number of extensions is growing and so is its community.

Code Versioning Skills

Code version control let’s you to track and maintain the code you work on. This is an absolute must skill for any web developer. Imagine a situation where you make a few small changes to your code and then the whole application stops working. It’s obvious that the changes you made has caused this and the fastest fix would be somehow to rollback to where you were. A version control system let’s you do just that. That is why it’s absolutely necessary.

Version control systems like GIT enable you to make mistakes without consequence. They are also necessary when you're cooperating with other web developers on the same code, they let you share code without worrying about breaking things.

Most popular versioning tools are GitHub, GitLab, MS Teams(TFS), Mercurial, etc. You should start with some flavor of Git as that has all the core concepts in place and it’s very likely you’ll end up working with a Git based system.

Graphic design Tools

In theory a web developer doesn’t really work on graphics - a designer does. But that’s just in theory. In reality you’ll find you have to dabble with graphics all the time. And if you don’t have some basic skills on graphics manipulation you’ll feel that you are getting stuck at every stage and waiting on someone to come and rescue you. Some popular tools for graphics include PhotoShop, Figma, Zeplin and Sketch know them a little bit at least by features and then try to learn at least one of them well.

Back-end and Databases Skills

Once you have mastered the part of the web site that the user sees the front-end, you have to move to the servers side - the back-end. On the server side you have the code and also the data storage - Database. The technology choice is massive here and you have to pick one or two focus on. The following graphs show the most popular languages (both desktop and web) and the most popular database technologies from the stackoverflow study. Use this to get an idea about what you should focus on if you have a choice.

Libraries and frameworks

Now that you have become used to the core skills for a web developer it’s time to focus on specialized libraries and frameworks. These make your life easy by doing all the hard lifting. With these libraries you can quickly get the basic structure of a web application up and running and then focus on adding features. This is a huge area by itself so I won’t go into the details but give you another graph of the most popular libraries out there currently. Know that no one actually learns all the libraries, you’ll focus on one or maybe two that you become real master of. The rest will only be used if you absolutely need to for a project.

Deployment and Hosting Skills

Now that you have made an interactive stylish web site, using HTML, CSS and JavaScript with a server side technology you love and a great database to store your data but how do you make it available to everyone on the internet? You’ll need to deploy it on a server and host it. Web hosting let’s you to store your resources (HTML files, CSS file, JS files, images, database) on a server that has internet connectivity and is accessible to everyone with a browser and an internet connection.

There are thousands hosting providers out there, learn the name of some good ones. Compare them and know their features. The other things you’ll need to know is how to get a domain for your app, how to point that domain to your website.

The #1 software soft-skill

A common question we get asked is: what are the soft-skills that a software developer needs? The answer to that question can be pretty big and some of the candidates can be very surprising (e.g. marketing skills - for advertising yourself in the new job market where employers actually find you rather than you find employers). But if the question is rephrased to:

“What is the the #1 soft-skill that a software developer needs?”

The answer is super easy. There is no confusion here, the answer is:

“The ability argue with logic”

Why?

Because, the software profession is all about debating and arguing what the correct solution to a problem is. There are no final or perfect solution out there. What works for one problem doesn’t work for another. What works today for a certain situation may not work tomorrow. There are just too many possibilities and there are no silver bullets! Nothing is sacred in this space, if “normalization” was the one thing that everyone agreed on data storage strategies (aka databases) yesterday, “de-normalization” could be (and is) the flavor of the day today. We have to live with the possibility that everything we believe in is probably wrong! So the only way to find solutions in this sea of uncertainty is - debates. Rational debates where every argument is proposed with logic and countered with logic. From such an exercise, maybe, just maybe a consensus may be reached. Or, what is more likely the common situation, no consensus is reached but a decision is made one way or the other with the pros and cons of that decision clearly out in the open. This is the only way to make progress.

Emotion destroys a software debate

In this scheme of things the worst possible situation is a debate where arguments are not based on logic but on emotion. The classics in this area are statements like “Relational database is the only way” or “Nothing is better than Java and I don’t want to hear anything else”, etc. These lines and people who make these lines are detrimental to the progress of a software project. They need to be killed, erm sorry, I mean they need to update their soft-skills and learn how to control their emotion and fight it out with logic (and data where possible).

An unpleasant reminder

I was reminded of this recently in an unpleasant way. We run a series called the career booster on youtube - it’s planned as series of shorts in Bangla language about what to do to prepare yourself for a career in software. The target is mainly students and early stage professionals. The third video came out a few days ago and it had the unfortunate title of “Programming languages NEVER to learn”! By itself it’s a mistake to have a title like that because it’s plainly wrong in our field (every language including the dead ones have a place and need and people do need to learn them). The correct title could have been “Programming language not to learn as a beginner” or something like that. But the cardinal sin was that the “NEVER” to learn languages included the mother of all languages C/C++ and the other big god in the pantheon - Java! With a lineup like that a storm of protest was inevitable. The social media became buzzed with hate pointed at us (and at our idiocy). Several influencers picked up on this and we walked in shame. The hate was fully well deserved. We took the video down and tried to come up with various forms of apology and lame explanations.

Needless to say, a complete mess!

But in this huge mess at least something positive came out which is all about today’s topic about the art of making your arguments with logic. Among the literally hundreds of comments (I really mean hate messages here :) ) there were some clear patterns. Some were just awesome killer retorts that proved beyond a shadow of doubt that our video was totally wrong and why it was wrong. And some were irrational and emotional banter that added no real value. You could easily separate out the professionals from the not so professionals in our field just by looking at the comments. Let me go over some of the good ones here to highlight what works great in software. But before I do that that let me restate, the great thing to know is that:

the ability to argue well is a skill and it can be easily learnt.

So being aware that you need to pick up this skill and then practicing some caution to keep your emotion in control and your logic in hyper-drive you can hone in this skill.

Back to the comments. There were some super awesome comments. They were precisely worded, designed to hurt yet made with logic and data that is so undeniable that you can just cry and look at yourself in the mirror and try to remember where and when you lost your brain :) Here’s a particularly good example, and I’ll point out the qualities that make this such a good one:

Clarity: Notice how the writer takes a direct jab at our lame excuse of saying that we had a plan to start a debate with the video (actually partially true but very badly executed). The jab is very sharp yet it is cloaked in the wording of being helpful i.e. “… hurting people’s career, which is misleading.” Precise, to the point and without any strong emotion. The write is just expressing his concern clearly and the opposing side has to either answer back or just accept it as correct.

Supporting logic/data: Then comes the killer - data. If you have solid data as your proof for any argument it is the show stopper. The writer clearly shows that at least in the job site indeed.com Java and C++ jobs are at the top thereby proving that the main goal for our miserable video - career betterment was not met.

Suggested solution: Then comes what I think is the master stroke of any good technical argument - some suggestion on how to improve things now that crack has been identified.

I am awed by a retort like this. Software developers like this person will be an asset for any team where he works. He will make debates short by cutting out the fuss and the endless bickering. He will make his point strong and believable and thus acceptable to other team members including the opposing group (assuming they are not emotional or illogical). And he will suggest a solution and reconciliation that will help the team heal and move on. Awesome!

Here’re two more good ones in a different ways, one points out a clear issue and basically is asking us to address it. Important for any tech discussion where you throw a logical question to the other side and ask them to explain it. The other one in Bengali is purely on the solution space trying to turn the issue into something useful rather than bicker about what’s obviously wrong.

The Survey

We’ve gone over several Facebook pages and filtered out about 300 purely negative comments made by people with software background (as given by their profiles). Overall, on our rough survey only 20% or so of these comments would qualify in some way as a logical, data driven and solution driven argument. The kind of argument we love in technical debates. This is worrying but this data could be an unreliable metrics of the reality as people don’t always stay very rational or professional in a social platform like Facebook. It would have been interesting to run this on a professional network like LinkedIn and see what the data is like. But hey, that’s not going to be us! This was too traumatic and we are done self-mutilation for the year :)

Anyway, gotta go, have fun, stay logical and stay with C/C++ no matter what career videos say. btw, our next career booster video will be about this very topic but we can’t find our actor, he is in hiding after this storm… joking of course! Should come out pretty soon.

MVP to Startup Success

MVP stands for minimum viable product and making an MVP is the only real way a startup can succeed. Making it saves both time and money and let’s a startup find it’s path to a product that the market needs.

What is an MVP really?

An MVP is simply put a cut down basic version of a product that is designed to test the market and get feedback. As a concept it’s been around for a long time, with people trying on “0.1” or betas, but it was popularized as startup process, a survival strategy by Eric Ries and his superb book Lean Startup. Let me let the guy explain it to you himself in this video.

The MVP is based on the concept that early adopters can test and provide feedback to improve the product. Not only the feedback but also test the business viability of a product can also be tested before a founder invests too much on a product.

Here are some things to think about when you as the founder are thinking of making an MVP.

Build the Core Idea

An MVP focuses on one idea and one idea alone. It does not include any other features. The goal should be building a product with a minimal budget in the shortest possible time. So the focus needs to be on the main features that solve a single pain point of the target users. Nothing more. So leave out those export functions and those customizable reports that all products seem to have but very few people seem to use.

Test Early

Even within the small scope of the MVP, the testing early concept is very much needed. Have a plan to start testing from the first day of development. Don’t think that just because you are building a small scoped MVP you can wait until the developers say “it’s done” - that defeats the purpose of the MVP which is a purely experimentation and try things out way of doing things. You as the founder and your team should have the mindset that you are just testing the water as you are building out the MVP.

Have a User Group

The MVP offers the possibility to find out your potential users’ opinion, and how they want to see your final product. So although your own feelings matter and should be the first round of test on the MVP the main goal is to let real users try the product. It’s difficult to find that user group, so start working on creating a group of ideal users. You’ll need them soon enough!

Validate the Demand

An MVP helps you understand whether your app is right for your target market. It should present your brand well to the users, and show them how your project is unique as compared to others in its category. Test out the market viability. Ask users how much they are willing to pay for it, how much time they would spend on the app, would they refer it to their friends and family, etc.

Test the Marketing

Run small digital marketing campaigns, see what the click through rate. This will test how much traction you’ll get with the product. This is the time to test variations of the marketing message. Find out what message gets the best results. This will not only tell you what works for marketing but may also tell you what your users are really looking to buy.

Here’s an example of an ad campaign run for a project management tool, targeted at exactly same demographics both on social media and direct feedback. The one one left got much less traction than the one on the right. The difference is very unlikely to be the imagery or attention as the same graphics same fonts etc. was used. What can this tell the founder? One possibility is that people aren’t looking for project management they probably want team planning (although both were in the feature list). Maybe a little more testing will help, but if this proves to be true the MVP should focus more on the team planning aspects?

Test the Burn

MVP is also test for budgeting and the burn rate. Use the MVP to test how much it costs to do a feature, how much it costs when you pivot on features. A very close monitoring of costs both financial and time is absolutely necessary to give you a good data with which you can predict future costs.

Test the Team

Last but certainly not the least, the MVP is a great way to test the team and it’s collaboration. Whatever happens during the MVP will happen (and happen at a greater scale) during the real product development. So test the teams abilities, collaboration skills and communications. Find out what works and what doesn’t. Use this finding to plan fixes, figure out what you can do to improve the known issues. Try testing the improvements too if possible during the MVP.

That’s it for now! Have a great weekend!