Making your software: Step 5 - Select a development partner

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 has then followed through to step 3 - to get ballpark estimates that gave her the information to budget and create a financial plan in step 4 - budgets and funding. Now she has the all the groundwork done with a good plan to move forward. Now is the time to roll up the sleeves and get into action - the actual software development of the product. And the first step in the action is to select the software development company that will do the job for her. From her previous steps she has nice and short list of good vendors, she just needs to make up her mind in this step to pin down the one she wants.

Part of the selection process is to setup the contracts. The actual legal contract is important, but at the end secondary - since no legal write up can replace a good working relationship. It’s extremely important to setup an operating process - decide how the project will move forward, how you’ll see the results and give feedback, the timeline, etc. The non-disclosure agreement (NDA) is Priya’s protection for the idea about the product as the software company will require her to go over the details of her idea before they can give a final costing they can commit to. There are variations to this plan, but this is typically the path most companies take.

The NDA

The NDA, short for non-disclosure agreement is Priay’s protection of her idea. For the software company to brainstorm and finalize her business idea to fit with a practical software within the limits of budgeting, they need to know in detail about Priya’s idea. The NDA provides protection to Priya in the case where the vendor doesn’t just steal her idea and builds it themselves. In the software world typically ideas are the common thing, implementation is the hard part, but still the NDA provides a much needed peace of mind for the two parties to discuss without fear.

A good NDA will help both sides. So there are typically time limits to the non-disclosure, also well defined definitions for scope about information. It’s obviously vitally important for Priya to protect her business secret and make sure that the vendor does not go away and make it product like hers. On the other hand a typical software vendor will be working with a multitude of customers, some within the same business area as Priya. So the vendor would also need protection from an over restrictive NDA that exposes them risk of breach even though the situation may be just a case of working on similar ideas for different clients. This balance of protecting both sides can only be achieved with scope and clear definitions of what constitutes a secret and what doesn’t.

For most contracts it’s best to use the help of a legal expert. However, NDAs are so standardized these days that Priya can get by using a template from the internet. Here’s one that we like: Free software NDA template but a google search will land Priya many other good ones. Note how the NDA has very clear definitions of information, exclusions and time periods.

Work plan

The next big thing in this phase is come up with a workplan - how the software developer will work with Priya to create the product. The workplan doesn’t have to be very detailed like a project plan, that will come in later when the software mockups are done and the software developer has enough information to create a milestone based project plan. The workplan is more a discussion and an agreement (maybe a verbal one) about how the next few steps will be done and then how the software development itself will be done.

Every software development company has it’s own way of doing things. There are some broad similarities, but the actual working plan is very specific to a software company. So it’s important to clarify that plan so that Priya knows what to expect and also the vendor gets to know about any concerns or timeline pressure that Priya might have. And it’s a good idea to do it at this early stage so that an red flags are spotted early and fixed (hopefully) before any side has made any significant investment in time and money.

A typical work plan (something we at Kaz follow for example) is:

1. Create team for project with clearly identified responsibilities and contact channels (say skype/phone/email/…)

2. Do a series of meetings go over requirements and create wireframes for the main features of the product.

3. Once the wireframes are finalized, create colored mockups to design the exact look of the final software.

4. Create a detailed project plan with timeline and delivery milestones.

5. Finalize the pricing and create a software development contract (unless this was done before).

6. Setup of shared issue tracker.

7. Setup of shared staging environment where client can see product on every build (usually daily).

8. Weekly (if not daily) status meetings and early feedback sessions.

9. Development and delivery at milestones.

10. Feedback sessions at delivery milestones.

11. Demonstration of key delivery of the product with larger groups on both sides.

12. Pilot phasing/Quality assurance sessions/UAT/etc.

13. Deployment on live infrastructure.

14. Support for live system.

15. etc.

