A software UX design story

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

Chapter 1: Finding the need

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

Chapter 2: Brainstorming

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

We came up with four major components

Some key concepts for the components were

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

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

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

Auditor
View results of a session
Generate reports

Chapter 3: Personas, Use cases and Storyboarding

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

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

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

Chapter 4: Prototyping prototyping prototyping

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

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

Chapter 5: Evaluation and hand over to development

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

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

Great story isn’t it?

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

Usability testing: How not to strangle your customers

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

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

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

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

1. Consider the business of the project:

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

2. Adapt the process to Sprints:

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

3.   Bake it into QA and UX:

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

4. Clear deliverables:

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

5. Scale according to budget:

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

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

Top Web Developer

How do you become a great web developer?

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

Foundation Coding Skills

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

HTML

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

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

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

CSS

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

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

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

JavaScript

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

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

Tool Skills

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

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

Code Versioning Skills

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

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

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

Graphic design Tools

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

Back-end and Databases Skills

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

Libraries and frameworks

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

Deployment and Hosting Skills

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

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

The #1 software soft-skill

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

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

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

“The ability argue with logic”

Why?

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

Emotion destroys a software debate

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

An unpleasant reminder

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

Needless to say, a complete mess!

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

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

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

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

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

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

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

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

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

The Survey

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

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

MVP to Startup Success

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

What is an MVP really?

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

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

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

Build the Core Idea

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

Test Early

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

Have a User Group

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

Validate the Demand

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

Test the Marketing

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

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

Test the Burn

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

Test the Team

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

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

The no 1 skill for software founders

As a software founder you have to be a master of everything. You have to wake up with the motivation of Tony Robbins, morning routine of Elon Musk, run meetings like Bill Gates and finance like Jeff Bezos. It’s not easy. Yet, as a software founder, none of these skills and abilities are the number one skill that you absolutely have to have to be successful. That number one skill is

The ability to scope well

Or in other words, the ability to decide what features to do and what to leave out. This single ability alone can get you a software that you can afford to build and that people want and will pay for.

The good news is that this skill is something that can be learnt. Here are some guiding principles that can help:

The Pareto Principle

Way back in late 1800s an econnomist named Vilfredo Pareto came up with a simple idea:y 80% of the effects come from 20% of the causes. This is now known as the Pareto principle that gets quoted in every where people are trying to choose what to do and what to leave out.

It sounds too generic, too optimistic. Yet the funny thing is you’ll find over time it’s spot on. OK maybe not exactly 80% to the dot, but close enough. In the software context you could rephrase it as: 80% use of a software comes from just 20% of its features. So - if you could get to those 20% only you’d make most users happy. Think of the huge benefit, 20% of the costs (and time and effort) to get you enough of a software to go to market.

Another place in software where this 80-20 comes in is fixing bugs. Software will have bugs, but if you can find the right set of 20% bugs you can probably cover 80% of the issues. There’s a famous story (probably true) of Microsoft’s ex CEO Steve Balmer sending out an email about how this has clearly been proven by stats on bugs on Windows XP.

So be aware of the famous Mr. Pareto and learn to hone your skills for finding those magic 20% of what needs to be done.

The MoSCoW method

The MoSCoW analysis is a simple process for identifying priority items. It’s used to classify requirements into different groups according to their significance to the customer.

The process of MoSCoW analysis in software requirement analysis involves taking each possible requirement in your software and putting it into one of the following sets:

• Must have : Something that must be done. Without it, it doesn’t make sense to release the product.

• Should have: Something that should be done. You can live without this feature, but you risk losing a significant amount of customer interest if it’s missing.

• Could have: Something that could be done. It’s a “nice to have” that makes the product better for your users, but at the same time it isn’t all that critical for your success.

• Won’t have: Something that would be nice to have. If you’re done early, this is a nice, but really it’s neither required nor important to the majority of your customers.

Looking at these groups, you might think that such a grouping is something product management (or the product owner) could do on their own. But it’s really your job. Only you can see the full picture of time, effort, budget and time to market. The market (and your competitors) aren’t going to wait too long for your Must haves to be done. They’re going to move on. That’s why it’s important to do the MoSCoW analysis jointly between product management and engineering. If you can identify a Must have which isn’t feasible in a reasonable time-frame, you need to find alternatives, the sooner the better.

$100 test technique

This technique is described in the superb Managing software requirements (Leffingwell and Widrig) book. The idea is pretty simple:

1. Get all the major stakeholders in a prioritization session and then make a list of features/items that need to be prioritized.

2. Give everyone imaginary $100

3. Ask them to divide the amount among the given options (user stories, tasks, requirements).

4. Add up the dollars for each item once everyone is done and then you get to know which items are most valuable (and should be done first)

Five whys technique

The five whys method is part of the Toyota Production System. Developed by Sakichi Toyoda, the Japanese inventor. It’s the simplest thing on Earth, yet amazingly powerful in revealing hidden details of any problem. The process run by the analyst (usually you) asking the stakeholder (usually you again, so you asking yourself) repeatedly five times why the requirement is necessary until the importance of the requirements is clear. The answers reveal whether the requirement is really important or if can be delayed.

That’s it for today, if you really liked this and want to dig deeper, this is a hot bed of methods and techniques and recipes. Google and you’ll find a treasure trove. And if you want a superb book to read then the classics would be Agile Estimating and Planning by Mike Cohn and the aptly named Software by Numbers: Low-Risk, High-Return Development by Deene and Cleland-Huang

Software by Numbers: Low-Risk, High-Return Development

By Denne, Mark

Agile Estimating and Planning

By Cohn, Mike

5 tips to stay sane with automation testing

Automation is great in the SQA world, but if not managed well it can get really messy. So how do you stay sane?

If one manages to land a sensible product manager who understands the many felicities of developing a business critical UI automation system it is incumbent upon you, as the “SQA guy” to try to do it the best way possible. So here are some road signs I picked up while navigating this cool neighborhood:

1.  Use the best Unit Test module

I started off with the well trodden and well documented path of Python’s default unittest module. The module is very well adjusted to the Object Oriented ways of the UI Automation. But upon looking into the wonderful pytest and its many wonderful features, (fixtures, smart test grouping, excellent hooks and plugins) I had to go with the small learning curve it accompanies. It was worth the time and trying out these modules before starting the project saved a lot of time.

2.  Break down the page object methods

The solution should follow a simple principle. Leave the testing to the test methods. The dilemma is what the functions mean in the Page objects. Well ideally it should not think in web elements but it should think in what it actually does. Like does a function might be used to log in, and not always sending the password to the web element. Sometimes a function may just mean a lot of complex things done in a single function and it makes sense until you are left with huge heavy functions with many dependencies. So you have to find a balance and make it as granular as possible. A thorough understanding of the business is essential to do break this into sensible chunks.

3.  Xpaths but smart

So the saying goes Xpaths are prone to breaking. Which it does. Copy pasting the full xpath will get you fast result but will leave you with flaky code. So if time permits you have to construct and spend some time on unique CSS attributes, Name and Ids to construct good Xpaths (Or use those attributes by themselves). The use of recorders maybe helpful in granular cases. Relative xpaths are quick and better solutions as the time is constrained. You have to find the balance to using these and not be shy to provide the full xpath when its time. But you should definitely know when that time is.

