Taking a break is a great problem solver in the software world

When you are writing code encountering challenges and roadblocks is inevitable. Whether you're a seasoned developer or just starting your coding journey, hitting a wall in problem-solving is a shared experience. In these moments, the inclination might be to power through, burning the midnight oil to conquer the issue at hand. However, there's a powerful and often underestimated strategy that can make all the difference – taking a break.

Mental Fatigue and Productivity

Solving complex software problems requires intense focus and mental energy. Continuous engagement without breaks can lead to mental fatigue, diminishing your cognitive abilities and creativity. Taking a break allows your mind to reset, helping you return with a fresh perspective and renewed mental stamina. This can significantly boost your overall productivity.

At Kaz we are serious about taking breaks during work. Our work environment is designed so that there are spots where someone can just sit and relax or play a game to take their mind off work.

Gaining a New Perspective

When you're deeply immersed in a coding problem, it's easy to develop tunnel vision. Taking a step back provides an opportunity to see the bigger picture. A break, whether it's a short walk, a snack, or a brief diversion, allows your brain to process information in the background. Often, the solution to a problem becomes clearer when you're not actively focusing on it.

Preventing Burnout

Software development is demanding, and burnout is a real risk. Constantly pushing yourself without breaks can lead to exhaustion, decreased job satisfaction, and even long-term health issues. Regular breaks act as a buffer against burnout, preserving your passion for coding and maintaining a healthier work-life balance.

A great way to prevent burnout is to take a long break from work - like a holiday or even a short staycation. At Kaz we do our yearly anniversary party as the company-wide long break, where we go somewhere far away for a few days to just relax and not talk about code!

Creativity Flourishes in Downtime

Creativity is a crucial aspect of problem-solving in software development. Breaks provide the necessary downtime for your brain to make unexpected connections and generate innovative solutions. Some of the best ideas often come when your mind is relaxed and not fixated on a specific problem.

Improved Decision-Making

When you're stuck in a coding dilemma, the pressure to find a solution quickly can cloud your judgment. Taking a break allows you to step away from the urgency and approach the problem with a clearer, more rational mindset. This, in turn, leads to better decision-making and more effective problem-solving.

Physical Well-being

The sedentary nature of software development can take a toll on your physical health. Many tech companies are introducing standing desk as the cure for cancer for this, but it’s not really a proper cure, a great read is this article on Harvard Health Blog about standing desks. The truth is that you need breaks away from your desk and work. Regular breaks promote movement and help prevent issues like eye strain, back pain, and repetitive strain injuries. Simple activities during breaks, such as stretching or taking a short walk, contribute to overall well-being.

In the world of software development, the ability to navigate challenges and solve complex problems is paramount. However, it's essential to recognize the value of stepping back and taking breaks when faced with a programming roadblock. Not only does it contribute to improved mental and physical well-being, but it also enhances productivity, creativity, and overall job satisfaction. So, the next time you find yourself staring at lines of code with no solution in sight, remember that sometimes, the most effective solution is to step away and allow your mind the space it needs to conquer the challenge at hand. Happy coding, with a healthy dose of breaks! Remember those old KitKat ad? Where they used to say “Have a break, have a Kitkat”, that’s exactly what you need to do!

Code Reuse: Leveraging the Goldmine

Here’s a little fun comic we did a long time ago in Bangla, roughly translated it says, “Copy paste was designed by the programmers for themselves!” This was fun but there is an element of fundamental truth about this. Code reuse is one of the best practices in the software world if done right.

The importance of efficiency, speed, and cost-effectiveness cannot be overstated. As developers strive to meet tight deadlines and deliver high-quality products, the strategy of reusing existing software code has emerged as a powerful tool. In this blog, we'll delve into the myriad benefits of leveraging pre-existing code and explore how this practice contributes to the success of software development projects.

1. Accelerated Development Cycles:

One of the primary advantages of reusing existing code is the acceleration of development cycles. Instead of reinventing the wheel for every project, developers can draw upon the wealth of code libraries and frameworks available. This not only reduces the time required for coding but also allows teams to focus on the unique aspects of their project, leading to faster time-to-market.

2. Cost Efficiency:

Time is money, and in the world of software development, time spent on coding directly impacts costs. By reusing existing code, developers can significantly cut down on development time, resulting in cost savings. Additionally, leveraging open-source software and libraries eliminates the need to develop certain functionalities from scratch, reducing overall project expenses.

3. Quality Assurance:

Well-established, reused code has likely undergone rigorous testing and debugging. When incorporating existing code into a new project, developers benefit from the collective efforts of the original contributors, reducing the likelihood of bugs and errors. This enhances the overall reliability and robustness of the software, leading to a more stable end product.

4. Consistency and Standardization:

Reusing code promotes consistency and standardization across projects. Adopting a standardized set of libraries or frameworks ensures that developers adhere to best practices and coding conventions, resulting in cleaner, more maintainable code. This consistency simplifies collaboration among team members and facilitates knowledge transfer within the organization.

5. Community Support and Innovation:

Open-source communities thrive on collaboration and shared innovation. By reusing existing code from open-source projects, developers tap into a vast pool of knowledge and expertise. Community support can be invaluable when troubleshooting issues or seeking advice on implementation, fostering a culture of continuous learning and improvement.

6. Scalability:

Reusable code is inherently scalable. As project requirements evolve or expand, developers can seamlessly integrate new functionalities by building upon existing, proven codebases. This scalability not only streamlines the development process but also ensures that the software remains adaptable to changing business needs.

In the dynamic realm of software development, the value of reusing existing code cannot be overstated. Accelerating development cycles, reducing costs, ensuring quality, promoting consistency, and tapping into community innovation are just a few of the benefits that come with this strategic approach. By embracing the principle of code reuse, developers position themselves to not only meet the demands of today but also to adapt and thrive in the challenges of tomorrow. It's not just about writing code; it's about leveraging the collective intelligence of the developer community to build a more efficient and sustainable future for software development.

Living with Bugs: Navigating the Imperfect Landscape of Software Development

In the intricate realm of software development, bugs are not just an occasional nuisance; they are an inherent and inevitable part of the process. No matter how experienced or skilled a developer may be, the complexity of software systems ensures that bugs will emerge at some point. Rather than viewing bugs as obstacles, it's time to shift our perspective and acknowledge them as an integral part of the software development journey. Learning to accept and manage bugs is not a sign of weakness but a testament to the dynamic nature of programming. We wrote before about our philosophy of living with bugs in software that is already being used, today I’m going to delve into a more general view about dealing with bugs as part of the software development process - learning to live, accept and even learn from bugs that we create as we write code!

The Nature of Bugs

Bugs, also known as software defects or glitches, are unexpected behaviors or flaws in a program that prevents it from functioning as intended. They can range from minor inconveniences to critical issues that compromise the entire system. The diversity of bugs mirrors the complexity of the software itself, which is composed of countless lines of code, dependencies, and interactions.

Acceptance is the First Step

The first step towards writing great software is accepting the inevitability of bugs. Rather than viewing them as a failure, consider them as opportunities for improvement. Bugs are an inherent part of the creative and dynamic process of software development. Even the most renowned software products have their fair share of bugs. Understanding and embracing this reality is crucial for fostering a healthy mindset among developers.

“Industry Average: about 15 – 50 errors per 1000 lines of delivered code”

— Code Complete, Steve McConnell

In Steve McConnell's book, Code Complete, it is mentioned that the industry average for errors in delivered code is approximately 15 to 50 per 1000 lines. This metric is commonly referred to as defects per KLOC (1000 lines of code). McConnell further notes that Microsoft applications experience about 10 to 20 defects per 1000 lines of code during in-house testing and 0.5 defects per KLOC in production.

While achieving zero defects is possible, it comes at a considerable cost. NASA, for instance, achieved zero defects in the Space Shuttle Software, but the expense amounted to thousands of dollars per line of code. Such high costs are justifiable in situations where software bugs could lead to life-threatening consequences. However, for most projects, reaching the same level of testing rigor as NASA is financially challenging and often impractical.

Learning from Bugs

Bugs provide valuable insights into the intricacies of the software code. Each bug is an opportunity to learn, improve, and enhance the robustness of the system. By carefully analyzing bugs, developers gain a deeper understanding of the software architecture, identify weak points, and discover potential optimizations. The iterative process of fixing bugs contributes to the continuous refinement of the codebase. A great read is this article about strategies to handle defects in the agile methodology.

Here are some of the ways we can glean insights and improve from encountering bugs:

1. Root Cause Analysis: Investigate the bug thoroughly to identify its root cause. Understanding why the bug occurred is crucial for preventing similar issues in the future.

2. Knowledge Enhancement: Bugs often reveal gaps in understanding or knowledge. Use each bug as a chance to deepen your understanding of the programming language, framework, or tools being employed.