End of step 5, Priya will have a software developer finalized and have a clear idea about the process that will get her the software application she wants to build. Now comes the fun and exciting part of actually building the software! It may feel like Priya is taking a lot of time to get to this stage, but remember that selecting the right partner, having the budget planning and having a realistic idea about the process is the only way to successful software product. Any shortcuts here could prove to be extremely costly down the line with time, effort and money spent on something that is not the product. So it is vitally important to go through the motions and get to this stage with confidence.

10000 hours of practice - fact or fiction?

It all started when Malcolm Gladwell published yet another one of his blockbuster books - Outliers. One of the ideas in the book was put in enough practice and anyone can be an expert of anything. In the book, Gladwell states that:

“ten thousand hours is the magic number of greatness”.

Outliers is one of those books that really motivates you, and this idea that you don’t have to be a born genius to become a good at anything is one it’s biggest uplifting moments. Gladwell quotes several studies and gives examples like starting really early and getting those 10,000 hours of practice made the Beatles become the greatest band in history. For example, between August 1960 and December 1962, the they played over 250 all night shows in Hamburg, playing four to five hours a night. This racked up their practice numbers, Gladwell argues, refining their skills leading to becoming the best. John Lennon him self is quoted as saying “In Hamburg we had to play for hours and hours on end,” he said. “Every song lasted 20 minutes and had 20 solos in it. … That’s what improved the playing.”

Is it a fact?

But is this true? Does putting in 10,000 hours into anything makes you the expert? Specifically, for us software people, we can ask “can anyone become a top developer by putting in 10K hours of programming?” Well for a start we all know that the more you code the more you become good at it. It’s one of the first advice we give to freshers or students when they ask about career improvement. There is absolutely no doubt practice makes a man perfect in the coding world. But the bigger question is, can anyone without any coding experience jump in and put in those 10K hours and become the best? This is where you’ll see a lot of dispute. In our experience, some people just are good at logic, or at looking at new ways of solving a problem, or thinking out of the box to find amazing way outs from knotty technical issues. If you start with one of those people and push in the 10K, yes for sure you’ll end up with a world class software developer. But if you start with someone who is not good at logic or just has a different way of thinking that get him into complexity all the time, I fear the 10K will not work so well. So I guess my answer is:

“it depends”.

This “it depends” seems to be in other fields too where the 10K rule is getting debunked. The original science behind the 10K rule was the 1993 paper by Ericsson et al. : The role of deliberate practice in the acquisition of expert performance that studied violinists and their achievements. But a recent study done to check those results found gaps and also the fact that beyond a certain level of achievement other factors came in to make the role of practice less clear.

10K hours of coding?

Let’s say that the 10K rule is a fact. Is it something we can actually do and become the greatest coder around? How long would it take? Let’s do some quick maths

If you wanted 10K hours of coding in 1 years you’d have to do 27 hours a day. So that’s impossible (unless you start approaching light speed and time dilates a bit for you).

If you wanted to do it in 5 years, you’d need to code 5.4 hours a day, 7 days a week. Kind of do-able if you want to loose all your social life. I actually know about someone who did/does something like that. He is definitely one of the best coders in his area, but has lost most of his life and family to the art of coding… so not sure if that was such a good move.

If you wanted to do it in 10 years, you’d be coding 2-3 hours a day, 7 days a week… now this is entirely possible and should be the recipe to make it big in the coding world.

So fact or fiction, coding 10K will improve your skills from where ever you start. Aiming for a reasonable 10 year plan with coding hours fitted in there almost everyday is something every aspiring coder should plan for. And read the book, btw, we are going to do a quick book summary soon about it!

Comparing software services export

Recently World Trade Organization invited us to share our experience in exporting software services from Bangladesh. This was part of their two day initiative of a web conference to compare and understand experiences of service export from LDC countries. Several companies in different service verticals such as animation, software, etc. from Nepal, US, Senegal and other countries presented their experience.