4.  The case for using a lightweight IDE

As the code is repetitive and the coding pattern is relatively simple one might make the argument the lighter and much modular IDEs like VSCode and Sublime text might be given a go. The Modular nature and the plugin strengths of the crowd favorite VS Code makes it an obvious choice but the lightness of Sublime text might just suit your style.

5.  Write clean code

Just like any other kind of project it should follow the basic Clean coding tenets. But especially true for aforementioned Single responsibility principle. Avoiding code duplication is also pretty important. And what I found was particularly important was proper use of Comments. You can literally follow the software business to create a cogent story for the automation to make sense.  It could be done even the untrained eye could make sense of the code.

Making your software: Step 2 - Find software developers

Priya, our fictional software entrepreneur from the previous chapter 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. Now her big challenge is to find a software developer company who will turn her dream into reality.

This is not an easy task. There are literally tens of thousands of software companies in the world. How would Priya find the software company that’s a right fit for her? Let’s try breaking the problem down a bit and see if we can come up with a strategy for finding the right software vendor for her. Let’s define what we mean “fit”:

For Priya, as an early stage founder, fit means the 3 following things in the order of their importance:

1. The communications is good between Priya and the team that will work on her product.

2. The cost of making the software is within budget.

3. The software vendor understands the nature of early stage startup projects like Priya’s.

Let’s go over these points and see how Priya can find software developers with these points in mind and also check for the fit.

The Fit

Communications is the key

Priya is not a software professional so she needs to find someone who can communicate various technical jargon and issues easily to her. Even if she was a techie herself, as an early stage founder she might not have the time to focus fully on her project - since many early stage products are “side projects” where the founders have a day job to worry about. So Priya needs to find a software developer who speaks at the same wavelength as she does. A developer who understands well what she wants to build, her business priorities, the “low hanging fruits” she wants to pick and can tell her in simple terms what technical challenges there are, which decisions win her time, which compromises saves her money without losing a lot on features, etc.

Let me stress this once more: communications is the MOST important thing for a software project. If everything is perfect, if Priya finds the world’s best software team working at the just the right cost for her and she then finds that she can’t communicate with them well then she needs to look elsewhere. Simple rule, yet many early stage founders falter here. Maybe the cost savings or the flashy tech skills make them think it OK if there are some issues in communications. Sometimes they think “software engineers are like that, they will always speak in jargon and I have to accept that and try my best”. It’s simply not true. Software can be complex and obviously very technical, but a good software team will always ensure that there is someone in the team who understands software jargon, “nerdy” engineers and also business priorities and the founder’s thinking.

Staying in the ballpark matters

Cost is a big concern Priya, obviously. She has limited budget and she has fit all the costs for software development, hosting, advertising, travel, etc. in that. The actual specific number is something she will calculate as part of the planning that we will cover as step 4 in her journey. The reason for delaying this, instead of taking it up as an initial thing, is for her to get an idea about potential software development cost. Software development cost varies wildly depending on what she wants to make and also on the vendor she wants to use to make it. But whatever the situation she has an idea about the maximum she can spare for her project, e.g. she will know that she can’t spend a 100K for sure but she will probably be able to scrape out 10K. With such a number in mind she can then narrow down her search for vendors, taking out obvious ones out.

Experience with startups is important

Most early stage founder driven software projects are a wild journey. Pretty much all such projects start with a certain plan but end up being completely different. This is the nature of the game. The need and flexibility to pivot is extremely important for the success of Priya’s software. This is because both Priya and the software vendor doesn’t really know for certain what will be acceptable to the users of the software. Priya does a good job with her experience in dealing with her customers to find out the pain points and use the template in step 1 to create user goals and stories. But those are just her assumptions. They are tainted by her bias about what she believes her software can do. They are not test on the field by real customers. And she may find out really early on (hopefully) that certain features need to be changed a lot to meet what her customers really want.

The software vendors are typically in a blind spot too about Priya’s customers. They may know a thing or two about what features are good and what are confusing. They will definitely know (if they have the experience) that they should limit initial features to bare minimum focusing on the biggest pain points for her customers. But at the end everyone is shooting things in the dark. This is why the software vendor needs to have the understanding and experience about startup project like Priya’s. They should know that the project features, needs and timeline will vary as the project progresses. They need to plan for this possible change and accept it as the norm. Their experience will also help guide Priya towards taking the right decisions.

The selection process

Now that Priya knows about the fit, here is a process she can use to find and filter the software vendors. This process has worked for hundreds of our startup founders so we can vouch for this.

1. Compile a list of software companies and score their online presence and reference

Google will get you the names of thousands of possible software companies. But before Priya does that she should first reach out to her friends and family for any vendor they know or have an idea about. The best way to find a good software partner is through reference, it saves Priya a huge amount of time and energy. If the reference is really good and from someone she trusts, she should still do the scoring for fit as given below, but she can save time by not going through the compiling a list of candidates and comparing them. The referred company checks fine on fit, she can just go with them.

If Priya is relying on Google to find names, “custom” or “bespoke” is the right word to use to filter out software product companies (that make their own software only - like Microsoft) from the software consultancies that makes software companies for others like her. Here is a good search phrases she can try:

“Custom software companies in ________ “ (if she is looking for a specific location like her town or a specific country because she heard the costs are lower there).

Apart from google, there are directories where Priya can search for software companies - these usually come with reviews (take them with a pinch of salt though!), example projects etc. Here are some directories that are pretty comprehensive:

Clutch

Goodfirms

G2

When collecting the names of the companies it’s easy to get carried away and end up with dozens of names. It’s a big time waster to go through a large list, so it’s always a good idea to do a filtering even when compiling the list of companies to consider. Priya should look at the companies website and their work portfolio to see if they look good and have worked with early stage founders like her. Some custom software companies only work with big enterprises and their DNA will never match with what Priya’s project needs. Another important thing to check is how active the company is currently. Many software companies start out doing a few interesting projects and then lose their energy and become almost a relic that tries to leverage on past glories. Priya should look at company’s social media posts, recent posts and tweets to get a feel about how engaged and energized the company is. Another important check is looking at some LinkedIn profiles of key members of the company to get a feel about their experience and their involvement with the company.

Based on the companies online presence give them a score and if a company comes with reference you trust give them a score on reference. Our vendor selection spreadsheet template that you can download below has a cell for these scores against each vendor.

2. Email software companies and score the experience

This initial email itself is good way to test the candidates for fit and filter out some companies - that is where the scoring comes in. Here’s how: the email Priya sends out would be intentionally vague. She would of course mention she wants a software made, but not give a lot of details or give conflicting information. The reason is it to test the communications right from the start. Any reputable software company will prioritize incoming business leads like Priya’s email. So it would go through a certain workflow. In some companies it may go from customer support to a business team, in others it may jump directly to a decision maker. The flow, the time to respond, the process of clarification about her vagueness, the quality of the reply, the position of the person replying and the message itself will give Priya lots of hints about the quality of communications in that company. If, for example, Priya gets into a loop of emails, where she gets thrown from one person to another in the thread it’s a BIG red sign. It would probably indicates bad work process or communications channel at the company and something very similar would happen during the project. So, this initial email and the response is a great test (easy and low cost!) that Priya should score.