3. Code Review Practices: Regular code reviews can catch potential issues early in the development process. Analyze bugs to enhance code review practices and foster a culture of collaboration among team members.

4. Automated Testing Improvements: Enhance automated testing procedures to catch potential bugs before they reach production. Learning from bugs helps refine test cases and ensures better code coverage.

5. Documentation Enhancement: Document the bugs encountered, their resolutions, and the lessons learned. This serves as a knowledge repository for the team and aids in preventing similar issues in future projects.

6. Iterative Improvement: Embrace an iterative development approach. Use each bug fix as an opportunity to improve the overall codebase, making it more resilient and less prone to similar issues.

7. User Feedback Integration: Bugs reported by users provide valuable insights into real-world usage scenarios. Integrate user feedback into the development process to address issues that may not have been apparent during internal testing.

8. Continuous Learning Culture: Foster a culture of continuous learning within the development team. Encourage open communication about encountered bugs, solutions, and preventive measures.

9. Code Quality Metrics: Implement and monitor code quality metrics. Track the frequency and severity of bugs over time, and use this data to identify trends and areas that require additional attention.

10. Peer Collaboration: Facilitate collaboration among team members. Encourage open discussions about encountered bugs, and leverage collective knowledge and experience to devise effective solutions.

11. Adopt Best Practices: Incorporate industry best practices into the development process. Stay informed about advancements in coding standards, security practices, and technology trends to proactively address potential issues.

12. Incident Response Planning: Develop incident response plans to efficiently address and resolve bugs when they occur in a production environment. This minimizes downtime and ensures a swift recovery.

By approaching bugs as opportunities for improvement rather than setbacks, development teams can create a more robust and reliable software development process over time.

Effective Bug Management

While bugs are inevitable, effective bug management is essential for maintaining a high-quality software product. Over the years various processes and ideas have floated in the software development world for managing and reducing bugs. Six sigma management process is an example of such an idea of reducing bugs in a set software cycle. Agile methodology has definitely proven to be a very effective tool for managing and reducing bugs.

Here are some strategies to navigate the bug landscape:

1. Thorough Testing: Implement comprehensive testing practices, including unit tests, integration tests, and end-to-end tests, to catch bugs early in the development process.

2. Version Control: Utilize version control systems to track changes in the codebase. This allows for easy identification of when and where a bug was introduced, facilitating quicker resolution.

3. Bug Tracking Systems: Implement a robust bug tracking system to document and prioritize bugs. This ensures that the development team can systematically address and resolve issues.

4. Collaborative Development: Foster a collaborative development environment where team members can openly discuss and share insights about bugs. Collaboration accelerates the identification and resolution of issues.

5. Continuous Integration and Deployment (CI/CD): Automate the testing and deployment process to quickly detect and address bugs in the development pipeline.

In the ever-evolving landscape of software development, bugs are not adversaries to be defeated but companions on the journey toward improvement. Embracing the inevitability of bugs and adopting effective bug management practices are integral to writing great software. By viewing bugs as opportunities for growth and refinement, developers can transform challenges into stepping stones toward creating robust and reliable software systems. After all, in the world of programming, perfection is not the absence of bugs but the ability to navigate and overcome them with grace and skill.

I’ll end the post with a little comic we made in Bangla. The text translates roughly to - “Do you want write code without bugs? Then don’t even try!” This little comic sums it all up - you just can’t write code without bugs, you just have to learn to live with it to survive in this software development world.

Disagreements and debate: the crucial elements in great software projects

In the dynamic realm of software development, where agility and innovation are paramount, fostering an environment that encourages debates is not just beneficial—it's indispensable. The idea of debating within a software project may seem counterintuitive to some, as the conventional image of software development often revolves around quiet coding sessions and collaborative problem-solving. However, embracing debates in the development process can lead to a plethora of advantages, from refining ideas and uncovering hidden issues to enhancing team collaboration and achieving superior project outcomes.

Innovation through Divergent Perspectives

One of the primary reasons debates are crucial in software projects is their ability to stimulate innovation. Divergent perspectives, often emerging during heated debates, can catalyze the generation of creative solutions to complex problems. When team members bring unique experiences, insights, and approaches to the table, it opens up avenues for exploring unconventional ideas that could be game-changers. This realization has led to many software leaders actively seeking a diverse software dev team in the hope of inserting divergence in perspectives in team decisions.