There were also presentations from the government side too from Bangladesh, UK and Turkey. The data analytics on export and import was very interesting particularly Bangladesh’s position in the matrix. Here’s a table of import numbers from UK’s national statistics office:

Always good to see software services export from Bangladesh picking up the lead role somewhere in the world.

Today’s post is a quick summary of the major points we shared from our experience in exporting software development services for the past 17 years from Bangladesh.

Finding customers

One of the biggest hurdles in software services export is finding customers across the globe. This is true for any businesses but for high cost, high risk undertaking such as software development this issue is very much the central one. Over the years our source of finding projects around the world where we are good fits has evolved. Historically our biggest source has always been referrals. Our existing customers refer us to other companies in their network - this is how we grew the most, in a very organic fashion. Referrals make sense as it automatically gives us the credibility that helps make the decision easier. Also finding potential technical project is always easier when someone is placed in network within a country and that what our existing customers are.

But the interesting fact is that over time this is changing. More and more we find that digital marketing is becoming a major source of finding customers. It is at part, roughly, with our other sources such as trade fairs and direct marketing. The following pie chart shows this experience as it stands currently.

Regional variations

Over the past 17 years we have worked with numerous companies across fourteen countries around the world. There are obviously a lot of variation between different companies and it is always hard to generalize. However, looking back we can see some patterns within regions of the world which roughly holds out although there are major exceptions of course. The following table goes over those generalized views. The green circle with checkmark means we found our experience easy and without major frictions or delays. The yellow warning sign says we had some degree of difficulty or delay in those regions.

The rows represent various issues, e.g. red tape is all about government regulations and compliance issues. The columns are rough geographic regions.

Our major hurdles as a software service exporter

There are many hurdles for a software service exporter, but the following two questions are the biggest ones:

How do we find software projects outside of Bangladesh?

Software projects are always difficult to find. There are no standardized location where they are published - they are hidden away in printed adverts, closed door RFPs or tenders, short time publications online, even on social media posts. So it is extremely difficult to find these opportunities in the first place, particularly if you are located geographically thousands of miles away from the country. Over the years here are the things that worked for us:

• Referrals

• Local partnerships

• Trade fairs

• Increased visibility – in bound digital marketing

• Social media outreach

And here are the ones that didn’t work:

• Outbound marketing (e.g. email campaigns)

• International RFP responses

How do we prove we are reliable?

And once we’ve found an opportunity the next big hurdle is how do we, situated so far away from the actual location of the work prove that we can actually deliver. Again, over the years here are things that have worked for us:

• Referrals

• Local partnerships

• Case studies

• Demonstrations of software

• Contracts and NDAs

What doesn’t work for us:

• Certification, CVs

• Brochures and other marketing assets

Overall the webinar was a great experience and the things that we learnt from it was very useful. We are grateful to WTO for including us in the webinar, for letting us be one presenters.

Making your software: Step 4 - Budgets and funds

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. In step 2 she went over strategies to find a software developer company who will turn her dream into reality. Then she gets good ball park estimates for making the software in step 3. Now that she has some numbers she can work on her next challenge of budgeting and financial planning for the software development.

Software development can be expensive, so a proper budgeting and financial planning is essential to make your software and launch it successfully.

Phases of software launch

There are several distinct phases in getting a software product to the market. These phases actually go way beyond the obvious software development and sometimes the founders don’t really realize all the steps and runs into difficulties with finances when that step happens. Here are some of the phases and what a founder should expect from a budgeting and finance point of view on such phases.

Design and planning

Every software product has a significant design and planning phase. If you cut this phase short you end up a poorly designed software that is hard to use or a software that took a lot more time and money to build because the developers just didn’t have enough guidance on what to make. So it’s essential to invest on the design phase. If money is tight, as it is on most startups, this phase can be less elaborate than what textbooks suggest about design and planning of software but it still needs to have some basic things done. The top focus should be a set of “mockups” of the software interfaces. These are pictures of the software screens as the user goes over common or most used features. If money is seriously short, these mockups can be just black & white rough sketches called wireframes, but that’s the bare minimum that must be done.

