Software development with Unity

Unity is now a leader in games and any application that requires 3D visualization. It’s a platform that’s stable, has huge developer community support, great tools, very helpful documentation and an ever increasing software developer group - thus a superb ecosystem. Today’s post is an overview of this platform that we love and have been working on for several years. We’ll share our own experience along with a more generalized survey of the ecosystem for anyone thinking of moving to this space.

Unity the game engine

Unity started in 2005 with a very specific goal:

"democratize" game development by making it accessible to more developers

From the beginning the the focus has been on making a tool usable by everyone - be it in ease of use or be it in cost. And this focus has enabled Unity to achieve the great level of adoption it has now. Over the years Unity ecosystem has developed in to one of the most extensive in any programming ecosystems. Here are some of the big highlights of that ecosystem.

Multi platform support

Unity’s greatest feature is single code base that can target multiple platforms. So a developer can build an app for desktops, mobile devices like iOS or Android, Consoles like PS4 or Xbox, AR/VR devices, etc. all with the same code base.

Easy to use and learn

This is Unity’s biggest thing - it’s just simple to use. Within a very short time any software developer can have the environment setup and ready to create really complex games. Unity leverages on existing programming languages (C# and JS) and developer’s favourite IDEs. Thus the learning curve becomes very flat very soon. This makes the decision for trying out Unity for a software development project very simple as a test environment can be setup quickly and developers can try things out fast

Documentation, tutorials and templates

A big highlight for working on on Unity it’s support for knowledge. Developing a game in Unity is a smooth learning experience with accessible online tutorials and learning materials that Unity itself provides. This is then augmented by literally hundreds of other free tutorials and training resources from third parties. Specially valuable are the numerous YouTube channels dedicated to Unity development. It really helps an a new developer starting out her journey in the game development.

Video tutorials are particularly rich. Unity itself has hundreds of such video tutorials that go over in details of building fully working games. Apart from these tutorials and standard documentation Unity supports and continuously grows it’s library of template projects. These are backed up by even more templates from the Asset store (see below).

Awesome forums and community

Online forums are extremely strong for unity. The large community of Unity developers almost guarantees that any problem a developer runs into is already answered or can be answered very fast. Most of the larger forums are monitored by the Unity staff to support and answer questions directly from the makers of the platform. This overall support mechanism helps build the positive feedback loop of the community. Making it so strong. Unity’s own support portal: Answers.unity.com is a great example of how company supported public forums should be. Other forums include the good old stackoverflow’s Unity area, forum.unity.com

Rich marketplace for assets

The world of Unity comes with a marketplace where you can buy (or in many cases download for free) great assets (graphics, game objects, code, even full games). The Unity Asset Store is loved by game developers because it rich collections of pre-designed graphics, game objects and many more. The overall impact of having such a marketplace at your fingertips is the rapid pace of development in your project. Whenever you stuck for something - be it a new character in your game or some funky code or game logic you’ll probably find something in the assetstore to help you. This just speeds up your development by a large margin.

Flexible Licensing Model

Most projects and companies can start using Unity for free and then pay as they grow. That is the philosophy for Unity’s licensing. Most game engines are expensive have the most rigid licensing rules. This is just not the case with Unity. The Unity game engine, despite being a top platform remains at an affordable price, as compared to others. The free version has enough features get most of the common software projects and games off the ground and an upgrade to Pro version at a an affordable price brings in a whole pack of advanced features.

Analytics built in

Unity comes with built-in analytics that a game developer can use to setup their analytics. The engine is comprehensive and covers pretty much all the basic needs of analytics for discovering insights about the game and it’s usage.

With such great features it is no wonder that Unity-made applications were used by 2 billion monthly active users, with 1.5 million monthly creators! Unity is there to take over the game development space and it’s a platform to reckon with. So if you are thinking of working on a game or a software that requires 3D visualization then give Unity a spin.

Mobile app development in Bangladesh

Freelancers in countries around the world.

Bangladesh is becoming a force to reckon with in the software development space. Over the last decade or so the digitalization of Bangladesh has been fast paced. Internet access has become norm for any area in the country. This has led to online freelancing as a viable way of working and earning a living. In most recent surveys on freelancer Bangladesh comes up in the top 5 countries. One major segment of the freelancing community is the software developers and a significant proportion of those developers are mobile application developers.

Most freelancers move to a professional career - creating a strong workforce available to the local software industry with ready skills to pick up software projects including mobile application projects. On top of this hands on skills, every year the number of IT graduates coming out of higher education centers around the country is significant leading to constant stream of technical skills being available to software companies based in Bangladesh. In an extensive study financed by the government the increasing trend in the employment in the IT industry is clearly visible.

Mobile application development is a key focus of most of the software companies in Bangladesh. This is because a significant proportion of software development work coming into the country has mobile apps development as it’s main focus or is at least a major component. This has led to companies specializing in mobile apps development in many technologies and industries such as small business mobile apps. Here are some of the key skills in mobile application development that companies like Kaz Software works on:

Native

Native development in Android and iOS is still the most powerful way to develop mobile apps if complete platform capabilities are required. We have been working on native platform pretty much from the first version of the developer SDKs on both platforms (and actually on the Windows Mobile platform and the ancient Symbian platform when they were still alive!). Although powerful the are not our typical choice as the codebase needs to be separate for each mobile OS leading to more work and cost.

Flutter

Flutter is fast becoming the top cross-platform mobile application development technology. Using the Dart programming language opens for fast forwarded dev cycles. It’s led by Google with it’s open source cross-platform SDK supported by plugins. Application development in Android and iOS is made easy and fast in this platform and it is the platform of choice for any new project.

Ionic

Ionic is based on HTML5. It’s a widely used technology for mobile app development today. Integrating HTML, CSS3, and JavaScript the platform can be used to build native apps. It leverages on iOS’s UIWebView or Android’s WebView. And it is built on top of Angular JS and Apache Cordova.

Xamarin

This is a cross-platform mobile application development framework that uses C# uses. Building apps for iOS and Android with one codebase that is in .NET means that the knowledge and skills of a .NET team that is otherwise involved in web development can be utilized.

Bangladesh is a great destination for software development in the mobile platforms. With such wide range of skills and in depth experience in a wide array of native and cross platform mobile application development it is a country that is coming up fast as one of the top destination for mobile apps.

If you have plans for making a mobile app, we can do it for you - and the good news is that it shouldn’t cost you an arm and a leg :) Drop us a message with the form below:

Get an estimate for a mobile app

Top 5 challenges of building an effective software team

1. Finding the right people for your team

This is without doubt the hardest challenge. Finding skilled software professionals is hard, but find the people who work can work together is even harder. Although this is the hardest there is no way around it. The success of any software project depends on one factor - how good the team behind it is. We know this from our experience in working with 100s of software projects over the past 18 years, but research and data in this area also shows this fact. In their comprehensive study of software project failures published in Software Development Failures: Anatomy of Abandoned Projects Ewusi-Mensah, K. showed that factors related team composition and team dynamics comes up very high in absolutely every single software project that has failed in their group. Similar connection with team related factors are found in other studies too. A good summary can be found in a paper titled core factors of software project success.

Table comparing softwre project failure causes from paper: https://www.researchgate.net/publication/330290988_Core_Factors_for_Software_Projects_Success

You need to focus both on the skills of the individual resources and the fit of the resource between each other to find the right team. A mix of skills is very important, so as you are composing the team work on looking at individual potential candidates and map out their skills - both technical and soft skills. Find a balance where you have various technical skills spread out along with the soft skills. An example could be that for a web development project in .NET you should look for people with core .NET programming skills but also add people with database, javascript, UI/UX skills. And again on the soft skills front you should have some members of the team who are good communicators, some who are good mentors and some who can run a debate well.

2. Getting your software developers to communicate effectively

Once you have the right team your next big challenge is to setup a system, a workflow and a culture where commutations happen in a flexible and free form way. You want multiple channels of formal and informal discussions. You’d want formal structures like team meetings and brainstorming sessions coupled with informal channels like a talk in front of the water cooler. At Kaz a great place for informal communications is the team’s own break space - we call them ip - interaction points. Sometimes it’s a veranda with some chairs where team members take their tea/cigarette break and has a chance to discuss something that’s bugging them (sometimes its about the the project too!).

It’s vital that your team should communicate effectively. Many a great software team has produced failure by the fact that the management made it too difficult to communicate - maybe with too many formal meetings or too few.

It’s hard to suggest a winning formula that works for every team as every team is different, every project is different. And add to that mix the WFH and remote work you have an even more complex problem. Work with your team to make sure there is effective discussions happening. Check back regularly on the health of that communications.

3. Developing a process that works for everyone on the team

Once you have the #1 and #2 sorted out you are half way there. The rest is pretty standard operations setup but it’s still super important to get things right. The top thing on the operations part is setting up the workflow.

A software development workflow involves all the nitty gritty steps of getting the software requirements, specifications, planning, distribution of work and then getting that work done in phases. The catchall word for anything related to software development workflow these days seems to be “agile”. But saying “agile” is not good enough. Setting up a workflow - if it’s driven by the concepts of the agile methodology that’s great - is important. Again, the thing to remember is that every team is different, every project is different and every company is different. The “agile” that’s right for you might be different from the “agile” of a different team or company. Plan the workflow that fits with your circumstances. For example, if you working on startup’s proof of concept project and entire future of the startup depends on showing this POC fast to it’s investors so that they can get some funding to actually build the thing - having a complex process for creating and tracking tasks that has to be reviewed at multiple steps is going to be a disaster. You’d want a process that is fast, relies mostly on verbal communications and commitments and almost no red tape. The opposite would be true if you’re working on upgrading an existing ERP that a large number of customers relies on it’s day to day work and single breakdown can lead to a lot of trouble fore everyone.

