All you need to know about bug reporting

Bugs are a fact of life in software. There will always be bugs, we just need to find a streamlined way of catching them, reporting them, fixing them and deploying a new version with at least that bug fixed. In this process of catching bugs and removing them from the software the role of bug reporting is vitally important. If not done right valuable time is lost in clarifying what the bugs was about and in the worst cases important bugs are either forgotten or deprioritized. This situation makes the software less usable and eventually if this situation continues the users stop using the software - which is effectively the death of a software. So today I want to go over one of the least exciting topics in software development yet one of the most important one - reporting bugs in a way that is effective, efficient and clear.

The bug report

The best bug reports are short with a step by step "how to recreate" section and an expected results section. It’s pretty easy to remember the rule for a good bug report. Every bug should have at least the following:

1. Steps to reproduce the bug.

2. What was the result?

3. What was the expected result?

By laying out the result and the expected result the bug report is clearly showing to the developer the gap. The developer can now use #1 to recreate the bug, look at the result and check why it’s not giving the expected result.

Here’s an annotated example of a great report from a really good post about how bug reports should be done.

Apart for the basic facts above, additional data such as screen grabs and links to the product page are always good to have. Something else that also matters is the context of the bug - if there was a special situation when it happens (ideally that should be part of the steps to reproduce, but sometimes it may be hard to put that in there). If your bug is related to a specific hardware device and you should attach your device ID, it helps the developers find the bug faster and fix it sooner.

Including as much detail as possible makes finding and fixing your bug faster, remember that when reporting the bug the state of the software may be completely different from the time when the bug is being re-created and fixed. Many times a bug that was reported cannot be recreated by the developer. The reason could be that a step was missed in the bug's description or the state of the software at that particular situation needs to be in certain way for the bug to recreated. I remember a particularly nasty bug that would only happen at the QA's machine but never on my dev machine. The reason was that the QA would always run the web app by clearing his cache which would create a situation very different from my one where a certain cookie was always set. So the bug was really about not managing the cookie's absence.

Sometimes there could be many bugs that you report without realizing it. For example if the application is doing something wrong in a situation where you expect it to do something different and you thought you had reported the only bug and then discover another one after some time, chances are that your first bug was actually two separated ones and not one big one. The QA needs to think through every bug to see how it happened.

As you can see, describing a bug is not as easy as it looks and chances are that if you report a bug like this: "I opened the app and clicked 'login' but I was on the 'welcome' screen and there was no way to go back", then it will be impossible for developers to fix that. And it will end up spending everyone's time.

The process after the report

After submitting your bug report in an issue tracker, it should first be picked up based on severity of the bug. If the bug is a show stopper, a bug that stops the software from working then it should be prioritized over all other bugs and if needed current development flow will need to be changed to fix the bug so that it hits the next release. If it happens not to be a show stopper but just an inconvenience, then it gets bumped down the list and is fixed over all other bugs that are also being worked on. The issue tracker should be available to the original reporter of the bug (maybe the QA person or even the user of the software) who can easily track it down and see the status of the fix.

Another important thing with a bug report is the history of the bug. Every bug should show when it was started, what happened during it’s fixing, the exchange in information that happened to clarify the bug and finally the fix and the confirmation of the fix. So a history of the workflow per bug is a must and every software development process should use an issue tracker that supports such history. The good news is most modern day issue tracker such as Jira, Github, fogbugz, etc. support this buy default. Even the simple trello board is good for this.

Making you software dreams come true

Now is the time

It's never been easier than now to actually develop and release your first piece of software. You can do it in spare time after work or on the weekends so you don't have to wait and delay it anymore. The technology exists to help you move things faster. The only thing that is holding you back is your fear.

 You are not alone in this. There are many people with similar fears - some of them are even afraid to post their ideas on the web because they think someone will steal it. But this just doesn’t make sense, we know first hand how hard it really is to make something good and useful so the huge moat that exists from idea to a real usable software is huge. Ideas are easy, it's the execution that is super difficult. I will argue in this post that now is the time to start - you can start with something and end up with a very different product and a different company. Remember you can always run a rebranding of the company once you know exactly what works. Here’s how you should start.