Typically this phase will require 10 - 15% of your total budget for the software.

Development of the MVP

This phase is the actual software building phase. MVP stands for minimum viable product and we’ll go over the concept of MVP in a separate post. But basic idea is simple: find out what is the minimum set of features that will sell the software and make that first and launch with it. Here’s good video about MVP..

Typically as founder should plan for 40 - 50% of her total initial budget for the MVP.

Launch and marketing

The launch of the product by itself is time consuming and can come with unexpected costs. The developers may request for server certificates, special cloud setups, software licenses that a founder may not have budgeted for. On top of that the launch process itself takes developer time which adds to the costs.

The marketing is obviously a huge area to think about when you are launching a product. Nothing sells without proper marketing.

Typically launch and marketing should be around 20-30% of total initial budgeting, but note that this is one area where it’s very product specific. If a software is planned to be something based on a huge number of users then marketing itself can take up more than half of the all the money spent in a project.

Releasing the updates

The biggest mistake that founders make is not factoring in the costs of making changes to the software AFTER the launch. These changes are usually the make or break between a software that people use and one that goes into the software graveyard. After all, only after a launch does a founder really get to see what works and what doesn’t, what her users are using and what they are asking for. Based on these real data points a founder has to adapt the software, modify it or fix the bugs to quickly launch a new version (usually a series of new versions) that adapts to the need of the market. This process is iterative, it’s usually time and effort consuming and thus it’s expensive. Not budgeting for this phase means the software never had a chance to fight it out in the market. So it’s absolutely essential.

Typically a founder should budget at least 15-20% of her initial funds for this phase.

Maintenance

Maintenance is the phase of managing to keep the software live over time. This may involve bug fixes time to time, maintaining the servers, updating various components as new versions of the OS or other software is released or new security patches are put out. For mobile apps this means the continuous effort to keep up with the new versions of OS that Apple or Android guys are coming up with, each having the potential to break your software.

A founder should budget for at least 2 years of maintenance after launch in her initial planning. Very much a product specific thing, but typically over 2 years it would take up 15 - 20% of the overall costs.

Payment strategies

When the founder is planning for financials of a project there are certain strategies she can adopt for the funding and the payment to the developers. These are general tips, after all, as each project is different with it’s own sources of funding, own specific situations of payments. Here are two strategies that works well for startups.

Milestone based payments

Setting up a payment schedule with the developer based timed milestones is great for both sides. For the founder it gives certain dates where she needs to make the money available, it also gives are a quantifiable way of seeing what she is getting before she does the payments and of course more solid commitment from the developers about the dates. For the developers it’s a good way of splitting up a bigger software project and getting paid as they build it. It reduces their risk by not lumping everything up for a big payment at the end.

Phased development

The phased development strategy is where the founder just makes her final product over a set of phases. Each phase has it’s own launch, marketing and payment. This way the founder can get the product out in smaller steps, judge the market as she goes along and only commit to more payments if she sees the demand. For a developer too it’s is a good way of splitting a large project up and getting paid early. But note that if the phases are too small this might be impractical for the founder and the developer as the costs of starting and stopping the project in each phase can be a big overhead.

OK, that’s it for today on this series on getting your software made. I’ll be back soon on step 5 soon about finalizing a software partner to get software made.

Deep Work - Great book for software professionals

It was a nice winter day at Balmoral hotel. The writer of Harry Potter series J.K. Rowling left a signed statement on a marble bust of Hermes in her room which read: “J.K. Rowling finished writing Harry Potter and The Deathly Hollows in this room (552) on 11 January 2007.