4. Creating an environment where every member of the team feels valued, respected, and included

In the mode of efficiency and engineering that software projects tend to push us we forge that at the end a team is a just another group of people. They are no different than other groups of people in our daily lives - each with their own needs and desires. It’s vitally important that in the hectic pressure of the the project, the need to find great resources and in creating efficient workflows we don’t forget the fact that the team members individually and the team collectively needs to feel valued and respected.

The worst offender in this space is the high handedness management teams sometimes use to operate with development teams. They somehow feel that they need to command and control the teams - which just doesn’t work in the creative and intellectual space that software development projects work in. It’s important to we aware of this danger of detachment from reality and keep honest reviews on the company’s attitudes and processes to make sure that the team feels happy and motivated. Remember that in software a demotivated team is directly equal to a failed software - there is no mid point in this equation.

5. Balancing what's best for your company with what's best for the team

The last point is a delicate one. You might have the best resources, you might have a streamlined process with a healthy team motivation in place but you are still operating within a business. A business has priorities and typically it’s about money and short term goals. These priorities will always clash with your team’s health. Short term goals will mean over working the team, it might mean a burnt out team and it also might mean that team members pushed around various things in their project (something that developers hate). It’s not an answer to say that I don’t care about the goals of the company - as those very same goals make the ends meet and get the funds for everyone to live. And on the reverse it’s also not an answer to say that we’ll sacrifice the good of the team to make the goals of the company work. There has to be a balance somewhere. The team will have to compromise on certain things (e.g. maybe a special impossible deadline for funding) and the company will have to compromise on others. If you get the balance right you’ll have a wonderfully efficient team in place.

OK, lots of heavy stuff. Let me finish off with a stolen Dilbert :)

Sourcing your software talents from around the world

A brave new world has arrived. A world where the age old concepts of work, workplace, office, meetings and all things related to work has changed forever. And I’m not talking just about WFH. Sure, work from home (WFH) or as some people prefer to call it “remote work” has become accepted, in some cases become permanent, but I’m talking about a much bigger thing than the acceptance of working from home. I’m talking about a paradigm shift in our way of doing work. The past two years (almost!) has forced this shift in us - in most case without us fully knowing. The paradigm shift is the idea that - work can be decomposed, spread out to talents who can do them anywhere in the world and re-composed. Any work can be split up into little blocks, and those blocks can be done by anyone, anywhere in the world and then those blocks can be put together and made into a whole.

This new paradigm works wonderfully in software work. Software development was half way there anyway, with teams spread out, tools of work (like the source control, servers) in the cloud, etc. But the pandemic just pushed the model further - specially to the skeptics (read management!). The formula for the new world in software projects is:

Step 1: Find talents anywhere in the world

You don’t wait for the talents in your neighborhood anymore. All you need to do is decide what skills you need to get the job done and then find a source for the talent online. There are freelancers and consultants available on sites like Upwork or Toptal or if you are looking for a more professional team that can take care of the whole blocks of things for you (and if need be the whole project) then you find a reputable company on a site like Clutch or you can rely on software company like us (shameless plug, but not too bad an advice).

Software is the same everywhere in the world - that’s the beauty of standardized syntaxes and compilers. So why wait? Treat the entire world’s software skills as yours to pick from - exactly like shopping from Amazon instead of your corner store!

Step 2: Bring them under your project’s virtual roof for a set period of time

The set period of time is the beauty of this new world. No longer are you tied to huge burn rates and HR overheads. You slot in the right skills at the right time and slot them out when their job is needed. If you can get the right partners and the right tools in place then it’s like magic - suddenly you have access to hundreds (if not thousands) of resources whenever you need them. It’s like being Microsoft on a puny budget!

Step 3: Get your software made!

Of course! This part is the same as before, well mostly. You will probably need to do a bit of composition with the blocks - that is bring the outputs together for the final software. In all likelihood you’ll probably do it the old style way but this too can be done in the new way of doing things and just relying on the resource cloud that you have in your hands!

The brave new world is great. The world is your oyster now. Happy software development.

Psst… if you want a great software team to help you make your software give us a shout at info@kaz.com.bd or just use box below to send us a message :)

Why do software projects fail and how to save them