3. Run a survey and score the response

Now that Priya has list of software companies she should send out a standard survey to all of them and ask them to respond. The survey should address some of the basic issues she needs to know about a company so that she can compare them side by side, but also the survey should be done in a way so that Priya can use the answers to create a score for each company. When there are a bunch of similar companies, that all seem to offer the same services it’s always hard to compare, so it helps turn things into scores that can then be compared objectively. However the responses of the survey should also give Priya some idea about the company’s way of doing things, their culture etc.

We’ve given a template for such a survey as a spreadsheet (part of the download with this post). This will give an idea about what are good questions to ask in a survey like this, however each product and situation is different so the actual survey will probably need some tweaking. Separately it also makes sense to run the survey with a survey tool like google survey or surveymonkey

4. Call the top 5 companies and do a call. Score the experience

Now that Priya has 4 scores for each company from #1-#3 above she can get the top performing companies in that list of hers. Note that the scores are not all the same, they need to be weighted on the aggregate score. This is because a reference from a friend you trust is obviously a more reliable score than a random email thread that went wrong (maybe the person answering that email was a new employee who didn’t know the process…). We suggest a weighing in our template (downloadable below).

Priya can use the scores (and also her instincts - she may have liked a company much better than their score) to select a few (5-7 is a good number, too many is a time waster, too few is a bit risky) top performers and ask for a detailed call to discuss her current requirements. The verbal conversation is important as it will double check on communications. It will also let Priya test how pro-active they are. Note that this is not the call to discuss the product in detail or give them the rough spec (from step 1) to give estimate. That will be step 3. The reason Priya should delay that discussion is that she should get a non-disclosure agreement (NDA) done and also she doesn’t want to go through the time consuming requirements discussion with so many companies. Her goal is still to filter out maybe 2-3 companies with whom she will get to step 3 level details.

5. Calculate a final weighted score

Now that Priya has 5 scores: Online presence, reference, email, survey and call, she can do a total score. But not all the scores are the same value - so a simple average won’t be a good idea. We suggest making weighing reference and the call the most. Here’s our suggested formula for the weighted average score (it comes with the downloadable template spreadsheet at the bottom of this post):

Weighted average score = [online score + (3 X reference score) + (2 X email score) + 3 X survey score + 4 X call score ]/13

Moving forward…

Now, at last, you have a spreadsheet with a list of software companies that are scored on their merit and you can do a simple sorting on the total score to select the top ones that you will actually spend time with to explain your idea and get them to give you an estimate - a “ballpark” price. Reason it’s still ballpark is that most companies would only give you a final “fixed” priced project if they do a more detailed specification with pictures etc. That takes time, and you only want to proceed to that after you know if the pricing will fit with your budget. A ballpark estimate helps you in this regard. If the ballpark is something that you can fit into your budget then you get into the next step, if a company that scored high yet gave a ballpark estimate way beyond your budget (happens a lot, software price varies wildly because of all sorts of reasons) you’ll need to get them out of your list. OK, onto the ballpark estimate then…

But that’s step 3. So we are done for today!

If you liked this, try out the founder’s power pack that we are putting together to help all founders in their journey through the software development process. Click on the image below to know the details.

The Quality of Software

When Oneplus co-founder Carl Pei appeared in a video with American Tech guru Marcus Brownlee, he showed off the prototype of the Oneplus Nord design, spoke honestly about the choices they made and broke kind of a fourth wall between the accessory makers and the consumers of the brand. Among the many aspects they discussed one hit me home, the fact that they are cutting about forty dollars’ worth of testing to get the ip68. This seems to have become the norm in the outsourcing industry. The customers want an Airbnb looking site and they can get it affordably.  It is a good deal. But just like the Logo, homepage or product catalog is important to the business, similarly important quality aspects which may make or break the business remain less understood and not well communicated from the provider’s part. It is because the frugal entrepreneurial handbook guides the business to be economically lean from the beginning and the provider is in a competitive market that often prioritizes agreement over proper counseling. There is a case to be made for quick business solution but as an engineer concerned with quality nearly half a decade it is incumbent upon me to try to inform both the solution provider and the valued customer about the pitfalls of the treaded path.

Sacrificial Testability

The first victim of removing the quality concern is the architecture is then designed with testability in lower priority. Even for the moderately tech savvy customer it will seem like a matter of no concern and it will therefore be reflected in the quotation. But what they should know is that it is the first step for the application is taking towards failure in case of success. It means for them that the application while look as pretty as any of the best looking sites but will not preempt failure in case the business application is as successful as it hopes it would be. Succinctly said, software written with non-testable code means that, failures/bugs will be an ever increasing problem and will reach the threshold only when you know enough to rue the problem.

The Performance Quicksand

A successful delivery of a Share market live information site, a betting app or a simple e-commerce site is something the valued customer would accept, applaud and give a glowing recommendation too. It certainly checks all the boxes of the SRS. But then it might be outdone by the competition, failing to retain users or get user reviews concerning slowness that they can’t seem to put a finger on. A performance engineer would point out the fact that the average response time is of the Share Market info is way slower than the competition, or the betting app is becoming unresponsive at a certain peak time or the e-commerce sites various modules are performing inconsistently. He might plan out a way to identify these issues before the development phase and help the dev team solve the issue when they arrive. It might not seem like a good investment to the entrepreneur looking to cut development cost but it would be incumbent upon the solution provider to inform the hidden costs to actually performance tune after it has been launched. Which, I have to add, is a lot more than addressing them in the first phase.

The Tested Software Fallacy

Again with the idea that software development should be in tuned with the business, I will propose that not all of the features have critical business aspects. For example a E-commerce site can live without the Wish list feature but will sure face huge losses if the purchase feature is broken or the search is not returning the right results. Yes, the manual tester might be expected to catch these errors but at the time the product is in production it might be too costly to handle. This is particularly important when a live product is under maintenance or is getting enhancement. So an experienced QA would suggest a business critical (risk factor driven) UI automation process to be integrated in the software development cycle which basically ensures that the new toy doesn’t choke the baby.

Hypothetical usability

Those with better accumulated focus group data could easily identify the core desire of the customer and use it against the next competing product. User Acceptance Testing does something similar; it gives a reaction from the end users about the site. In the book “Hooked”, Nir Eyal points out the importance of returning customers. Plenty of Software with technological advantages are failing because of the lack of emotional response from the user.  Even in the case of blue ocean market ideas every business not getting the edge by collecting real user based data will be outdone by someone who is going to use it. But the customer often overlooks the fact that this kind of testing might be way cheaper than to hire a focus group while the business is running.  What they don’t know might just hurt them in this case.