Yes, you have read it right. J.K. Rowling wrote the final book of Harry Potter series in a hotel. Because, she needed undistracted concentration to produce a world class work. Not only her, but also Bill Gates did require such uninterrupted attention to complete the first version of “basic” in 1974 which laid the foundation of a billion dollar company “microsoft”.  He used to close himself up in a separate room most of the time for 8 weeks to produce such a program. Mark Twin, Rabindranath Tagore and so on also had similar patterns. So, what were they actually doing! What is it called?

Deep Work by Cal Newport 

Deep Work: Rules for Focused Success in a Distracted World

By Newport, Cal

Author Cal Newport, an MIT graduate and Georgetown professor has named this as “deep work” and explained this phenomenon in his book “deep work”. He also claimed that, this deep work helped him to double the output of his research papers while raising a family, writing the book and teaching fulltime in a prestigious university.

Now, you might think that, they were some extreme examples or privileged people to do so. But the author shows us some way of how we can manage to do deep word despite busy or daily schedules of other works. Before this, you should know why we need deep work because we all don’t want to be Bill Gates or J.K. Rowling.

According to the author only 3 types of people are going to be successful in the upcoming tight economy.

• People who have large capitals to invest in companies

• People who are very good at technologies

• People who are very good at what they do

 For most of us, the first two are usually not possible, but we all can manage to attain the third quality. That’s where deep work becomes significant. Neuroscientists have found that intense level of focus in isolated fields of work caused “myelin” to develop in relevant areas of the brain. Myelin is a white tissue that develops around our neurons  and allows brain cells to fire faster and cleaner. So in a sense, when we practice deep work, we upgrade our brains and allow specific brain circuits to fire more effortlessly and effectively. It also allows us to rapidly connect ideas and uncover creative solutions. It helps us to produce something standout amongst the noise and avoid being forgotten by the flood of information that we deal on a daily basis.

Shallow work vs deep work

Shallow work are such works that allows distractions like talking to colleague, listening to music, replying texts etc. We also call them multitasking. It decreases our productivity and wastes our time. Whereas, deep work is totally the opposite. Deep work increases our thinking capacity and increases concentration that boosts productivity and makes our work hard to replicate. The shallow work that we do today will be replaced by automation in near future and more people will be willing to do it in lesser payment since that’s easy to do with other tasks.

Attention Residue

Suppose, you are writing a novel with 100% attention. Suddenly, the phone beeps and you reply your friend. Then when you come back to the novel, you can come back with 70/80% of your attention. Rest of the attention stays with your phone. The more you multitask or get distracted, the more you lose your attention to the particular task and in the end, you can’t give your 100% which leads to an average output.

Four methods of deep work

Monastic deep work

Here, we completely separate ourselves from the daily or distracting environment and focus on our work. We have to isolate ourselves from the world until our goal is achieved.

Bimodal deep work

Here, we can conduct deep work for a particular period and live our usual life for the rest of the time. For example- J.K. Rowling used to separate herself into a hotel and for writing all day long and by the evening she used to join the regular world.

Rhythmic deep work

Here, we can fix a particular period (couple of hours) for deep work such as morning of the day to work without distraction and do our rest of the works at a regular basis.

Journalistic deep work

Here, people who are very busy with their schedule, can prepare themselves in such a way that whenever they get free time, they use it for deep work. Peter Shankman can be a great example for that: the author needed some distraction free isolated environment in his very busy schedule to write a manuscript for his book, he bought a round plane trip business ticket from USA to Tokyo. He got 30 hours without distraction in the air to complete his work. Here, he paid some expense but the output that he got, outweighed the expense.

We also need proper food and sleep for the brain to keep focusing on our work. Deep work requires serious will and patience to accomplish. And the result is always something special. So, if we want to be successful in this modern world where unemployment and overpopulation will take over the job sectors, deep work can lead us to the way of success and make you the best version of yourself at your work.

Here’s a quick book summary in Bangla…

Atomic Habits - Great book for software professionals