A recent post about making software project plans that work started a thread of conversation with a fellow software guy about how true it is that software projects are prone to fail and we should just accept that fact and plan around that. His point was that we should actually take a more positive attitude that software projects work out at the end and work from that positive space managing the risks. He does have a point, any work starting out with a negative thought actually leads to bad things - your thoughts are a thing as Napoleon Hill says in a book about wealth creation. And it’s a good question to ask - what is a better approach for software projects - assume failure and plan to manage it or assume success and avoid traps?

Facts & Data

Let’s look at the facts again. Research after research shows that software projects fail most of the time. A great source of software project health in general are the CHAOS reports published by the Standish Group. The CHAOS Reports have been published every year since 1994 and are great indicators of the state of the software space.  The 2015 report studied more than 50,000 projects around the world, ranging from small few man week software projects to huge thousand man year IT projects and system implementations.  The results show clearly the trend that software projects are failure prone. Take the summary pie charts in the report (shown below). The red is ominously present in all the three aspects that were judged - budget overflows, timely delivery and feature achievement. I agree that the green is also strong (note the error on the first pie though, where the colors are flipped!) but shouldn’t you the red to be much smaller on all those pies? With such large amounts of money spent and with companies betting their existence these days on their IT systems having that high percentage of red is not a good sign.

And don’t think this is a recent trend. Actually things have been getting better over the years. Software projects have always failed but the rate of failure is reducing (at least according to these guys). The stats show the success percentages are going up over the years, so that’s definitely good!

Why do they fail? And, how to save them?

This is obviously the million dollar question (I guess a billions of dollar question in this case). Every software project is different, be it with the requirements, the nature of the product, the nature of the customer and the nature and composition of the team that worked on it. So it’s impossible to generalized. But overall some common risks are seen in all software projects that can if left unmanaged lead to be one of the factors of failure. Note that I said “one of the factors” as most software projects fail not because of one single cause but a whole bunch of them, each stacked on the other. So instead of talking about generalized causes of failure, let me just claim that most software projects have the following risks that should be managed. It would not gurantee the success of the project but it would certainly make the project safer.

Bad project planning

In our experience, bad project planning is the biggest cause of software development failure. This is one area of engineering where project planning makes it or breaks it. You can have the best developers in the world, unlimited budget, time, documentation yet if you don’t plan things right, if you don’t plan things realistically you’ll just burn that team, eat up that money and time and end up with a bad software or no software. To take a recent software project that failed despite having everything ($1.7 billion budget, 1K+ strong team, etc.) is the US’ healthcare.gov platform. It was way over budget (original budgeting was $93.7 million!), severely delayed and very buggy even when delivered. Problems started as soon as it was somehow launched. Although it was known from day 1 in the planning that there will be huge demand, the huge hit caused the site to go down within the first 2 hours. While website user hit initially cited as the main cause (inexcusable as this was one of the given parameters) other problems showed up because the UI was not complete or confusing. Issues such as drop down menus not being complete and insurance companies information data not being correct or complete was a common problem. By some estimates, only 1% of people managed to successfully use the site on the first week. On October 20, 2013, President Barack Obama remarked, "There's no sugar coating: the website has been too slow, people have been getting stuck during the application process and I think it's fair to say that nobody's more frustrated by that than I am." It was all down to the poor project planning.

Work on that project plan. Read our recent post about project plans that work. And most importantly work with skilled project planners who has experience to understand the problems of a software project.

Lack of communications or excess of communications

Software is always a collaborative exercise. You need open channels of communications that are fast and reaches a resolutions quickly. The the quick resolution is also super important that is whey the excess of communication is something to worry about. You have to monitor that “analysis paralysis” doesn’t creep in just because there is a lot of communications possible.

Too many targets & unrealistic goals

Often the only things that pushes a efficient and streamlined software project towards disaster is the multiplicity of goals. A team can only do one thing at a time with a good quality. If you try to push them to do too many things even with the best of planning they will burn out over time and reach a point where it is only the team’s speed that hinders the success of the project.

Many great companies fail to understand this - they push their wonderful software teams to create great software one after another - pushing new features in, pushing new versions and upgrades in - at one point the team just breaks down. No matter how good your plans are or how good your communications channels are a burnt out team will always lead to failure.

Too large a team and too large a project!

Software project size and the team that works on them have an optimal size. Beyond that optimal size things don’t work too well. Communication becomes too noisy, mistakes start happening, people tend to lose focus and the wonder project plan starts to break down. Over and over research has shown that larger projects fail more than smaller ones. Here’s a table from that 2015 report:

If you have a large project or a large team - break it down to smaller projects with smaller teams that interact at set points to build the large project by parts. That is the only safe way of doing things - we know it from experience and data proves it over and over. I’ll finish with this quote from the report … says it all.

“... that size was the single most important factor in
the resolution of project outcome ... It is clear that the larger the project, the less valuable the return rate. In many cases larger projects never return
value to an organization. The faster the projects go into production the quicker the payback starts to accumulate. ”