Debates force individuals to articulate their thoughts, challenge assumptions, and present evidence in support of their ideas. This process of intellectual rigor helps in refining concepts and ensuring that the final solutions are well-thought-out and robust. Without debates, a team risks falling into the trap of groupthink, where conformity stifles innovation and unconventional ideas are overlooked.

Identification and Mitigation of Risks

Software projects are rife with challenges, and potential risks can lurk beneath the surface. Debates serve as a powerful mechanism for surfacing these risks and addressing them proactively. When team members engage in discussions about project requirements, design choices, or implementation strategies, they are more likely to identify potential pitfalls that might be overlooked in the absence of scrutiny.

By thoroughly debating different aspects of a project, ranging from technical decisions to project timelines, the team can anticipate and mitigate risks early in the development process. This proactive risk management is crucial for ensuring project success and preventing costly errors down the line.

Enhanced Collaboration and Team Dynamics

Debates, when conducted in a constructive manner, contribute to a positive team culture by fostering open communication and collaboration. When team members feel empowered to voice their opinions, it promotes a sense of ownership and engagement. Additionally, debates encourage active listening, as team members must understand and respond to each other's arguments.

Moreover, healthy debates provide an opportunity for team members to learn from one another. As individuals share their knowledge and experiences, it creates a collaborative learning environment where everyone can benefit from the collective wisdom of the team. This learning dynamic not only improves the skill set of individual team members but also contributes to the overall growth and development of the team as a whole. One thing important in this area is the leadership style of the team leads in the software project. If the style of leadership is not open to a multitude of ideas then the benefit of enhanced collaboration breaks down and the debates turn into points of division within the team.

Refinement of Ideas and Decision-Making

In the crucible of debate, ideas are refined, and decisions are thoroughly scrutinized. This process is essential for ensuring that the chosen path is the most effective and well-considered one. Debates force individuals to defend their proposals, encouraging a deeper understanding of the implications and trade-offs associated with different choices.

Through this rigorous examination of ideas, the team can make informed decisions that are more likely to stand up to the challenges of implementation. The act of defending one's position in a debate requires a comprehensive understanding of the subject matter, promoting a culture of informed decision-making within the team.

Continuous Improvement and Adaptability

Debates are not static events but dynamic processes that unfold as projects evolve. In the ever-changing landscape of software development, the ability to adapt and iterate is crucial. Debates contribute to a culture of continuous improvement by encouraging teams to revisit decisions, reassess strategies, and incorporate new insights and information as they emerge.

This adaptability is particularly important in agile development environments, where the ability to respond quickly to changing requirements is a key success factor. Embracing debates as a means of continuous improvement ensures that software projects remain agile, resilient, and capable of delivering value even in the face of evolving challenges.

In the fast-paced world of software development, where the only constant is change, the importance of debates cannot be overstated. By fostering innovation, identifying and mitigating risks, enhancing collaboration, refining ideas, and promoting adaptability, debates play a pivotal role in shaping the success of software projects. Teams that actively engage in constructive debates are better positioned to navigate the complexities of development, resulting in superior outcomes and a culture of continuous improvement. In the vibrant ecosystem of software projects, debates are not just discussions—they are catalysts for excellence. We have a joke at Kaz that if only two people agree in a group of many we have a decision! The little comic here says that in Bangla :)

Common mistakes that new software companies make and how to avoid them

Starting a new software product can be a daunting task, especially if you are new to the world startups and software. While every new business journey is unique, there are some common mistakes that many founders make. After helping companies big and small - from Fortun500 beasts to one person startups, we think we’ve seen it all! In this blog today, we will discuss the some of common mistakes that we see over and over and also give some tips on how to avoid them.

Not knowing your customer

One of the biggest mistakes that software product leadership make is not knowing their customer. Notice I’ve kept the term very generic, “software product leadership”, and that’s because this mistake is made by startup founders as well as product teams in well established software outfits! It is important to have a clear understanding of who your target customer is and what their pain points are. This will help you develop a product or service that addresses their needs and provides value. Take the time to conduct market research and talk to potential customers to gather feedback and insights. Remember that the software you are making is not for you (well it may well be, but you are probably not its only user). So make sure your biases and fascinations don’t guide the software requirements. Find out out the real customers, find out their actual needs - their needs may not be at all like yours. We recently posted a detailed strategy of finding what features you should plan on your software - worth reading that too if you are considering this point. Also worth a read is another recent post about finding customers for a software product.

Not having transparent conversations with your co-founders