We are starting a new series on great books for software professionals. The plan is to find books that help us become better professionals in the software development field. We plan to cover both technical books like programming, architecture, etc. and also non technical books that help with our people skills, improve motivation, that help us manage work and life better.

We start this series with one our favorite self help book - Atomic Habits by James Clear. A book that is for everyone. It shows in very simple and clear language with actionable steps how making small changes in our life leads to amazing improvements overall. This is a perfect book for software professionals as they deal with a huge amount of complexity in their work for which they have to constantly learn new things, manage their time better to improve and hone their skills. We’ve benefitted a lot from it and hope you will too.

Summary

Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones

By James Clear

When we want to achieve a goal, what do we do? We set the goal and work for it. But is that enough or does that truly lead to the goal that we want to achieve!

Here comes the big question, what does it take to truly achieve the goal? The simple answer is process. But when we hear about the process, we think of a long boring stuff that requires patience and persistence. So, is it really that tough?

What makes the difference between the winners and losers is action. When we set a goal and do nothing but watch the time passing by, in the long run become losers. On the other hand, who follow the system, make continuous small improvements, actually achieve the goal. Just like any particle is made of small atoms, remarkable results are also made of atomic habits. Habits that make the real difference. So, if we want to achieve it, we have to forget the goal and follow the system instead.

Changing Habits

Generally, habits can be changed in two ways- outcome based and identity based. Let’s draw a very practical example that can help us.
Suppose, someone wants to quit smoking, now if he is asked to smoke, he can possibly give this answer “Sorry, I am trying to quit smoking”. Now, let’s be honest, we all know it doesn’t help much. Here, the person is trying to improve but is not ready to change his identity. And this makes it harder for him to fight against the person who he thinks he is.

WHAT IF ….

He put a different answer instead? Like, “Sorry, I’m not a smoker”.

Anything that we do repeatedly, becomes our identity. Our every action votes for the person we want to be. Because no single action can change our identity. Rather the repeatability of that action can change our identity. When we confidently talk to someone, our identity as a public speaker gets recognized; when we influence others, our identity as leader gets recognized.  Hence, first we have to decide, what type of person we want to be and according to that, we have to keep voting on that identity. If you want to be a gentleman, then your behavior on the road, bus, train should be accordingly. Because we are changing our identity with our belief system.

Four actions

Our habits are generated through the following four steps-

·         Cue

·         Craving

·         Response

·         Reward

Cue is what reminds us of the reward. Craving pushes us towards get the reward and our response makes us to achieve the reward. And we want the reward because we will either have satisfaction from it or we can learn something. And if anything is insufficient among these 4 steps, changing any habit won’t be possible properly.

From these 4 steps, we can say that, we can follow 4 steps to build a book reading habit- 

• Cue: This should be highly visible. If the books are visible, then we can easily notice that, yes, I have to read books.

• Craving: Here we have to make the visibility attractive. For example- we can add bookmarks on the book so that we can easily know how much we have and where we had left.

• Response: This should be easy to respond. So that, it doesn’t become hard for me to reach them.

• Reward: Here we can choose the right book. So that, it brings a higher level of satisfaction for us.

Ways to remove bad habits-

·         Cue should be invisible

·         Craving should be unattractive

·         Response should be difficult

·         Reward should be unsatisfying

We can apply these 4 steps to remove any addiction like- smartphone addiction.

We usually imitate our habits from these three groups of people

The close, the many, the powerful. We are inspired by these three groups in general. Some people think that, they lack motivation. But actually, they lack clarity. They actually don’t know how to start things and how to proceed them. In real- environment is more important than motivation. For example- in case of buying a product, the things that are placed in front of a store, we tend to try them in the first place. So, in case of building a habit or leaving it, we have to setup proper environment for that.

People think that, self-controlled people are driven by their willpower and self-discipline. But actually they design their life in such a way that in order to be disciplined, they don’t need much of discipline. For example- if they think television is killing their time, then they will remove the television from their house.