— CHAOS Report 2015

Top 10 Questions you must ask your software vendor

Do you have any questions for your software vendor? You should. The standard stuff like what is the size of the vendor’s team, what are their skills, how long have they been around are usually available easily at the vendor’s website, their brochure or they are more than will to just give you that information. What is more difficult to know yet vitally important for you are the answers to the not so easy questions.

Here’s our list of top 10 questions that must be asked before any software development relationship is set up with a new vendor. There are obviously a lot more, but we feel that these 10 must be asked no matter what and the answers to these should be discussed internally with your team to see if you see a good fit, to see if you agree or accept those answers or not.

1. What are the company's values and goals?

You might think this isn’t all that important for you as a customer, or it’s just some marketing blurb that you can by pass - but you’d be wrong. A software development project isn’t like many other projects around, it’s not like a simple product you buy and then you can pretty much live on your own. A software development project means a sustained relationship for a period of time (usually pretty long - remember it’s just not the development time, but all the maintenance, updates, upgrades and fixes of a software’s typical lifetime) . So what your vendor’s values are, how they see the business, what their goals are - all these matter because you’ll need to agree with them, be comfortable with them and at the very least accept them. For example if the vendor feels that their real goal is to become a giant in 5 years, then you need to think if that fits with your goal of working with a stable and small team.

A picture from 17 years ago at our old office where we had those beautiful mosaic patterns you don’t see anymore.

Sometimes alignment of values are a very good sign that things will work out in the longer term. I remember a long time back I was showing a prospective customer our old office space that had these beautiful, intricate mosaics and I mentioned that we love these patterns and we take extra care not to destroy them somehow. She just absolutely loved it and said her company was a 3rd generation owner company that valued traditions - and we knew we had a good alignment. And indeed over time that has proven to be so true, having worked with them for a long time and launching several of their flagship products.

2. What happens when you fail to deliver something?

This is the hard question that all software vendor will try their best to avoid. But you absolutely have to ask. Things do go wrong in software (actually all the time, some studies have shown that 78% of software projects fail, a recent post of ours tries to find a way software project plans can be done to avoid failure). So asking how the vendor will manage that risk is essential. If the answer to that sounds vague or if they say the impossible - “we don’t fail” then think hard if this is a good fit, dig in deeper to see how reliable that partner is. Every software project should have a disaster recovery plan - simple. If a vendor doesn’t have one or isn’t planning one then there is something wrong with that vendor.

What you should be looking for is a realistic yet confident approach towards delivery failures. There should be a risk management plan - a risk containment and mitigation approach. They should be ready to act when a failure happens, and draw on the experience and knowledge from past projects and from the team to minimize the impact to the project.

3. What happens if a team member leaves suddenly?

Software is very much a team effort where every team member is essential. Over time a team member becomes an expert of the project and its requirements. Developers grow the essential familiarity with the codebase, the features, the decisions and the compromises that make a software project work smoothly and efficiently. So when a team member leaves it puts a huge dampening effect on the overall project and the vendor must have a good plan to first manage the team so that doesn’t happen and then manage things when it does happen.

More on this theme on question 8 below and there is a reason to separate them out and ask them a bit spaced apart. You want to revisit this topic to see if the answers fit well.

4. Can you provide case studies of customers who have been successful with your software?

5. Can I speak with a client who is using your product now to get feedback on their experience?

6. How many projects like mine has your company completed in the past year?

This is pretty standard stuff - but sometimes these case studies are not shared publicly. Maybe an NDA prevents the sharing or there are some other reason why they don’t want to put these in their marketing material. So it’s essential to ask and then review these case studies. These are projects that has worked out so you should get a feel of your own project fitting in those - see if you can imagine your project being one of the case studies in the future. Ask questions that are not answered or issues that are not clear in the case studies.

7. What's the best way to reach you during and outside normal business hours?

8. Who will be my point of contact throughout the project?

Standard questions but you’d be surprised how many customers don’t ask this. You should have a clear picture about what to expect when the project is running in terms of communications. All projects will have at least one point in its history where you are desperately looking for a quick answer to a question. It could be during an important demo that you are giving to your prospective customer, it could a bug you spotted that needs a fix right away. You need to know about the contact points and be absolutely sure before any vendor is accepted.

9. How do I know that I can trust you with my data?

Data security if everything in software and it’s important you ask this question right at the beginning. There must be a very clear procedure for data security at the vendor’s site. They must have a plan and a process that ensures that the plan works.

10. How long have your employees been with your company, and how many years of experience do they have in this industry ?

This is a revisit on the team stability question of question no 3. Vitally important question and a revisit is needed to see if the answer to this fits with the answer to the other.

Good luck with your vendor hunting!

How to motivate a remote team