Co-founder relationships are critical to the success of any startup or a software product launch. It is important to have open and transparent conversations about roles, responsibilities, and goals. Without clear communication, resentment can build up, and the relationship can deteriorate. Make sure to have well-organized conversations that are designed to share how you feel about the current situation of the company, how it's organized, and who is responsible for what.

Not launching

Many startups are afraid to launch because they think they need to be fully ready before they can get in the press or be on popular blogs. However, launching is not as significant an event to your users as it is to you. If you think about it, how many famous platform do you remember being launched? We only find out about a new product once it starts getting traction - think Facebook, think LinkedIn and think if you ever heard them at launch time… most likely not! It is important to move up the launch as soon as possible to get your product in front of customers. This will help you validate whether it solves their problem and give you the feedback you need to improve. Remember the minimum viable product (MVP) way of doing things. With an MVP you move to a faster launch and a faster way to more feedback. A long time back we posted on our blog an article about how every software company should launch with an MVP and it’s one our most read articles.

Not using analytics

Measuring what your users do when they come to your site is critical to improving your product. It is important to track your website analytics and user behavior to understand what is being used and what is not. This will help you make data-driven decisions and prioritize features that are important to your customers.

Not prioritizing the actual product!

Startups often prioritize sizzle over the actual steak! I mean they make more fuss about various things around the product than the actual product itself, such as hiring, press, and conferences, over getting the product out there and talking to users. However, the actual work of startups is pushing product, getting it in the users' hands, and seeing if they like it. Prioritize getting your product in front of your customers, gathering feedback, and iterating on it to make improvements.

These are some of the most common mistakes that we see many companies make. While it is possible to be successful even if you make these mistakes, it is important to minimize them as much as possible to improve your odds of success. Good luck!

Workplace design for a software company

We are turning 18 this month! Around every birthday we have we keep getting asked about our “secrets”. The secrets of how we run things, how we managed stay professional yet a fun place to work, how stayed profitable yet spend so much on “extras”, etc. And every birthday time we usually end up writing about our little “secrets” - although they are not really secrets, more like common sense. Today’s post is about one such common sense “secret” - what kind of workplace design (we strongly believe) works best for software companies.

First, let me point out that we have written around this topic before, so some of this will be regurgitation but some maybe be new - coming from our added experience and also a recent redo of the office space. So here goes…

Patterns rock but some new cool kids do too

I cannot but mention this side note: there is a direct link between the software design patterns and these architectural patterns. The pattern language book had been the seed for the idea of categorizing good software architectures and plans to a list of standardized design patterns by the famous GoF. As a tribute this connection, Prof. Alexander (the principal writer of the Pattern Language book) was asked to do a keynote speech at ACM conference on OOP which he started with this line :)

“Thank you very much. This is a pretty strange situation I find myself in. I hope you sympathize with me. I'm addressing a room full of people, a whole football field full of people. I don't know hardly anything about what all of you do. So—please be nice to me”

Just as with software design patterns workplace design also has patterns that can be used to create good designs! The classic in this space is The Pattern Language which first laid out the ideas of patterns in architecture or space design that leads to “good feelings”. Essentially the writers were trying to list and categorize the design elements that make some places feel comfortable so that these design elements can the reused. Within the 253 patterns they identified there are some gems for the workplace. We always tried to use as many of them as possible in our work place design. Over the years we have found that some work better than others for software companies. In our redo we kept to the ones we know works but we revisited the patterns to see if we can glean out new ones. Into this framework of patterns we have now additional public information about the workspace design thoughts for software companies like Google or Microsoft . We’ve been looking at what they believe is great and trying to steal as much as possible from them too! Obviously we don’t have as deep a pocket as the big guys so however much we like the slide at Google we just couldn’t convince our finance guys to fit that for us :(

Office space for the rest of us

OK, that slide at Google is just too good but since we can’t do that, let me go over some of the principles we have used in our redo.

Office needs to feel more like home

This has been one of our big ones from day one. We have always hated the “corporate” look of traditional software companies which look unnatural. By brining in elements from our home and allowing the organic growth of that workspace you create connection with the workspace. We thing that a workspace that looks and feels alien to what you are used to makes you disconnected from that space and you cannot have the same emotions and the same feeling of ownership as a space that feels like home. A good example would be a trip to a 5 star hotel - however beautiful it looks like, how comfortable that stay is like, you still feel that you are not part of that space, you are nothing but a temporary visitor. Contrast that with a stay at an airbnb, you almost instantly connect with place the moment you step in (assuming of course you’ve picked the right place!). The good thing is that the “home” feel is easy to recreate in most places. In Bangladesh the place of “adda” (chit chat) is a key for a good home feel. And we easily achieve that by bringing in elements of bamboo blinds and cane furniture. This is something we have used extensively in our redo from meeting rooms to “adda” spaces.

Meeting rooms need to be “cozy”

Meetings are the curse of work life :) Most of them feel like a drain of time and energy and your goal from the very first second becomes an exit strategy. I’ve generalizing of course but there are some elements of truth in what I said. Yet we know meetings are essential. To solve this opposing pulls we’ve found that a good solution is to make the meeting spaces feel cozy. You should feel that you are going to special place when you are going to meeting - a place that feels comfortable. We used a pattern for this (151 Small meeting spaces) and it is supported heaps of organizational behaviour research. For example Bernard Bass ran a study and published back in 1965 that showed the number of people in a group influences both the number who never talk, and the number who feel they have ideas which they have not been able to express.