Take the first step

We all have dreams about making something useful, something that solves a pain, something that makes our life that much easier. That is exactly how all the software platforms around us started. It's very easy to forget that when you are in the middle of the whole thing. But it only takes a bit of research to uncover all the stories behind today's giants. And these people weren't billionaires sitting on their money before they made their products, they were just like us, with big dreams and nothing to lose. Sure there was some hiccups, maybe huge ones, but every little mistake is just another signal for you to change your idea so that it fits with what the market needs.

Start deciding now what is it that you want to make and start doing some research about what the market needs. This way you will make sure you are not wasting your time and energy on something that has already been done or that can't be done properly because there is no demand for it. Of course the last point raises the question: How do we find new ideas? How do we know that the software I'm planning will be something that everyone wants?

What do people really want?

Sometimes it is easier to find a gap in the market. This simply means that you research what your competitors have and try to analyze what they are missing or not doing properly so that you can offer the same product with more advantages. For example, there were a lot of applications for office tasks but no one offered a solution for lunch at the office easily! And that's the niche that all the food delivery platforms filled in. Food delivery disruptors like just eat or uber eats are just ideas that came by finding the gaps in our everyday life's workflows. Take this from the wikipedia article about one of the oldest food delivery apps: :Takeaway.com was created by Jitse Groen in 2000 after he had a difficult time ordering food online from local restaurants. Initially, Groen wanted to deliver all kinds of consumer goods; however, he noticed that food deliveries had the most demand, and decided to make this the company's primary focus. This is a common story for most successful apps.

Another way is to think of something that you just hate with a passion and then come up with a solution. If you have an idea, don't wait for it to be perfect - put in the time and effort right now! Chances are likely that there are many others who share this dissatisfaction with what currently exists so your product will probably find some fans. That's all you need to keep the ball rolling - some early adopters. They will give you the ideas of what else is needed to make it even more useful. What features people will pay for, what they lack in the market. Starting from a small set features leads you to take the baby steps that lead to software that people really want. Take any successful software as an example, look up their history and you'll find that they all started with a very very small set of features and they changed, updated and upgraded all the way. Do you remember how MS Word 1.0 was? It was a disaster, a buggy software that had much less features than the leader in the field then Word Star or Word Perfect. But what MS Word did was solve the pain of remembering formatting codes and use the wsywig paradigm to make users' life easy. It wasn't perfect, but it was a start.

Software is difficult. It requires dedication, creativity and endurance to make it happen. You will have to conjure up the programming language that fits your needs, come up with features for your software, make sure everything works across devices, platforms and operating systems. But if you are now finally ready to face all these challenges - welcome!

How to evaluate software development company performance

Do you find that your software development company is taking too long to deliver a project? Do they lack creativity and innovation? Would you like a partner who can provide accountability and transparency in their work? If so, read on.

As a custom software development company that have worked with hundreds of clients all over the world we have come across all kinds of situations where multiple parties are involved in creating a software platform. The performance of each party is crucial for the overall pace and success of the software project. And we have advised our customers about how to monitor and assess performances of their vendors - including ourselves! In today’s post I will summarize some of the biggest tips we have for our customers to assess the performance of a software developer.

The basics

In order to evaluate the performance of a software development company, there are four criteria worth considering:

speed, price, quality & service

Here's how these factors stack up for one of our clients:

-Speed: Slow delivery times lead to lost revenue as well as frustrated customers. Our client has already seen an average 30% increase in productivity from the new vendor we partnered with them on this project.

-Price: You get what you pay for! The old adage applies here, however there is a big mitigating factor here - location. If you are using a vendor at a relatively lower cost location such as ourselves based in Bangladesh you have the opportunity to find a price that is lower without compromising on the quality.