Remote work is now the norm. This is one thing that the COVID has pushed us to and has proven that it works. Companies that never did remote work (including us at Kaz) are now fully functional and thriving with remote work. And remote work is here to stay as a work model - it’s very likely that every company in the world (including us) would keep some form of remote work in their process. Everything has a downside - and for remote work it’s the lack of the rest the team near you that starts having an effect. Over longer period of time motivation for work becomes a big stumbling block. And for manager and team leads it’s not an easy problem to solve. But we’ve found that it’s not an impossible problem either.

“77% of remote employees say they’re more productive when working from home”

— Survey by CoSo Cloud

You don't have to be next to someone's desk in order to feel the energy of a team that can work together and accomplish goals. As a manager, you can motivate and inspire your remote team just as well as you would if they were all sitting in your office.

Here are our top tips for motivating your team remotely.

1. Set clear expectations for your team

We are used to taking visual ques from all our interactions, these ques form much of our understanding in any conversation. A remote team misses a lot of these visual ques in an interaction over a zoom call or worse over an audio only call. So it's vitally important that common understanding of expectations is reached. We tell all our customers to set aside a slot at the end of every meeting to just go over the main points of the meeting and check that the both sides agree on what the expectations are.

2. Be transparent about what is happening

When your remote team feels out of the loop, they are less likely to want to engage. People are motivated by being informed about what is going on around them, so tell them! If they miss something, feel free to say "let me go over that thing" or "you should hear about a new development that is happening". This is especially true for software teams, as software development is typically a very collaborative effort and if the remote team feels that they are left out of decisions, changes in requirements etc. it will create a loss of motivation and just make the overall process of software development difficult.

3. Communicate regularly

The remote work experience will be a lot better if there are regular communication channels between the remote team and the office. Some ways to keep them in the loop is by having weekly meetings that are open to all members of the remote team, sending out emails with important updates on new features or scheduled changes, etc. Asking them regularly how they are doing, where they are on particular tasks or deliveries.

There are many other ways you can motivate your remote team. Some of them are time off or bonuses, but at the end it is about working with people who enjoy what they do - And if they are happy to work for you, you will get an effort that goes beyond the job requirements.

For small companies this might seem like a lot of overhead, but it is vitally important for the longer term.

“2020 has seen a 9% increase in Google search interest related to “team-building””

— www.thinkwithgoogle.com

The biggest bugs in software history

We all know that software bugs are bad. But how bad can they be? Here are three of the bigger bugs from software history.

The most expensive

Ariane 5 Flight 501

June 4, 1996 the very first Ariane 5 rocket launched. But it began to disintegrate only 30 seconds after launch - slowly at first and then with a final explosion. In this case, there was a bug in the guidance code which allowed vibration to cause it to misread a variable. Simulations to find the cause of this showed that in the rocket’s software (which came from Ariane 4), a 64-bit variable with decimals was transformed (cast in tech speak) into a 16-bit variable without decimals. In the 16 bit world of Ariane 4’s operating system a variable can only have a number between −32,768 to 32,767 yet for a 64 bit variable that range is the huge range of -9,223,372,036,854,775,808 and a maximum value of 9,223,372,036,854,775,807! These variables, taking different sizes in memory, triggered a series of bugs that affected all the on-board computers and hardware, paralyzing the entire ship and triggering its self-destruct sequence.

A very expensive bug at $370 million price tag. You can imagine the stress the software and QA team must’ve gone through after this super expensive fireworks. We have the video that shows the effect of the bug though…

The deadliest

The patriot missile failure

In February 1991 an Iraqi modified Scud missile hit the US base of Dhahran in Saudi Arabia, killing 28 American soldiers. This was not supposed to happen as the base was protected by a super sophisticated anti missile system called the Patriot. But a software bug was what made this happen which translates to a delay of  ⅓ of a second after 100 hours - about the time of running for that disaster. A 0.33 seconds doesn’t sound too big; but for a radar that follows these fast moving (1.5 km per second / 0.88 miles per sec) missile, this translates to a 600 meter error. Enough for the anti-missile-missile to miss it’s target and for letting the Scud do its damage.

The most fun

Windows 98 presentation BSOD with Bill Gates

This actually happened! And the best thing is that we have a video of this happening live. You can’t have it better than this.

A nervous-looking Chris Capossela, then chief marketing officer at Microsoft, plugged in a scanner into a Windows 98 machine and Mr. Gates was just beside him smiling. Their plan was to show how easy it is to just add hardware into the new Windows - the famed plug-and-play abilities of Windows. And boom we had a gem of a Blue Screen of Death (BSoD), and a priceless moment in bug history. Mr. Gates pulled another wonder with line that went: "That must be why we're not shipping Windows 98 yet!". Here’s the video for your viewing pleasure.

How to make a software project plan that actually works