And when we try to build a habit, we have to keep tracking that process that we are following and try to measure that progress.

To sum it up

We have to remember that, our brain loves challenges. That doesn’t mean it will like challenges that we can never achieve. For example- I love to play tennis. Now if I am put against Roger Federer, then very soon I will lose all my enthusiasm. And if I start to play against a little kid then I will get bored. So, the challenges should not be bored or overly challenging.

Atomic habits are the key to a massive change. So, rather than daydreaming, we have to develop a process and act on it.

Here’s a quick book review in Bangla…

Top Benefits of Hiring an Offshore Software Development Company

There’s a constant uptick in security breaches of companies around the world. It’s a never-ending concern for security professionals, especially since countless organizations are not giving it much attention.

A study by IBM Security/Ponemon Institute conducted in 2019 concluded that the average cost of a data breach is $3.92 million. This raises an important question, "What can companies do to safeguard themselves from these attacks and potential losses?"

How do software vulnerabilities affect businesses?

Software vulnerabilities are flaws or weaknesses in software that compromise the security of a company’s system. These issues can be critical for businesses as a data breach or system attack can easily cost millions of dollars in compromised files, operational challenges, and system maintenance.

How to prevent security vulnerabilities

Data breaches show no signs of letting up; therefore, having secure software is vital to every organization. Although not all attacks can be fully anticipated, many can still be avoided by following the tips below.

Define Security Requirements

You must ensure that security requirements are clearly identified and observed during the entire software development life cycle. This includes business objectives, company policies, risk management programs, and applicable laws and regulations.

Be Mindful of Third-Party Software

Minimize the risks of being exposed to vulnerabilities by managing the use of unsafe third-party components. If using third-party software is inevitable, only use those with Code Signing Certificates to guarantee its authenticity, effectiveness, and trustworthiness.

Consistently Identify Vulnerabilities

Limit an attacker’s window of opportunity by regularly checking your systems for vulnerabilities. Assess and test the software's code to identify new risks. Establish an efficient response program to ensure security researchers can log weaknesses as soon as possible. 

Get Help from the Experts

Since developing innovative, functional, and secure software is what software development companies focus on, they have a strict and consistent process and guideline that they follow for every execution. In a nutshell, they’re the experts who can effectively help your company with your infrastructure.

Why hire an offshore software development company?

To help businesses decide how software development vendors can help with their system security, we’ve broken down the top benefits of hiring an offshore software development company.

Guaranteed Security

Trusted software development vendors are experts in their industry, especially with system security. They are knowledgeable about the dangers that companies can face and how to mitigate them. Partnering with the right firm means you’ll have access to professionals that would turn your business and security requirements into a reliable product.

Cost-Saving

Outsourcing your development project is a more efficient and financially sound choice since you won’t have to hire and train an entire team to create software. You can use the money you save for the betterment of your company.

Reduced Liabilities

A software development process requires a lot of valuable time and resources. It demands full attention on the core objective, from the inception phase to the deployment of the solution. 

To maintain the project, you must have a dedicated team to handle the task and acquire the tools for development. These obligations can be expensive for companies, especially for small and medium-sized businesses trying to minimize liabilities while maximizing the efficiency of available resources.

Faster Development Time

Competition is tight in today’s market, so producing secure and functional software in a short time will benefit a company. In-house development requires hiring software developers and researching rigorously on the best tools needed. Without the technical know-how, this can take a lot of time and delay the entire process and compromise quality.

Utilize The Top Resources And Technologies

The technology landscape is rapidly evolving, with technologies such as artificial intelligence, blockchain, natural language processing, and many more changing how industries operate. Different resources are being utilized in offshore development, which enhances the development life cycle and their ability to create powerful software that influences innovative technologies.

Offshore development offers a simpler course to expanding your business and leveraging the decade’s technological advancements. Not to mention the security and peace of mind that it can offer your company. Ensure seamless business continuity and growth with these insights.

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…