In the end Oneplus did what they do best to break into a saturated market, they did it not by doling out fancy new technology but assuring quality where it mattered. The part Pei was mentioning was actually a smart move considering they prioritized the software experience over durability which makes the device popular. It took some time but they edged out their place in the pantheon of high end smart phones. By making informed decision of assuring quality of the business critical aspects of any solution both the software solution providers and the potential solution seekers will be benefited with better business outcome. That I think is the writing on the wall we finally need to see.

A killer tech CV that no company can refuse

Our last blog post about cool beginner web projects was a super hit! Over a single day we had dozens of email asking for more ideas, some suggesting even cooler projects and others saying we should put up example codes. Thanks everyone for their suggestions, ideas and critique. Staying on the high note, I decided I should describe an ideal resume concept for software developers: A CV which is itself a show of skill, which is a CV - I’m calling it the:

“The Recursive CV”

The idea is pretty simple, and I’m surprised that I’ve not seen anything like this yet. Let me explain what I mean by a recursive CV and why it’s great. But before I do, let me also go over a big problem with the concept of CVs that currently exist.

Problem: CVs are not proof of skills

All CVs look the same!

It’s true. On an average we receive at least a hundred CV a month, and if there are job adverts out that number reaches a thousand easily. On a surface level most CVs look different, they have different formatting, their content is different (obviously!) and structurally they are similar, as they should be to some extent. They have the usual contact detail, experience, skills, references, etc. But the way they are all the same is that there is almost impossible to differentiate one candidate from another based on the content of their CV. They all tend to have similar skills, more or less similar experience blocks, almost the same number of references. So when we are looking for a particular experience set (e.g. C# web development) and a particular experience (say 3 years) we end up with literally hundreds of CVs that are equally a good fit. It’s impossible to go over all. So we take shortcuts, every employer does. Each of us have some tricks, secret hacks that are essentially heuristics. For example I check if there are any misspelling of technology names (e.g. .net instead of .NET) - very superficial, I know, but we have to find some rationale for not doing hundreds of hours of interviews :)

The big question we always have for tech CV is:

Does this person really have the skills he/she is claiming to have?

And I’ve rarely found a CV that answers that question by itself. There are exceptions, I remember a horribly formatted CV with several misspelling of technology names that I was going to delete right away - but I happen to see the last line of the CV that said: “I implemented a .net based JVM, here’s the link…”. Thankfully, I noticed it. The guy turned out to be a freaking genius named Maruf Maniruzzaman, who as it turns out doesn’t need to write his CV well. He ended up being directly hired from us by Microsoft, and now does rocket science level robotics programming at Amazon. Btw, he is coming to our deshi tech adda next Saturday (see the poster here for more details).

OK, I’m digressing. Back to the original problem: it’s not easy to find proof of skills in the typical CVs.

Solution: Make your CV a proof of your skills

If you could come up with a CV that was by itself a proof of your skills that would make things so simple for everyone. But how? Well, this is what you’ve got to come up with ideas. But here’s an example of such a “recursive CV”:

You write a little Javascript app that shows your CV as an interact-able web page. You could have the timeline of your experience, have fancy fold outs and fold ins that show information but also shows your CSS and JS skills. Maybe a search that shows how good you are with suggestions. A skills tag cloud that can lead to GraphML based viewer to show off your project experience? The options are limitless. What would be great is if you could show how you are doing each piece of the CV, some code snippets, etc.

The CV itself is a show of your skills.

If you want a hint or some starter code to move in this direction here are two great example codes:

Building a Vertical Timeline With CSS and a Touch of JavaScript

CSS Timeline

OK, that’s it for now, hope this post will help you to think something new about your CV. If you make something make sure you send us your “CV” to hr@kaz.com.bd we are always on the lookout for people who are different and exceptional.

Cool web projects for beginners

Today’s post will be slightly different from our usual topic of helping startups, software teams and company culture. You gotta do something different sometimes, right? And this topic comes from a lot requests from CS students and fresher software engineers who wants to pick up a “hobby” project that'll teach them some interesting things. These projects are really important for freshers because:

1. Perfect thing to practice and improve coding skills

2. Great for playing with new technologies

3. Awesome thing to mention in the resume!

Plan on using an up and coming javascript library (e.g. ReactJS, etc.) or a new new library in your favorite programming platform. The goal should be to learn something new while doing a fun project. So here goes, our list of cool beginner projects.

The Image Manipulator

Every web developers need to become a guru in manipulating images. Any good web app these days rely on some kind of images tricks and gimmicks.

Features

The image manipulator can be a bunch of image operations tool. But the first feature to focus on should be image rotation. Here’s how the first version can be like:

1. It will start by displaying a square pane showing an image in a 2x2 matrix.

2. A set of up, down, left, and right arrows next to each of the images the user can flip them vertically or horizontally.

Challenge

You can only use native HTML, CSS, and Javascript. Image packages and libraries are not allowed.

Hints

How TO - Flip an Image

The Book Finder (using an API)

The book finder is an application that lets users to search for a book. The user can type in any text such as the title or author of a book and the app will display the resulting books in a list on the page with small thumbnails of the books.

Features

1. The home page is a google like page with a search box where the user can enter any text.

2. When the user submits the search, the app will call an API (see below for possible candidates) that will return an array of books and show additional information about the books.

Challenge

Make the app a single page application (SPA).

Hints

Google Books API

Is there an Amazon one? Does Google books API give you thumbnails?

Memory - Card Game

Have you played this game with cards? It’s a card game where you have to click on a card to see what image is underneath it and try to find the matching image underneath the other cards.

Features

1. The app opens up with a home screen where the user can see a grid with n x n cards. All the cards are faced down initially

2. The user can click a button to start the game. When this button is clicked, a timer will start

3. User can click on any card to show the image it. The image will be displayed until the user clicks on a 2nd card.

4. When the User clicks on the 2nd card:

   a. If there is a match, the 2 cards will be eliminated from the game.

   b. If there isn’t a match, the 2 cards will flip back to their original state

   c. When all the matches have been found, the User can see a dialog box showing a Congratulations message with a counter displaying the time it took to finish the game

Challenge

Only HTML, CSS and Javascript allowed.

Hint

Example project

History chart for GitHub

This project, a bit advanced but fun will provide a visual history of a users GitHub activity.

The goal is to produce a timeline containing each repo and annotated with the repo names, the date they were created, and their descriptions for a user of GitHub. This is a great great project for the resume since it can then be shared with a prospective employer. Of course, only public GitHub repos should be displayed.

Features

1. The app starts by taking in a GitHub user name

2. Then the user can click a ‘Generate’ button to create and display the named users repo timeline

3. There needs to be validations for wrong user names etc.

Challenge

Stick to HTML, CSS and Javascript if you can.

Hints

GitHub has two API’s to access repo data.

Documentation for the GitHub API can be found at:

• GitHub REST API V3

• GitHub GraphQL API V4

Making your software: Step 1 - A rough specification

Meet Priya

Priya is a successful interior designer. So successful that she just can’t find time to serve all the projects that come her way. She has a brilliant idea about a software solution that will be able to scale up her operation. A mobile app where many of her customers can actually do their own interior design planning work and then reach out to professionals like her to put the finishing touches to the plan. She knows it will be a great hit, but she has never worked on software project and has no idea where to start.

This series of posts is to help people like Priya. To help her walk the many steps that lead to a successful software launch. This is the story of her journey, with today’s post as the first step she needs to take - create a “rough specification” - a list of features for her software. This list of features will help her explain what she wants her software to do. She will need this for software developers who will build her app and for investors who might fund her.

A name for her product

It’s best to start with a name.

A name of the software project makes life easier, Priya will not constantly need to say “oh that software for helping people do interiors” - she can just use the name. The name doesn’t have to be final, she can stick to a temporary name and use a name that’s different later on. But it’s important to think of a name that gives a feeling of what the software will do. This thinking of a name helps to kick start the thinking for the software’s feature list work too. And, if she can think of a great name that she will use in the real product she can actually buy the domain too. Giving a name and buying a domain actually helps make the project feel more real to her.

After some soul searching Priya decides to name her software “Designly” but decides to buy the domain later as the exact domains were not available (this would be true for most names you can think of - selecting the domain name will take some imagination!)

The user goals

The next thing Priya has to do is list out the goals of the Designly: what will her users achieve when they use Designly. This list is usually called the “user goals”. By listing the user goals out first and keeping them in mind when she thinks about features she is ensuring that she makes Designly useful for her users. Here are some example user goals for Designly:

1. Users will be able to design their interiors without getting expensive professional help.

2. Users will be able to quickly try out variations of their designs and colors.

3. Users will be able to find great interior designers close to them if they need experts.

It may take a few days of thinking to come up with the user goals list. It’s best to give it the time, to think all the goals through, as some goals are not quite obvious, yet after writing out some of the goals they may come out as obvious goals. Here’s one that may make it in Priya’s list which might not be too obvious at the beginning:

4. Users will be able show their designs to friends and family and ask for opinions.

After all, a great value for a software like the one she is planning is that people can try out designs and check how others feel about the design - just as we do in real life for other things.

The user stories

Now that she has the goals listed out she has to come up with a list of how the user achieves those goals. This is usually called user stories in the software world. If she lists them out in a nice easy spreadsheet her software developers would love that. This is what their product analysts have to do anyway and she is just fast forwarding the whole process with her list and also saving a bunch of money.

Here’s a way most software developers like to write these user stories. It all comes from the Agile principles of software development, and it’s worth reading up about this a bit. This agile way of making software is the best for a startup project like Priya’s. So here’s how Priya needs to write the user stories, she should structure each of the stores in the formation of:

"As a ………………. I ………………. , so that ………………. ."

Here’s an example from her product:

"As a home owner, I want to easily try out different colors in my room’s design so that I can see what combination works best for my room."

Since there’s likely to be a whole bunch of these user stories with some of them more important than others it’s good to have them in spreadsheet with the columns laying out the structure and with additional columns that can give other information. We always tell our founders to keep it simple, it’s important to get the thoughts in place rather than worry what’s the right and the wrong way of doing things - since there is no right or wrong. Here’s an example of such a spreadsheet:

A picture or two

With the list of goals and stories Priya would be miles ahead with her software project. She would have something to talk about with software developers or investors. But one extra little effort would magnify her effort by a lot - creating some pictures. You know how it goes - “a picture says a thousand words” (btw, if you ever wondered, that line is originally from Ibsen - morphed into what it is now). In the software world pictures are needed not only because of the thousand words, but also because they might tell the right set of words. Here’s a great picture that explains this (again proving that pictures can explain things so much better! We’ve used this before in a related article that’s worth a read for Priya too: interface between technology and business).

Priya doesn’t have to do anything fancy to make the pictures. Even some hand drawn pictures of how she thinks the software might look like or interact will be a great addition to the rough specification that she is making. But we suggest a great tool that is used by professionals and non-software people around the world: Balsamiq It’s a really easy to use software that let’s you do quick pictures of software interfaces.

With a tool like balsamiq Priya can churn out some concept pictures about the software very quickly. They don’t have to follow any “software UX best practices” or anything, that’s the job of the UI/UX experts. But having these pictures does a double check on the list in the spreadsheet and also helps Priya think through how the goals and stories might actually be in a real piece of software. This understanding of the process of translating words into software interfaces, the difficulties involved and the thought process is invaluable during the actual process of making the software. It would help Priya understand the timelines, estimates and also make her very effective in giving feedback to the designers when they do the actual software interfaces. Here’s an example of how one Priya’s drawing might look like. Even this single picture would help the software developers so much to understand what Priya is thinking of in her software.

That’s it for this step. With the list of goals and stories and with few pictures of the software interfaces Priya is all done for her specification. Now she can find any software developer (the next step in her story) and explain what she needs quickly and ask them to give a price idea. I can tell you that any software developer she goes to will have a happy face when they see her rough specification ready for them!

If you want to use our template for the goals and stories, download it by clicking the button below…. Watch this space for the next one on the series that helps Priya find software developers for Designly.

If you liked this, try out the founder’s power pack that we are putting together to help all founders in their journey through the software development process. Click on the image below to know the details.

10 Steps to Making Your Software Product

You have a great idea for a software.

You want to make it and launch it. But you are not sure how to move forward.

This is one of the most common situations with first time software entrepreneurs. Things can be very confusing for software products when it’s your first time. Where do you find a good software company that will make the software for you? Do you first figure out how much it’s going to cost? How do explain your product idea well enough so that the software company can get you realistic estimates? How do you ensure that they keep their promise? How do you know if they delivered a good software product? What happens after the software goes live? What happens if it needs a fix or a change? There is a whole list of important questions that needs answers before you can really make up your mind and move forward.

But where do you start?

As a software company helping entrepreneurs like you for the past 16 years we know your pains. We’ve helped many entrepreneurs turn their dreams into reality and launch their products.

We want to share our ideas and experience in this new series of articles called the “Making your software”.

The Steps

Before you do anything, you should have a rough idea about the stages you go through to get your idea into a working software product. So here goes, the life story of a typical software product - from the perspective of the entrepreneur.

Step 1: A rough specification

This is just you (and your co-founders) writing up (or even better drawing up) what you want to build. Doesn’t have to be perfect, or even very detailed but the moment you start asking software professionals questions like how long, how much, etc. they will want this from you. So this is the first step.

We’ll go through some tools you should use to get the specification done and also provide you with a template that works great for a rough spec. Read the post at: Making your software - Step 1 - a rough specification

Step 2: Find and compare software developers

This is the most important step in the story. A good software developer (like us :) ) is the key to getting your product launched. They will guide you through the rest of the stages, giving you advice about where to compromise and where not to. It’s absolutely vital that you research a bunch of vendors and find the one that fits you the best. Remember that the fit needs to be with you - a vendor can be the best skilled, most experienced, etc. but if they don’t communicate at the same wavelength as you nothing will ever get done right.