-Quality: This is the the most important one. In the world of software the only thing that really matters is quality. And you could compromise on pretty much all the other factors but not on the quality.

-Service: How’s the requirement analysis, the communications during the build, the delivery, the promises kept and the promises broken? All of these go towards the service metric.

The performance measurement matrix

The performance measurement is not a linear operation. That is to say it is not a single number you are looking at. For example a company that is great at quality might be really poor at speed. Does that mean it’s a badly performing vendor? The only sane way of getting a full view of the performance is to create a matrix that goes over the issues at stake and measures each one of them against the four basic dimensions of performance mentioned above.

One thing to note before I jump into this: there are hundreds of “scientific” way of measuring performance of a software development vendor. This is a topic that is favourite with efficiency specialists, university computer engineering departments and large multinationals with huge investments in IT. If you really want to get to know some of the research work that is done in this space a great starting point is the highly academic yet useful book generalized towards engineering organization performance: Performance Measurement and Management for Engineers or if you prefer a google search will lead you to a pages and pages of approaches towards measurements. What you’ll soon learn is that there is no standardized foolproof way to do this. At the end you end up with a lot of hand wavy metrics. All the big names in software has said something or other about the futility of measuring performance in software projects! Here’s one I like a lot:

“So while I see the value of measuring individual performance in research settings, I think its difficult to find cases in which the effort is justified on real projects.”

— Steve McConnell

OK, now that I’ve got that out of the way, let me go over what we suggest. Our approach is pragmatic. We accept that no measurement scheme will be perfect, so all we can do is layout some basic information in a way that’s easier to visualize and let project owner do their own assessment based on that. So that leads us to the matrix I was referring to.

The columns in the matrix are the four basics - speed, price, quality & service and on the rows are the questions or issues that matter to the project or to a particular company. In this super simple method we take away the pain of running elaborate surveys, questionnaires, software line of code analysis etc. that some approaches use and use a very intuitive way of quickly getting to some feelings about the overall performance. Note that the number of rows, that is the issues, actually vary project to project, company to company. And that makes perfect sense, what matters to one project may not be an issue at all to worry about in another.

Here’s a sample matrix that we did for one of our customers recently. They had a total of 28 issues that they tracked with this, beyond the ones shows in the screenshot the rest were specific the product features, stuff like “All screens should update with animation”, etc. These made sense for this particular customer as they thought this was essential for the assessment of performance, but for many other companies such a granular level or such a narrow scope for the assessment wouldn’t make sense. That is the beauty of a simple matrix approach such as this one - it is flexible and can be adapted to the need of a specific project/customer/vendor situation.

When it comes to evaluating software development company performance, there are a number of factors that can help you determine if the vendor is working in your best interest. I’ve outlined our suggested way that seems to work very well for software projects. You can use this at regular intervals (we suggest every 6 months) to check the performance and detect signs of change. The change in scores from previous ones give you the signs of a change in performance - for the better or for the worse. Do any of these signs apply to your current vendor? If need help give us a shout at info@kaz.com.bd to learn how our team might be able to help you.

Leadership in software development

I was recently reading an interesting post about various kinds of leadership styles in the business world. The author tried to distill the styles into the following:

• Autocratic Leadership - my word is only word good or bad style of a leader

• Authoritative Leadership - follow me (better version of the autocratic if the leader has a clear vision)

• Pacesetting Leadership - driven leader who sets a high standard and pushes people towards that standard.

• Democratic Leadership - consensus driven

• Coach-Style Leadership - a style that focuses on mentoring the team towards perfection

• Affiliative Leadership - people and their needs first approach towards work

• Laissez-Faire Leadership - hands off, I trust you to do the job style

Pretty exhaustive list, but while we are at it, I’d add some weird ones I’ve come across in my working life too:

• Bureaucratic Leadership - follow the procedure whatever the case style

• Transactional Leadership - tit for tat style, where your life gets better if you perform better. Money money money sort…

And of course the infamous