Using several ideas from the pattern book and Microsoft’s data here are some of the things we decided about meeting spaces:

The space needs to be small and feel like you are moving into a comfortable space.

A pool of light on the meeting table (pattern 252) to tie the group members together.

Different types of chair (to make the feel of less corporate style meeting rooms and more home style spaces to talk).

Here’s a meeting room based on these principles from our redo (different chairs are not yet in there).

No approach from the back

This is our old one of making every seat with a wall at the back. The idea is that you should never feel that someone is watching you and your screen from the back. We keep our screens hidden from walking views. The overall effect of this is the feeling of safety and trust that it creates. It’s always been one of our strong views and we’ve written a lot about this before, here’s one recent one: Why we keep our screens private.

Keeping the team together

Software is a collaborative effort. Yet noise is a big issue for software developers because it creates distractions and reduces flow. How do we reconcile these two facts? Google actually had some really good data out about this after their big googleplex with hundreds of developers working on the same space went live. The gist of what we derived from it is that - the hum of work is good but only to the extent that the hum is related to what your interest is in. This fits with our beloved pattern of master & apprentice (pattern no 83). So we’ve designed the workspaces so that the team can stay together on its own without other teams mixed. We’ve also tried (where space permits) to have the lead (aka master) to have some more space and some privacy so that he can run short adhoc discussions without distracting the rest of the team.

Work and Play spaces

Ah this is our favourite as always. We’ve written about this very recently so I won’t repeat but point that post out: Work and play together - the secret of great work but the TLDR is that we have always had play areas very close to work areas. The idea is whenever someone needs a break they can quickly jump into a play area without a lengthy walk that becomes a barrier. In that light we have ping pong tables next to meeting spaces, adda nooks next to software development rooms or cricket running right next to work!

Special spaces and elements

We wanted to make the work space feel special in some way. This is really an on-going effort but throughout our office space we’ve tried to bring in elements that creates a little bit of surprise (and hence it’s ongoing as any surprise becomes boring after a while). Some of these special places are spaces that connect us with our past or our family (e.g. pictures of our children or us as children!), some are just weird things on display, some are nice things to look at (like pictures, aquariums, art work, etc.). I think these special things brings in a variety in our working lives and make us think outside the box once in a while.

I’ll leave with a picture of one of these “special” places - with picture of some of us as children and with one of us with his daughter enjoying the space - this pictures tells everything about our goals and aspirations for our workspaces.

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.

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 :)

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.

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.

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…

Top Benefits of Hiring an Offshore Software Development Company

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

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

How do software vulnerabilities affect businesses?

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

How to prevent security vulnerabilities

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

Define Security Requirements

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

Be Mindful of Third-Party Software

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

Consistently Identify Vulnerabilities

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

Get Help from the Experts

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

Why hire an offshore software development company?

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

Guaranteed Security

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

Cost-Saving

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

Reduced Liabilities

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

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

Faster Development Time

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

Utilize The Top Resources And Technologies

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

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

A full year of WFH

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

The WFH move

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

First two months of WFH

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

One year down

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

Bye for now, stay safe!

Freemium model for software sales

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

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

What is Freemium?

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

Which eventually lead you to this:

Why Freemium?

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

Does it work?

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

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

Software that looks at animal footprints

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

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

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

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

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

Living with bugs in released software products

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

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

Accept bugs

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

“Release with as few deadly bugs as possible”

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

Make finding and reporting bugs easy

Real life story:

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

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

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

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

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

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

Involve customers in the bug finding journey

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

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

Have workflow for updating users about bugs

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

Create a culture for celebrating finding and fixing bugs

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

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