In the upcoming posts we’ll go over the basics of what you need to look for in a software developer and get you a template form you can use to survey the vendors and then compare them.

Step 3: Getting ballpark estimates

Ballpark numbers are very rough cost estimates based on the specification (from step 1) you give to the developers. This number helps you figure out costs and plan your funds. Always get ball park numbers from developers you short listed from step 2. You’d think it makes sense to ask for a number for from everyone as part of step 2, but in most cases the number will either be too much of a guess or plain wrong. 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.

We’ll guide you through a series of questions you should ask and things you should clarify to the developer to get a good ballpark number.

Step 4: Budgets and funds

This is the nitty gritty of how much money you’ll need and when. How you’ll get the funds and pay the developers. We’ll do a post on typical payment strategies, expected costs throughout the lifetime of the product and financial planning.

Step 5: Select the software developer and an NDA

This is where you finalize the software development partner and setup how you will work together. 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 your protection for the idea about the product as the software company will require you to go over the details of your 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.

We’ll do a post in this series with a time tested foolproof process along with a typical NDA template that does the job.

Step 6: Brainstorming/wire-frames/mock-ups

Now that you have a software developer on board and a rough specification in hand it’s time to brainstorm the idea and turning that idea into a working piece of software. You start by pinning down the features into a list, setting priorities for the features based on business importance and technical difficulties. The goal would be to target the “lowest hanging fruits” first - do the features that your customers would love the most which are also technically easy. For startups this path is the safest, with the plan of rolling out a product fast and possibility of cash flow along with early feedback from real customers.