• No Leadership

This is great, although I would think in reality any particular leadership is a mixture of style. But I would also agree that in general there is a “style” that dominates in everyone. So the big question that comes next for us software people is:

What’s the best style for software teams?

There is no fixed answer to these type of questions except maybe the boring ones that start with “depends…”. But I’ll not go with the boring ones and try to answer this in a very specific way with our experience at Kaz Software. With more than 17 years under our belt, making and delivering software and more importantly surviving :) I’d say our way is a good answer as any. So much so that I’d say Kaz’s way i the only right answer and any other answer is wrong.

So here goes…

The answer is (imagine atmospheric background music here): Intrinsic Motivational Leadership

OK, that one isn’t in the list above and it’s kind of a made up name, but let me explain.

Intrinsic motivation is the motivation that comes from within. This is a opposite of the extrinsic motivation that is usually money or status. A leader who can create this motivation in his or her team is the only kind of leader who will excel and that software team will be the best at what it does. A leader with this style of leadership follows two goals:

Goal 1: Create a jelled teams

Such leaders know that in the business of software development teamwork is the highest priority. That is the only way to get reliable and reproducible results from a team. To create cohesive team that feels like a family is the biggest goal for such a leader. A team that feels like a family has a specific identity, specific way of doing things and saying things. All these together creates sense of loyalty and commitment towards the common goal at hand - be it the challenging deadline or fixing the impossible bug.

“Google users trust our systems to help them with important decisions: medical, financial and many others. Our search results are the best we know how to produce. They are unbiased and objective, and we do not accept payment for them or for inclusion or more frequent updating. We also display advertising, which we work hard to make relevant, and we label it clearly. This is similar to a well-run newspaper, where the advertisements are clear and the articles are not influenced by the advertisers’ payments. We believe it is important for everyone to have access to the best information and research, not only to the information people pay for you to see.”

— Google's 2004 founders' letter prior to IPO

It helps if the company’s long term goals are something to be proud about. A great example is Google’s “don’t be evil” which has been an unifying slogan for Google’s teams. Although it’s been slowly phased out when Alphabet formed.

Similarly Apple employees have almost fanatical following and identification with the company’s goals and aspiration with the famous slogan of “we are against totalitarianism”. A classic Steve Jobs move which started with the Mac ad in the 1984 superbowl directed by none other than Ridley Scot (of Alien fame). If you haven’t watched the ad, it’s a must…

So a leader whose goal is the intrinsic motivation, will need to do something that to creates an identity which leads to that jelled team goal.

Goal 2: Make information available

A software team is by it’s very definition a group of smart individuals. Software companies invest the biggest on their HR cost and that is all because of the smartness of individual members of its teams. A motivational leader knows that the best way to lead is not to rely on his or her own brain but rather to rely on the collective smartness of the team at hand. And to make that possible the leader has to do everything to make all information needed to make a decision available to the team. Thus, hiding some facts that are only available to the “management” is not an option for such a leader. She has to work with different parts of an organization to bring relevant facts and information out in the open for the team to decide what the next step is.

To achieve this goal a leader has to convince the management that openness is the right way forward - not an easy task. It’s difficult and sometimes almost impossible for business leadership to reveal the innards of an organization. A project that is running of funds, a customer who has negative feedback about a team, a marketing venture that lost a lot of money, etc. are ugly facts of running an organization. Hiding such information from the teams lead to statements from leaders like “I know things that you don’t know…” - which just doesn’t lead to intrinsic motivation goal. It also makes it impossible for smart software teams to come up with decisions that are based on facts and data. So a motivation driven leader will have to do all in her power to make such information available to the team and then empower the teams to make decisions. Collaborative decisions coming from agreement from the team leads to the most effective decisions and a leadership that focuses on such a strategy is always a winner in software organization.

I’ll leave today with that great video of the 1984 superbowl ad that Apple made… always a fun watch. While you are watching it keep remembering that this is an ad for a computer!

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?