Making a project plan for software development is one thing, but making it work is another. You've probably seen lots of software project plans in your day. They all look the same with their pretty Gantt charts and lovely blue annotations, don't they? Yet, do you know the failure rate of these pretty Gantt charts? That number is an unbelievable 78% according to one study in 2009 (the same group found a failure of 84% in IT projects in 1994!). This humongous failure number keeps coming up in studies after studies, here’s one by another very respected group - McKinsey-Oxford study for IT projects

Given these huge failure numbers we have to accept the reality of difficulty of making a software project plan that works. Over the years we at Kaz Software have worked on numerous software projects, for hundreds of companies around the world and we know from first hand experience how difficult this is. There are hundreds of variables that you should be thinking of when making a reliable project plan - from obvious ones like requirements, business priorities, resource availability to unexpected ones like language barriers, paperwork, compliance issue, etc. On today’s post I’d like to share some of the things we have learnt about making a better project plan - not perfect, maybe perfection isn’t possible, but a better one at least!

Decide on a project timeline and set deadlines

The first step is to decide how long your project will take. One month, three months, six months? Or maybe you can't put an exact number on it because you aren't yet sure what the project entails. That's fine too - just be as accurate as you can. The point is to be realistic, to have all the information available at that point in time and make the best possible guesses based on that information. If you know the requirements will change frequently, set deadlines for each round of revisions. If you think your team members are bad at estimating their time, maybe give yourselves a longer timeframe. Set deadlines that are achievable but challenging. Don't be too optimistic or you'll end up disappointing yourself and everyone around you when things don't go as planned.

Create a list of tasks with a democratic estimation

This is where you break down the requirements into smaller areas, features and then eventually tasks. Make sure you about break large, vague tasks into smaller tasks with deadlines that are based on the time estimates. Breaking down the larger tasks into smaller tasks are relatively easy, especially if you have experienced resources in your team. Where it gets extremely hard is the time estimation of tasks. Most developers will either overestimate or underestimate time cost for a task. This is just a fact of life. Our solution has always been to use democracy to find the time cost number - effectively asking all members of the team to discuss and come up with a time estimate rather than relying on a single person (the developer who is likely to do the task). This may sound counter productive, as the task will be done by a single developer at the end of the day - but somehow the democratization of this process gives much better result.

“Realistic schedules are the key to creating good software. It forces you to do the best features first and allows you to make the right decisions about what to build. Which makes your product better, your boss happier, delights your customers, and—best of all—lets you go home at five o’clock.”

— Joel Spolsky

On this point I’d like to note another very effective way of getting time estimates - which is to look at historical success and failure rates of estimates per developer and based on that decide if the developer typically over or under estimates and then add or subtract based on that data. This idea was very effectively put into use in Joel’s FogBugz product - and he called it evidence based scheduling. You do need a platform like FogBugz to make this happen, and even then you need to have enough historical data with the same developers to make it really work.

Write down the resources needed for each task

This is where you list who's expertise is required to complete each task and what kind of equipment will be used. If the skills required for a task is not available in your team, plan for it - how you will fill up the gap, what steps you'll need to take to have that skill available at the right time. Some of those steps may be tasks themselves that you have to add to your project plan.

Set up milestones that you'll need to meet

Milestones let you know how much progress you've made and if everything is on track with your timeline. You can set up intermediate deadlines as well if you're not afraid of breaking your work into smaller chunks. If you have a long term project, it may be better to set up milestones at the beginning so that you'll know how much you can do every week or every month.

Make sure your plan is achievable by breaking it into small enough chunks so that you can achieve them one by one. Divide and conquer is the the only way to solve the complex problems in a software project. If you decide to take on something big, it can quickly become overwhelming. Try breaking your project into smaller pieces and figure out how long each one should take.

Stick with it!

Don't give up when things get tough! You're almost there! This is the most important tip of them all. If you have failures, delays, setbacks just know that that is a fact of life for all software projects. You just have to have the patience to stay with your plan, make changes as needed to adapt to the delays and move things forward. Software projects never go as planned, and one of the greatest sign of a good plan is that it has the ability to absorb the changes as they happen. And the one most important skill of a software leader is the the ability to stick with the plan.

Remember that a software project is a process, and it can be thought of as a linear progression from one phase to the next. Plan out how you will go from start to finish with milestones in between. Use your resources effectively by having the right people on the job for specific tasks, making sure you have access to special equipment or resources.

Let’s break these horrible failure stats. Good luck!

All you need to know about bug reporting

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

The bug report

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

1. Steps to reproduce the bug.

2. What was the result?

3. What was the expected result?

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

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

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

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

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

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

The process after the report

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

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

Making you software dreams come true

Now is the time

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

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

Take the first step

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

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

What do people really want?

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

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

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

How to evaluate software development company performance

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

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