Once you have that list of features thought out the next step would be to create storyboards - pictures of the software and how particular features would work. The software company’s designers and product analysts usually walk you through this. They do these first without worrying too much about the exact colors by drawing them up on rough sketches - pen and paper works but a software tool is better. This is wire-framing. And then they start putting colors and logos on them to create mock-ups - the pictures of the exact look of the software. How much detail you do depends on your time-line, budgeting etc. But you absolutely need to do at least some basic ones to get an understanding about the features. At Kaz we do the preliminary part of this process free. Some companies charge for this too. So this is something you have check with your vendor to decide beforehand.

In this series I’ll go over some tools we use and give you templates for the features, specifications and wire-frames.

Step 7: Final estimate and a contract

Now that the software requirements are well understood on both sides (remember, your original idea and the exact reality of the software may have changed a lot during the brainstorming!) it’s possible for the software company to commit to a price. Usually the price is close to the ballpark number (our typical error margin is +/- 30%), so it shouldn’t come as a big surprise. But it’s always possible that the idea has evolved far from the rough spec you had (which was the basis for the ballpark). This is where both sides can sit and decide how to align things. One way is to break up the product in phases, and do the deliveries in phases to fit with your budgeting. Or you could be compromising on certain features (e.g. “let’s do the facebook integration later since it will save 2 weeks of dev time”) to reduce the costs. Once you have reached a decision on the pricing you do the contract. Again the actual contract is much less important than the relationship and the understanding of the project features and priorities, but obviously you need the legal paperwork. The goal in the contract is to try achieve something that’s a win-win for the ever changing world of a software product.

We’ll share a template that has been time tested on startup projects and discuss the important things to go over during this step on finalizing the price.

Step 8: Development

This is where the actual product gets built. The part we love the most! This also the most important, time consuming and expensive part of the full activity. So you absolutely have to get things right to optimize it and make sure the project moves along at the right pace, risks are managed and a process is in place that ensures that things are done over and over.

We are super experts in this space, and after a thousands of times on the merry-go-round of software dev cycles we have very specific ideas about how it should be done right. We’ll share them along with some reporting ideas in this series.

Step 9: Marketing Plans

Without your marketing plans you software launch will never work. This is something you’ll need to do in parallel to the development work so that you are all ready to go when the software is ready. You’ll need a lot of technical help in this regard - since a lot of the marketing will be digital marketing. User tracking, social media integrations, interfacing for customer support, SEO, etc. all need the software company to help you out in this process.

We’ll share a list and a spreadsheet to track these. You should use this to coordinate with the software company and also clarify the need for help in this front with them.

Step 10: Launch

Wohoooo! This is the most exciting part. But this part needs very good planning to get right. There are all sorts of things like hosting, domain pointing, social media assets, launch activity planning, advertising assets and a million other things to worry about. Make sure you plan this before hand with the software company.

We’ll do our typical launch activity run down with you in this series and provide you a spreadsheet and a “cheat sheet” for launching your first product.

Life after the launch

Launching of a product is really just the beginning of your long journey as a software entrepreneur! What you launch first is just the version 1.0. You have to then see what the market actually wants, what you got right and what you got wrong and then roll out newer versions of the product with additions, subtractions and most importantly modifications. At the same time the marketing and sales part of the story should take center stage - since if you can’t sell the product you will soon run out of money! Along this same path is the need for maintaining the software - fixing bugs, patching the hosting server or updating a mobile app for newer versions of operation systems (e.g. “Oh no iOS 14 has changed everything and we need to fix our app for it!”).

We’ll lump up all the million things that you are supposed to do as part of your life after launch into a post and give you some templates and plans to guide you through this life!

That’s it folks! It may look super complicated but I can tell you it’s not once you learn the basics. When you have a good software partner (ahem, like us :) ) it’s even easier as most of this they will guide you through anyway. Also watch this space as we do the posts over the next few weeks. We are always here to answer any questions you might have. Just drop us a line to ask using the button below. Our startup project experts are always happy to discuss your projects!

At the end it is an exciting and intensely creative activity that I know you’ll love. Remember, if you don’t do it now, someone else will soon enough, so now is the time!

If you liked this, try out the founder’s power pack that we are putting together to help all founders in their journey through the software development process. Click on the image below to know the details.

16 Years of Kaz Software: Why we make our screens private

There are some simple rules at Kaz, and one of them is:

Our monitor should always be private.

Why?

Because, we trust ourselves and we also understand the nature of our work.

We trust ourselves to do the the work that’s assigned to us without the need for tracking and monitoring by anyone. And we also know that as a software developer we can be extremely effective one day, churning out amazing algorithms in minutes and be totally useless the next day - staring at our screen and wondering what it’s all about. That’s how human brain works. Our creativity, our energy and our performance are sometimes influenced and inspired by something - maybe by a dream from the night before, an article we read or an act of kindness by a fellow traveler on our way to work. And in the same way our energy can be diminished another day by a bitter experience, a sleepless night or a random bad news on the TV. We know that our performance will vary, but we trust ourselves to give our best, to make up our lost time of our bad days with the lightning speed of our good ones. Trust helps us do that.

The fact that the company, our managers, our colleagues and our juniors trust me, with my screen hidden, makes me perform my best. It gives me the safety that I need as a human. It makes me feel happy.

16 Years of Kaz Software: The work smart and love work way

I think we have a weird relationship with work.

We honor work yet we hate it.

The society is awed by people who are workaholics, yet that same thing destroys lives and families. We would rather not work, yet we are at work most of our waking hours.

When Kaz started, we said:

it doesn’t have to be that way. Work needs to be something we love.

And our strategy was that if we can work smart we will love our work. That was the goal and that’s what we always stuck to, and look at us 16 years later. We have enjoyed each and every moment of those years yet we have worked hard, making hundreds of great software. It all happened because we loved our work and we worked smart.

No secrets here. I’m surprised every time I get asked about our little secret of how we make work so loved. How we achieve high quality in our software time and time. I’m surprised because there is no secret. It’s obvious, it’s common sense. Judge for yourself, here are some of those “secrets”.

Let people choose their work

This is the big one. Everyone has their own soft spot for tasks. Some people love writing up precise documents whereas most hate documentation. Some developers can only relax when they are doing algorithms yet some great developers I know would rather die than think of maths. If you can come up with a team structure, a work plan where everyone can choose their own piece of work you are on your way to creating love for work.

What happens to the pieces no one likes? Easy. Once everyone has got a pick of their own the left overs people don’t mind so much to divide up between them and just slog it. Try this, I have tested this a thousand times before and I know it works like magic.

Cut out the red tape

Red tape - all the “process”, sign offs, authorizations, email acceptance, form fillups or whatever time wasting, soul sapping, life destroying stuff that organizations have come up with must be take out. Red tape takes away the fun from real work. The only thing it adds is just delays. I’ve found that all the promise of red tape that is supposed to make a project work according to plans are complete myth. Throw them away and you’ll find that a group of smart individuals working on a project they love will always deliver on plan.

Say no to politics

Politics is when a team needs to appease certain groups within the company. Politics is when saying what’s on your mind makes things difficult for you in the team. Politics is the single most harmful thing that a project or a company can have, yet it is something that exists in most teams. Maybe it is in the nature humans. You have to work hard to keep politics out, but it’s worth it. Take it out and then work becomes so much stress free. And stress free work leads to work that you love.

Risk takers are celebrated (even when they fail)

I’ve kept the best one for the last. Working smart and loving work means you have to own your work. You have to be responsible for the decisions you take and you need to take them without fear. If you in a work environment where failure from a decision leads to huge repercussions and pain, you end up in an endless process of authorizations and double checking. This leads to wasted time, but more detrimentally to a feeling that you do not own the work, you just happen to be doing it for the company. A psychology like that will never get you smart work. And it will never get you great, amazing results.

OK that’s about it. Simple, isn’t it? For the past 16 years we have proven over and over that these simple techniques give you great results. This is our work smart and love work way of doing things.

A post from the past - Shadows of Sinensis

Shadows of Sinensis was our trip to Srimongol in Sylhet in 2009. Here’s what Ferdous wrote about the trip in our old blog…

Shadows of Sinensis

- Md. Ferdous Bhuiyan


Shadows of Sinensis, a memorable trip to Srimongol, will remain afresh in the mind of Kaz family. Fun-loving Kaz Family went on rampage to obtain unlimited ‘Furti’ and relaxation during our 3-day tour to Srimongol from 15 to 17 February, 2009. Eventful Srimongol trip offered us relaxation, fun and most importantly the joy to share with our colleagues and family members. The team of Srimongol trip encompasses each and every one of Kaz Family. Young stars of the team aged 3-month to 3-year provided the team with pure and refreshing entertainment in the lap of nature. All of us along with our spouses and kids looted the unlimited joy by swimming in the pool, climbing the mountains, wandering in the wilderness and having delicious foods.

Powered by 41-member, Kaz team reveals the sportive frenzy of Kaz family. Many of our enthusiastic players as well as cheering audiences enjoyed watching and playing Cricket, Badminton, Football and Table Tennis at daylight and even at night using light. Frenzied bedding accompanied by enthusiastic cheering gave the events a special glow.
Silence of the evenings was shattered with the sound of laughter provoked by lively ‘Adda’ and the melody of harmonica and songs sung by us ruled the isolation of night. Monotony or tiered is something that failed to touch the mind even for a second. Luxurious and well-furnished bungalows became the place to spend last few hours of night to start a new day with more enthusiasm.

A spur-of-the-moment decision fixed the day scheduled. Going to ‘Lawachara’ or finding out the tea-stall named ‘Nilkantha’ to have multilayered tea was decided within a few minutes with the urge to know the unknown. Such whimsical decisions to visit outside of the Tea Resort made the trip more attractive and gave us the chance to experience something new and adventurous. Those who were more attracted to water of appealing swimming pool were busy with swimming and diving throughout the whole noon.
Delicious Food must be there to color a memorable time. We the KAZ people vowed not to get hungry and have delicious good food with every single chance of celebrating party. There is no exception of this oath even at Srimongol trip. Being the fan of delicious food we grilled chicken and included delicious dishes for a sensational dinner and enjoyed the last night having spicy food and dessert.

Sensible traditional ethos of our firm revives with this lovely trip. And it would be no rhetoric to reiterate the truth that ‘Shadows of Sinensis’ is a great step forward for the neatly tied Kaz family to enhance its fellow-feelings and team spirit as ever.

16 Years of Kaz Software: How our fun party revolution started

Our guiding principle when we started 16 years back was:

We will build a happy place to work.

And every one of our millions of tiny decisions over the past sixteen years has been guided by this goal of happiness. Happiness is essential at work, especially when work is as creative as software development. So sticking to this principle is very important for us. It isn’t easy. There are many decisions you have to take in a business where you are forced to decide between money and happiness. But I’m proud to say in most of those decisions points we chose happiness over anything else.

Our first real test

Really early on, just a six months after our first real big project and after we got hold of some real money, finally, we had our first such decision point:

Do we keep the money safe for rainy days or do we do a celebratory party?

This was a time when our future wasn’t very certain. Yes, we did deliver a great product and our first customer confirmed that they would continue with us to build the version 2. But everything was still up in the air, the customer was actually starting to recover the huge loss they had, we didn’t have any new business leads, we had no idea what would happen in a few months, let alone years. Yet I clearly remember the decision process that went like:

What we decide today will set the tone of the company.

Are we courageous enough to stick with our goal of happiness?

Do we want to be exceptional?

or are we going to sell ourselves to mediocrity by playing safe?

When we were young! A picture at Cox’s bazaar from our first big party

As you can guess from that line of reasoning, we decided to be be exceptional :) and arranged for an all expenses paid 4 day trip to the beach town of Cox’s Bazaar, staying at the most expensive hotel there (at that time) and having lots and lots of fun!

You might ask, as I ask myself now - Were we fools? Were we irresponsible? Irrational?

The answer is always a big NO. That single courageous decision set the tone, fixed the music and set us on a path that we have been on for the past 16 years. Happiness above money. This single formula made us successful as a business but more importantly successful as group of humans.

That first party led to our tradition of doing lavish anniversary parties and product release parties. Celebrating victories is a basic human need for happiness and for renewal of energy.

Happiness is part of us

Our second party was a 12 day trip to Goa! And over the years we have done numerous trips and parties in Thailand, Malaysia, Bhutan, Nepal, India and all over Bangladesh.

We started a revolution that has been copied by many other companies around us. Yet when we started many warned us that this was not sustainable, it was a not business viable. They said that our enthusiasm and money will fizzle out as became more mature :) Didn’t happen for sixteen years, and I don’t see happening in the next sixteen :p

Some pictures from our trips and parties… you can find more at our facebook photos.

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

View fullsize

16 Years of Kaz Software: How we started

We turn sixteen this month! Sixteen years! Time flies so fast, it feels only like yesterday when we began.