The basics

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

speed, price, quality & service

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

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

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

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

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

The performance measurement matrix

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

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

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

— Steve McConnell

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

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

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

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

Leadership in software development

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

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

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

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

• Democratic Leadership - consensus driven

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

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

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

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

• Bureaucratic Leadership - follow the procedure whatever the case style

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

And of course the infamous

• No Leadership

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

What’s the best style for software teams?

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

So here goes…

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

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

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

Goal 1: Create a jelled teams

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

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

— Google's 2004 founders' letter prior to IPO

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

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

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

Goal 2: Make information available

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

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

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

Making your software: Step 5 - Select a development partner

Priya, our fictional software entrepreneur from the previous chapters on this series has a dream to make “Designly” a software platform for interior designs. She has followed our suggestions on writing down her features in the specific format that software developers love as step 1 in her journey to make her software. She has then gone through the methodical approach of finding possible software developers using a simple yet effective process using the method laid out in step 2 - find software developer She has then followed through to step 3 - to get ballpark estimates that gave her the information to budget and create a financial plan in step 4 - budgets and funding. Now she has the all the groundwork done with a good plan to move forward. Now is the time to roll up the sleeves and get into action - the actual software development of the product. And the first step in the action is to select the software development company that will do the job for her. From her previous steps she has nice and short list of good vendors, she just needs to make up her mind in this step to pin down the one she wants.

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

The NDA

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

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

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

Work plan

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

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

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

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

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

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

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

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

6. Setup of shared issue tracker.

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

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

9. Development and delivery at milestones.

10. Feedback sessions at delivery milestones.

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

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

13. Deployment on live infrastructure.

14. Support for live system.

15. etc.

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

10000 hours of practice - fact or fiction?

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

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

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

Is it a fact?

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

“it depends”.

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

10K hours of coding?

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

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

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

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

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

Comparing software services export

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

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

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

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

Finding customers

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

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

Regional variations

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

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

Our major hurdles as a software service exporter

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

How do we find software projects outside of Bangladesh?

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

• Referrals

• Local partnerships

• Trade fairs

• Increased visibility – in bound digital marketing

• Social media outreach

And here are the ones that didn’t work:

• Outbound marketing (e.g. email campaigns)

• International RFP responses

How do we prove we are reliable?

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

• Referrals

• Local partnerships

• Case studies

• Demonstrations of software

• Contracts and NDAs

What doesn’t work for us:

• Certification, CVs

• Brochures and other marketing assets

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

Making your software: Step 4 - Budgets and funds

Priya, our fictional software entrepreneur from the previous chapters on this series has a dream to make “Designly” a software platform for interior designs. She has followed our suggestions on writing down her features in the specific format that software developers love as step 1 in her journey to make her software. In step 2 she went over strategies to find a software developer company who will turn her dream into reality. Then she gets good ball park estimates for making the software in step 3. Now that she has some numbers she can work on her next challenge of budgeting and financial planning for the software development.

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

Phases of software launch

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

Design and planning

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

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

Development of the MVP

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

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

Launch and marketing

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

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

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

Releasing the updates

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

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

Maintenance

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

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

Payment strategies

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

Milestone based payments

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

Phased development

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

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

Deep Work - Great book for software professionals

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

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

Deep Work by Cal Newport 

Deep Work: Rules for Focused Success in a Distracted World

By Newport, Cal

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

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

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

• People who have large capitals to invest in companies

• People who are very good at technologies

• People who are very good at what they do

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

Shallow work vs deep work

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

Attention Residue

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

Four methods of deep work

Monastic deep work

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

Bimodal deep work

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

Rhythmic deep work

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

Journalistic deep work

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

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

Here’s a quick book summary in Bangla…

Atomic Habits - Great book for software professionals

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

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

Summary

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

By James Clear

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

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

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

Changing Habits

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

WHAT IF ….

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

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

Four actions

Our habits are generated through the following four steps-

·         Cue

·         Craving

·         Response

·         Reward

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

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

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

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

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

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

Ways to remove bad habits-

·         Cue should be invisible

·         Craving should be unattractive

·         Response should be difficult

·         Reward should be unsatisfying

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

We usually imitate our habits from these three groups of people

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

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

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

To sum it up

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

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

Here’s a quick book review in Bangla…

Top Benefits of Hiring an Offshore Software Development Company

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

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

How do software vulnerabilities affect businesses?

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

How to prevent security vulnerabilities

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

Define Security Requirements

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

Be Mindful of Third-Party Software

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

Consistently Identify Vulnerabilities

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

Get Help from the Experts

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

Why hire an offshore software development company?

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

Guaranteed Security

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

Cost-Saving

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

Reduced Liabilities

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

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

Faster Development Time

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

Utilize The Top Resources And Technologies

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

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