It all started with a small startup company in silicon valley in big trouble. They were trying to make an innovative software that could save millions of dollars for big companies by helping them find the best routes for financial transactions. The idea was amazing and the founders were leaders in their industry. They had enough investment money, gleaming California offices, maths PhDs, technical architects and a dev team with great resumes. And best of all - customers were knocking on their doors, waiting for the software to launch. But the founders had a dark secret, they knew that underneath their shining offices and sparkling resumes something sinister was slowly eating away their dreams.

Their technical team was doing meetings after meetings, running technical discussions and creating documents, Gantt charts, presentations and project plans. But no usable software was there to show even after a full year. Every time a new build was promised something turned up that made the technical team reconsider their plans and adjusted their schedules. After a full year of trying they were running out of money and had nothing to show to potential customers.

The Last Resort

This is where we came in, a last resort. One of the founders knew somebody who knew somebody who knew us! When we finally met up on a sunny March day in 2004 at one of those great seafood places at Fisherman’s wharf in San Francisco the appeal from the founders was desperate. They were giving up on their current team completely and had just enough money left that could run our team for six months. Equally desperate were we to get our first big project, to keep us afloat. So we said yes without a thought.

That yes led to a realization a week and a marathon code review later that the only way forward was to write from scratch. Six months to build and deliver something with a team of four that a team of nine couldn’t do in a year! Great challenge, but we love great challenges!

So that is the beginning. It has a good ending. We delivered two weeks ahead of time, with more features than the original list. We helped the lay the bricks of a company that is worth millions now and leads the industry in that special niche.

Here are some some pictures from our early days…

Software beyond the pandemic: What happens to 5G?

Would you believe that there was/is even a conspiracy theory that 5G caused coronavirus! The theory goes that the radiation from 5G towers triggered the virus. Very imaginative! But my post today is not about a crazy theory, it’s about how the global pandemic affects the pace of 5G technology adoption.

5G was definitely the flavor of the month before the virus took center stage. Every tech conversation around connectivity led to 5G and how life as we know it will change when 5G becomes widspread. 5G, or fifth-generation connectivity, will provide amazing fast internet, 100 times faster than 4G with better network reliability. Enhanced connectivity will bring new way of doing things, new technology, like self driving cars, drone delivery, AR/VR/XR experience like movies and sports events or games.

5G roll-out delays

5G network roll-out across the U.S. will definitely be delayed significantly because of the global pandemic. Network operators that buy 5G gear will changing their business plans based on demand and the supply chain of telecom equipment, mainly from China will be affected. Vendors such as Huawei, Ericsson and Nokia will see much lower sales than were projected just months ago.

For 5G connectivity to take off the whole equipment and network ecosystem needs to working in synch. And 5G hardware — phones, chips, etc. — has to start in full pre-pandemic levels. With the supply chain severely disrupted, hardware production has been affected and with most of the world preoccupied with the immediate worry of the virus the consumer interest has fallen too. All of these aggregate to the an overall delay in the technology adoption.

The use of 5G in factories, storage, distribution and ports is one of the big driving force for it’s adoption in the business space. This delay is a big blow for businesses that were planning for improvements via upgrades to a company’s wireless network.

Only a temporary setback

Ultimately, there will be pent up demand for 5G among companies that want an edge. Businesses will be looking to be more productive and gain ground by modernizing their IT systems, collecting more data than ever and automating as much as possible. That includes lights-out manufacturing, in which factories keep humming with no human presence, thanks to 5G-connected hardware and software.

Also the virus has forced us to lockdown and work from home. Which is showing to everyone that this new way of working and living is possible. Remote work could very well become the norm with office spaces being exceptional. With this way of life the need high-speed connectivity will become essential infrastructure need for business and communities to operate. The pandemic has shown that the current network infrastructure is not enough. Large scale remote work has strained household networks and points to the fact that the network technology needs to upgrade to fit with this new way of doing things. Which leads to 5G. So it is only a temporary setback for sure.

So we wait for this fabled technology and dream about those real time VR games that we will play one day!

Can a software company be 100% WFH?

The global pandemic has pushed us all to working from home (WFH). And overall across all industries WFH is proving to be a viable way of working. For the software world WFH was very common anyway, but now will complete WFH for months is showing to many that WFH works and this could be the new way of working with or without a global pandemic.

This has led many to ask:

Do we need to work at an office space at all?

We see a reflection of this thinking in big software companies already. Facebook and Shopify has already put out clear strategies for this change mindset about office space. A recent tweet from Tobi Lutke CEO of Shopify puts this succinctly:

As of today, Shopify is a digital by default company. We will keep our offices closed until 2021 so that we can rework them for this new reality. And after that, most will permanently work remotely. Office centricity is over.

— Tobi Lutke 🌳🌲🛒🕹 (@tobi) May 21, 2020

Mark Zuckerberg did a longer version of the same thinking in Facebook post (of course)…

Our experience - WFH is great

At Kaz Software our experience has been extremely good with the 100% WFH mode. We posted recently about what we’ve learnt after two months of full WFH. Going by where we are we know that 100% WFH at all times is something that we can sustain very well. The time savings merely on the journey times on Dhaka’s infamous traffic itself justifies the WFH move.

But…

However, we also feel strongly about the need to be together as a team, working side by side. There is something in nature of work, nature of us being human that makes face to face interactions inherently better for some type of tasks. Here are some tasks we know we’ll have to revert to working together at the office.

Brainstorming software features

Brainstorming just doesn’t work the way it should in a virtual environment. There is something in the energy and enthusiasm in face to face discussion, something in the hand gestures of an excited colleague or heated argument about what is a good software and what is not, that is completely missing in the video calls. You just cannot do great brainstorming session without bring the team together.

Software UX/UI design phase

When you are designing UX as a team the constant to and fro between the designer and product manager or the developer is what drives the design forward. You take that out, move that into regulated video calls you will lose the creative spurts that happen in those face to face interactions. We would never want to take that out from our work, and this would be another phase of work we would always keep as a time to get together at the office.

Technical planning and architecture

Technical architecture and planning is something that can be done fairly well on the WFH mode. In fact some part of, it where a single architect is designing the overall blueprint, are best done alone and WFH works just fine for that. But when it comes to discussing the pros and cons of an architecture, debate out technology choices video conference calls fail miserably.

QA cycle

On intense QA and testing cycles of a project the constant need of the SQA team members to talk with developers, show them in action what is wrong, articulate their emotions of frustrations when a bug reappears or happiness when a bug has been fixed is something that can’t be done remotely. An intense QA cycle is very much like sports, where the developers are competing to create a bug free product or fix the bugs fast and the SQA team is working to find the bugs. The pace, the excitement, the mechanics of such a phase of the software development cycle just falls flat on remote teamwork.

So WFH is great. It’s here to stay. At Kaz we are prepared and committed to work from home as long as it takes. But we are also thinking of changing how we would work beyond the pandemic. WFH will be part our practice for sure, but we would also ensure that we work from office too. If you are in business of creating great software, as we are, there is no way but to meet and work side by side sometimes.

Stay safe!