Top software for business in 2023

2023 is going to be an interesting and unpredictable year for the software world. On one hand there is huge momentum on multiple exciting greenfield technology fronts such as AI, Metaverse, AR, etc. but on the other hand there is the fear of a major financial downturn leading to less investments in these emerging trends and more focus on recession-proof solutions in fintech, eCommerce, etc. Everyone knows that in the longer run companies have to invest and innovate in the emerging technologies to stay ahead in the competition but the big question is what’s the fine balance of investment for future technologies vs. the compromises in near term financial safety. We asked our tech leads about what are the areas where companies will do the most business in software and here are some broad areas they’ve suggested.

AI in fintech

AI has become of the keywords that gets thrown into any such discussion about the future of software. There is a good reason for it obviously, but specifically for 2023 we think the broad area of AI will be less important than the niche areas. One of those niche areas is the fintech. Any financial downturn leads to renewed interest in managing money well. And that is where AI can make a huge difference. AI in fintech isn’t anything new, it’s has been getting progressively better over the past few years, but we think 2023 will be the year where more eyes will be on it for it’s business value and this will accelerate this field immensely.

A good example of the type of fintech AI that we think will get the boost is the one that’s being rolled out at Upstart which is claiming to disrupt the inefficient, complex and slow industry of loans and credit risk analysis. This is a great summary of what they are aiming with their technology:

“Upstart is an AI lending platform that partners with banks and credit unions to provide consumer loans using non-traditional variables, such as education and employment, to predict creditworthiness”

The application of AI in the lending business will be a game changer in the financially difficult climate of 2023 where there is a significant likelihood of increase for the need for credit.

Another great example of the type of AI product to get a boost in 2023 is product like Highradius. It is again a platform that aims bring efficiency to financial processes that are highly inefficient currently thus costs companies time and money to operate. If they get it right their platform will automate routing receivables and payments processes including predicting engine for cashflow sensitive information like invoice payment dates using AI and machine learning.

Smarter eCommerce technology

Let’s face it, recession or not, online ecommerce is only going to thrive. It’s one of those data curves that only goes up because of the inherently good economics in the concept. The question isn’t, is it going to be important but which part of it is going to be important. We think ecommerce is still at the same level as it was years back when it was invented. Nothing significantly has changed in the buying process in platforms like Amazon. And that’s fine for most times since things are pretty optimized there anyway. But at times like these, a company that can come up with an innovation on top of existing marketplaces which will bring better deals, better sales, better visitor counts will win big. 2023 is a year for smaller outfits to make a name in the super established sector of ecommerce software.

So what can be there that has a chance to win big? Here’s an example: Affirm - a platform that opens up buying options on ecommerce platform, offering affordable ways to pay that are more flexible and transparent than a credit card. Again machine learning algorithms are the key to managing the credit underwriting but the company brings it into the hands of everyday consumers.

Intelligent Job Platforms

Recession equals more job searches - that’s just simple maths. So every job platform out there will likely see major upturn on visitors and revenue in 2023. But like ecommerce, job platforms are one of those areas where very little has changed over the years. 2023 is probably going to be the year where the new platforms with better offering will be the bigger winners and likely outpace some of the old and established players.

One example is Cogbee which uses technology to speed up the screening and thus offering a much better solution for employers. More employers mean more jobseekers and thus the positive feedback loop leads to bigger revenue for such a platform. Another great example of job platform that rethinking this old space is HireEZ that is brining in the concept of outbound marketing to the recruitment space. The platform enables employers run outreach towards their ideal candidates thus completely bypassing the time consuming screening and assessing phases of traditional recruitment. Savings in HR process caries huge value in a budget conscious year like 2023 and products like these are likely to get a lot of business if they can deliver.

Inter connecting smart home devices matter

Do you have whole bunch of “smart” home devices that don’t feel that smart? I’m talking about your Alexa not talking with your Google nest and cool smart tv from Samsung not so different from the old tv you had. The current landscape of smart home technology is very very fragmented - with separate camps for Amazons and Apples of this world and every other day a new player coming up with device for some existing camp or starting a new camp altogether. It’s confusing for the users and it’s bad for everyone. Why can’t these smart devices talk with each other? Why can’t I just tell Alexa to switch off my Samsung TV? Why cant these devices actually be a smart home. Well the short answer is obviously that these are from different and competing companies. But things are not so bad, a new standard for communications is emerging fast that most of these big players are signed up on and we hope very soon we’ll have a new generation of devices that can really talk with each other and be bit smarter!

The Matter

Competitors Apple, Google, and Amazon are joining forces to make an open-source smart home standard called the Matter. The goal of this standard is for smart devices to work together, making innovative apps around these smart devices simpler and to maintain security without compromising usability.

“You will then have the power to choose how you want to control your homes, independent of which smart home technology you choose. Smart home devices will be compatible with various platforms, so you can choose between Google Assistant, Amazon Alexa, Apple Siri or other platforms. ”

— Nik Sathe, VP Engineering, Google Nest

This standard will enable supported smart home device to talk with each other, regardless of which smartphone or voice assistant you’re using or which type of device you running the command on. All the major smart home device manufacturers are on board with the big boys and there is a lot of excitement around what’s possible. Here’s a quote direct from Google: “choose between Google Assistant, Amazon Alexa, Apple Siri or other platforms”. Nice, isn’t it?

What’s Inside?

So what’s inside this Matter? Version 1 of the specification was published 4 October 2022 so we actually know a great deal about it now. We know that Matter will work with existing Wi-Fi and Bluetooth, so it’s essentially a layer on top of existing connectivity paths and will not replace them. Reports say that devices will likely have to support Wi-Fi, Bluetooth Low Energy, or Thread to comply. Implementation details will be up to the exact manufacturer - as long as they stay on the standard they are good. We also know from various press releases by the group that the initial trials will be on home safety devices like locks and smoke alarms.

The standard is an IP based protocol, but obviously the devices won’t necessarily be required to connect to the internet - a local IP network will work too depending on what kind of connectivity and feature the manufacturer is planning.

The Future is Connected!

The first device with matter in is coming pretty soon (November or December 2022).Ubysis from German wants to be the first to have a product with matter in place. Apart from them there are whole bunch companies that are early adopters, big names like Amazon, Assa Abloy (Yale), Eve Systems, Google, Huawei, Legrand (Netatmo), etc. are all in there. So the future looks really good for an interconnected world of smart home devices. However, hold your horses. As with any such standardization which hundreds of separate competing companies have to comply to the dot there will be hiccups. On top of that the agreement on the standard and it’s changes are slow too - again because of multiple interests. It took early 2019 to 2022 to even get to a version 1.0 so you can imagine how it would go from here as new implementations are made and new needs arise for connectivity.

But we are super excited. Finally the days of connecting all those smart home devices are here!

Finding great software developers

Your software business is growing. To keep pace with the upscaling, you need a great software team to handle all the tech things so that you can focus on your work of expansion. But, do you know how to find and hire that great software team? A team that shares the same vision as you?

It’s hard to find good developers, as their skills are so much in demand that unless you are Google or Facebook you’ll never attract top developers to build your software projects. Even if you find someone with great talent and skills that person may not be the right fit for you and your team: he might not understand your instructions well, or may collaborate well with the rest of your team. Yet it’s vitally important to get the fit right in software. Building a great software is all about a team working together.

So, how do find great software developers? Here are some tips from our experience in working with hundreds of companies around the world building their software products.

Know what roles you need to hire for

A software team is composed of many distinct roles. Each role is essential and together they move your project forward. Remove one and you’ll see that things aren’t moving as they should. A role doesn’t mean a single hire, many roles are one person but sometimes many persons also fill a single role. Let me give you some examples: you need a business analyst role, someone who would understand the business problem you are trying to solve, then also understand how the software will solve that problem and most importantly know what are the priorities within the solutions. You also need a product manager, who will know what the product is supposed to do, when a certain version should come out with what features to meet what business need. This product manager will be the coordinator who talks with the tech team communicating the need and scope and then understand the technical challenges that the team faces and then faces the business side to understand their needs and communicates what’s what’s possible and what’s not. Now these two roles - the business analyst and the product manager tends to be two very distinct role but if the project size is small or if you just can’t afford two separate resources it’s just about possible to mix them both an have one hire that takes on both the roles. And if small startup it could be the founder who takes that role along with other roles like business development and even sales.

Whatever the context, before you even think of searching for your team, have a list of software roles you need to fill up. Then do your maths and figure out how many hires can you do and see if you can spread out the list of roles within them. This will guide you to the next step of the skills you need in your hires.

Know what you want to make

You need to know clearly the what you are making and what your business priorities are during this making phase. You should all the main features of the platform, which features are the most valuable and which are good to haves and which you can do without. The technology platform should be a big factor in this, for example you should know clearly what you want to keep inhouse and what you can get an external agency to do for you. For example, you can outsource salesforce development and keep the rest in house. In a perfect world you should also have clear specifications and requirements documents before you start adding software developers in the team who would build those features - but that’s in a perfect world!

In a startup, the minimum viable product aka MVP holds the most importance before the product or service is launched. Creating a neat and efficient MVP increases the chance of the startup being successful as well as fund raising and beta testing. And, that is where the software development team becomes crucial. So if you a startup just going through the motions of making your first attempt at the software your needs for the team is very different from the situation where you are an established software company thinking of extending an already selling software.

Remember that having a clear view about what you are building will not only help you identify the skillset you need but also help you ask the right questions when you find potential candidates.

Reference, reference, reference

The tech world tends to be a very connected world. Personal advocacy is always a first choice for everyone when it comes to hiring people for a software project. In this case, you have to keep in mind that your product or service is based on, and according to that you have to find the right people with appropriate skills. Maybe a web developer has helped your friend greatly, but it will not come to handy if your product is based on android application.

Here at Kaz software, around 80% of our customers are referred to us by our existing clients and partners.

Searching on the internet

Searching at the right forums and discussion boards can land you rare skilled developers who are not available in other platforms. Many software development teams work as agency and offer their services through their own company. If you are willing to work with a readymade team who can start working for you, this is a really good option. Kaz Software is a good example of such sources of ready to start teams. We maintain skilled teams working in a wide range of technologies from web application to mobile apps. The added benefit of using a company like ours is that we come with resources that a software project needs time to time but not always - resources like technical writers, designers, testers and systems support. And you can take help from such resources on a need basis, greatly reducing your HR spend and managing your budgeting.

Online platforms for freelancers like UpWork or Fiverr are widely used by employers who want to hire a remote resources. These platforms tend to be good for smaller or one off type projects. However, you can find freelancer groups as well who work together to offer service to startup owners to build solutions. The services can be web or app development to custom CRM solutions. This can be a really effective solution if you’re running low on budget. Also, you can find freelancers while knowing their actual review and rates. 

Social media and LinkedIn also can be a great option if you want to know the detailed and previous portfolio of employees. The experienced ones post their portfolios there, specify their skills, and the level of their endorsements shows their overall efficiency at their job. Even they don’t match your preferences, you can always connect with them and other people to get more people’s profile. Start by searching for the keywords relevant to your requirements and get the list of potential employees. Browse through the results, assess the profiles and send a proposal to them.

Offline search

You can always go search for technical people in person in events. A lots of conferences, meetups and hackathons take places regularly where you can find the right person to work with and discuss your work briefly. Especially in hackathon, you can get to see the efficiency of any individual or team who are just an event away!

Remote Resources

You don’t always need your team to be situated in the same spot. The entire world can really be your source of software hires! Remote software development teams can easily be managed using collaboration tools like Slack, Zoom, Jira, etc.

Remote software teams should only be hired through reputable software companies as they provide infrastructure for managing those resources, provide the right working environment, run the payroll, manage their holidays and work hours, etc. The most crucial reason for hiring remote teams from established software companies is the things around a team that makes a team coalesce and work with motivation. These include great office spaces, network and systems support, team activities and team building events. All of these keep technical staff motivated and companies benefit from that motivation.

Recruiters and managed service providers

Last but not least, if you want to outsource the hiring work to save your time, you can work with a recruiting agency or with a MSP aka Managed Services Provider companies who are mainly specialized in technology recruitment. This is a path we don’t suggest to our clients unless they are really short on time or are desperate for resources they cannot find in any other way. The main reason for putting this as a last resort is the difficulty of finding the recruitment agency that really understands your needs properly. Usually these agencies are working off a generic keyword driven hiring agenda that is not always the perfect fit for your actual need.

Market testing your software idea

Have a great idea of a software that can make lives better? But, no idea of how to find out if it is a good fit for users, and there is really a demand for this on the market? To find the answers read on.

The setting

Great products don’t get started with “what?”, it starts with “why?”. And, market testing for your software idea is also associated with this.

Testing your business idea is an essential first step to determining your target market and tailoring it to their actual needs. A software product needs lots of testing in its journey of being purely conceptual to a real product with real users (ideally paying users!). This is true as much for software technical as for market research. Any software product should go through a set of rigorous market testing even while it is just an idea, and then through design, prototype or fully developed stages.

The start

Writing down the basic anatomy of your product can be a good start. Breaking the whole idea into narrow parts helps a lot while integrating it as a whole. This involves finding your buyer persona, what value proposition your idea provides, and mostly, what problem it does solve and how it is unique from any others. Don’t forget to analyze your competitors and how they have tested their data and what they didn’t. Try to gather knowledge from reliable sources to have a lot of ideas to market your idea. For example, if you are thinking of making a customized ERP look at what a typical ERP RFP looks like.

Organic first

In this digital age, we have a lot of options to test the concept idea to people. Use your social media wisely in this case. Write a LinkedIn post, start a twitter thread, etc. Ask a question in quora. Ask if your idea will solve any one’s problem, Check out existing threads about software ideas related to your idea. Or just check out software idea questions generally, these might lead to some very insightful threads, here’s one about finding software ideas. Connect with communities from the appropriate social media forums where your target customer is finding solutions. This work as an organic testing which might need some time but can bring really great value for free. Remember one thing, many can like your idea but not interested in buying the product. So, this is not the end of the marketing test.

Moving forward, try to be creative with your marketing tests. Even before developing the whole product, just use the conceptual prototype with beta testers who are always curious to try out new things. Offering samples or customized takeaways can be ways of doing that.

Testing with a budget

Now, it’s time to hit the market with some real action. People liked your idea, joined for a beta test, but who’s going to buy? Create a market testing budget - as you’ll need cash up front for some of these activities.

Start with a landing page attached with a sign-up form can bring you potential customers in the early stages. Hubspot is an awesome tool for setting up free landing pages with analytics support. And if the idea flies and you do end up making the software, hubspot would be very useful to coordinate your marketing and sales effort. So it’s a good point to start. Also, use surveys to get to know the trends, what tailoring your idea needs and act accordingly. You can use a lot of free and paid tools like HubSpot's A/B Testing Kit, Google Optimize, Freshmarketer, Optimizely, Omniconvert. Crazy Egg. AB Tasty or Adobe Target. 

Prototypes and walk-throughs

After you have gone through the initial steps of market testing and you see a definite need for the product you are thinking of, you need to test with something more definite. This is where prototypes come up. Instead of building out a full software, a very expensive process, you can use prototype or even a series of pictures to represent your software and seek feedback that way. There are many free and paid tools to build a prototype for your software. Proto.io is one our favourite but you can use others that less expensive or free.

Once you have the prototype you can then start using a more formal approach to testing by running user group sessions or events to show off your tool and seek feedback with surveys. Some of these can be expensive but it’s worth the investment to get early feedback not only on your product idea but also about design, interaction and usability. This is also time when you should involve a software company like us to work on the design of the interfaces and help you through the user feedback and feature identification process. We’ve helped hundreds of companies and software entrepreneurs brainstorm and design software apps.

Team lead skills in the remote teams world

Software team leadership is always a challenge. A great team requires a fine balance of super geek, hyper proactivity, low ego and great sense of business needs - an almost impossible mix. We’ve written extensively about the traits and good practices of software team leads. Here’s a recent one about some of our top tips of becoming a great software team lead, based out of a survey we did with our teams. In this already complex and difficult role a new set of skills requirement is becoming very important - the skills of maintaining remote teams.

In the post pandemic world remote teams are becoming the norm. Remote software developers can based locally or be dispersed over a wide geography. With remote teams comes additional layers of issues like communications issues, cultural gap, teambuilding challenges, etc.

We asked our leads who manage remote teams for their best advice about managing these remote software developers well. Here are the top tips that came from this survey:

“Focus on output rather than effort”

One of our leads say this is the only mantra that a software team lead working with remote software developers need. His only focus is on the achievements of the team rather than how long it’s taking things to be done.

“ If a developer takes just hours to complete something that usually takes days, she is being productive. I don’t care about how many hours she is working per day”

— Software Team Lead

This is not to say schedules are not important. Obviously. Keeping to a project plan is essential. But a great lead has to balance that with the fact that everyone works differently, which means a one-size-fits-all solution just doesn’t work in the software space.

“Monitor teams and give feedback regularly”

Constantly monitor and quick feedback is the key to managing remote team says another experienced team lead. He says his top priority is to keep an eye how the team is performing and give early feedback if things start to go wrong. Questions to ask are:

Is the team underperforming? Do they need training or mentoring?

Is the team overperforming? If that is the case could they take on more tasks?

Is there a team member who is not communicating enough? Or the reverse: is someone putting up too much noise in the discussion thread on the collaboration platform?

Do all team members understand their colleagues well? Is there a cultural issue that is creeping up creating a divide in the remote team? (this last one is the super important one when you have team members from different countries - social biases start creeping up in technical conversations that need be addressed asap).

“Find the optimal working times”

Remote team members generally mean different time zones, and even if the time zone is the same WFH leads to disparity about when is the best time for work for team members depending on their home circumstances. It’s vital for the health of the project and the team to find out when your remote team members are most productive, what are their preferred time for working. Once you have this information you can setup a system where there is the most overlap between the team members and yet there is no loss in performance.

“Forcing a fixed time on remote teams just doesn’t work in the long run.”

“Set guidelines”

Remote working gives your team certain flexibility, but that should not mean they can do things as they please. Setting guidelines about remote work/WFH is essential to create a set of rules that team members can follow and refer to when things go wrong. Setting these ground rules will mean the difference between a team that is well coordinated and a team that is constantly going through one chaos after another.

Note that guideline also involves scheduling. You can create a schedule for them that offers some amount of flexibility to your remote team. That is one of the biggest positives of remote work environments, and as expected studies have found that more than 78% of employees agree that flexible scheduling makes them more productive.

“Publicly acknowledge hard work”

It is vital to acknowledge team member’s success in the remote team working environment says one our most experienced team leads. That is because team workers can feel isolated and underappreciated in the remote team working model. It becomes the team lead’s job to find successes to celebrate and bring high performing team members to highlight. This creates motivation, takes away the isolation and the feeling of not being appreciated.

Acknowledge success during team meetings. Praise during a team meeting is a great way to publicly recognize someone’s success. It gives the team member a team-wide exposure and recognition of their capabilities and skillets.

Remote teams are here to stay and software teams and their leadership has to learn the new set of skills to manage such teams well. Hope this little set of tips from our team leads helps in that journey.

Remote software teams - the secrets of efficiency

Remote software teams are fast becoming the norm. It was a growing trend pre-pandemic, but the pandemic has accelerated that trend, proved that it is a workable model and has broken the barriers that usually slows the the pace of change for such paradigm shifting ideas in an established space. No longer are software products and companies stagnated by the lack of skilled resources in the neighborhood. Software resources can be added to a team as and when required from anywhere in the world. And this reality is completely changing the landscape of how software teams run and operate.

As with any new way of doing things, a new set of good practices are emerging for managing highly spread out remote software teams. Some of the old ways of doing things have to be adapted in a certain way to make things more effective. We’ve been writing about our experiences in managing remote software teams and setting up workflows that bring about the culture of enthusiasm and spontaneity that is the seal of all good software development teams. Today’s post is about the lessons we have learnt about making the remote software team more efficient at work. Here are some of the top tips from our technical leads:

Enforce the use of tools and process

Tools are essential for remote software team. Sometimes in software development they feel like overhead, and software developers hate following the rules set out by the team about work process updates on collaboration tools. For teams that work together, the process often breaks down because of oral communications or just plan and simple laziness, yet it may still work out, even this break down can accelerate the development process. Not true for distributed remote teams. With team members working away from each other, sometime working in completely different timeslots and often communicating in different languages - tools are the main process of keeping things moving forward without confusion. The number one loss of efficiency in remote teams come from confusion about a task and circular nature of debate about the work at hand. Tools reduce this inefficiency. So remote teams must make sure that they are not deviating away from work process and they are using the tools as planned. I’m being very expansive about the meaning of tools. When I say tools I really mean any pre-decided set of steps that the team uses to get their jobs done. Tools can be the collaboration tools like Jira or slack, or they can be some build environment, or deployment standard, or email chain that is sent out after every push to the repository, etc.

Make it easy to ask anything

The biggest downside of remote teams is the lack of face to face interactions outside of work between team members. These interactions break down the barriers between team members, making them operate at social level, ideally as friends. We’ve suggested many ways a company can try to solve this problem and bring the team together. The goal is simple: make it easy for team members to ask anything to other team members. There should not be a worry of “what others will think of me” or “she might think I don’t even know the basic stuff” etc. Having that sort of barrier means that remote team members spend an inordinate amount of time solving something that is already solved or could be solved in a matter of minutes if someone else in the team answered a simple question. You’d be surprised how many times hours even days are spent by software developers looking for a certain thing, say a database file, just because he did not feel good about asking about the location of the file.

“Failure is a learning opportunity” culture

On the same lines as the previous tip, the remote team should feel that failure is totally acceptable in software work. If the remote team members get a feeling that they have to hide their failure - because it reflects badly on their performance, or that their boss somewhere else in the world might get angry about the failure, they’ll waste time in trying to hide that failure. Time will be spent trying to fix it with a patch that will break down soon, or even worse shift the blame to someone else in the team. All such behavior leads to downward spiral of inefficiency, loss of team morale and eventually bad software. The solution is simple, from day one the team’s motto should be that failure is acceptable, when it happens discuss it with other team members, find a solution and learn from it so that the team doesn’t make the same mistake.

Team leads are the sheep dogs too

Team leads are typically the shepherds - leading the flock forward, showing the way to go, etc. But in remote teams the team leads have to play a significant role of sheep dogs too. Sheep dogs help the shepherds from the rear, making sure that no one is left behind, or no one at the rear are going in the wrong direction and most important everyone knows what the direction go is by making quick corrections to small mistakes as they happen. Remote teams spread out geographically has a much larger chance of individual members getting lost or going the wrong way in their work compared to teams that work under the same roof. This is where the team lead’s sheep dog role comes in. A team lead should setup a process where she can regularly check the status of work of team members - code reviews, regular meetings with individuals, product demos, etc. all help in this sheep dog work.

Solving issues fast become more important

All issues should be solved quickly in any software project - that’s normal. Issues lead to confusion that leads to delays. But in remote software teams this fact is magnified hundreds of times. A small issue, say a broken build, leads to a bunch of developers working in a completely different timezone to be sitting and waiting for someone to wake up from sleep to fix the break. Solving issues as they come up becomes a priority for team lead in distributed teams.

Goals first, everything else follows

Last but not least, remote teams need to have clarity about the goal of their work and of their company. When the team knows the goal it’s decision making process becomes much more independent. Individuals don’t have to wait for a team lead to answer every question for the work to move forward. With every team that’s important, but for remote teams clarity about the goal of their work may not be communicated enough. They may not be hearing from the management or the business leaders a lot. Their interactions get limited to a small section of the company - usually the technical teams. And this might lead to confusion about what the overall purpose of the work is. A company might be planning to build the fastest checkout tool for eCommerce, but remote developers may understand that they have to build out the most customizable interface possible for the checkout - leading to decisions that make the interface slow. If the goal was made clear then developers would then probably compromise on features of the customization in the interest of staying on the goal of making the interface fast.

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.

Work and play together - the secret of great work culture

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” - how working in an environment where fun is built makes for a great workplace.

Work and play together

Happiness is a core value at Kaz. It stands next to our other core value of the highest standard of work quality. We have always believed that workplace should be fun and relaxing which in turn will make the workers relaxed and more engaged. With this simple principle in mind we have integrated play in our work by introducing areas at work for relaxing, playing games like table tennis or cricket, for drawing what ever is on your mind on board, etc.

This concept of “work should be fun” creates work ethics that is spontaneous and ownership driven. This is the big reason why teams and individuals at Kaz take responsibility in getting their work done without any micromanagement and structure of command and control. And we think this is the only way to work in the creative field such as ours.

Play areas built into workplaces

A picture says a thousand words. Here’s one that tells the story of a typical day at Kaz. We have no qualms of putting a meeting room right next to a place where others might be playing. And time and time we have found that the play doesn’t affect the work nor vice versa. Yes, sometimes things might be too in depth in the meeting that the noise of play might be distracting - and that’s super easy to fix anytime by asking the players to play later. But the essence of the idea that work and play can and should happen together stays in the mindset of everyone. This mindset helps everyone to relax and creates a work environment that is stress free and happy.

Research supports our approach

Don’t take our word for it. There is a growing body of research from diverse fields like Psychology, Business management, Economics, etc. that support the thesis that play at work increases efficiency and performance.

Studies have shown evidence that play at work is linked with less stress and burnout. Play directly corelates with better job satisfaction, competence, and creativity. Research data indicates that when an employee is assigned tasks that are presented playfully, she is more involved and spend more time on the finishing the task better quality. The benefits of play goes beyond the individual employee. Teams and groups show increased trust, bonding and social interaction, sense of connection, and a decreased sense of hierarchy when play is introduced within the work culture. Studies show that play at work can benefit the entire organization by creating higher employee commitment to work, better decision making, and increased creativity. In a study done over 2000 employees in UK it showed there is a clear correlation between the uses of fun in the workplace. Amongst other data found was this interesting statistics:

• 79% of employees think fun at work relieves stress

• 62% of employees who have fun at work take less sick days

• 45% of employees in a traditional business don’t feel engaged

• 87% of employees are less likely to leave if they are engaged at work

Although if no studies were ever done we would have confirmed from our own experience over the past 18 years that work and play works together! And that’s just one of our big not so secret secret :)

Happy birthday Kaz!

Remote software team - setting up the collaboration

Remote software teams is way forward in software development. No longer are companies tied to particular locations, waiting for resources and skills to be available and delaying the entire software process. By finding the right software resource at the right time and forming a remote team to work with any onsite team completely changes the game - and companies that are realizing this are getting ahead in the game. This is just one more evolutionary step in our ever changing industry, a step that has just been accelerated by COVID but it was a step that was bound to happen at some time or other.

As with any paradigm shifts such remote software teams come with some adjustments in work practices and process. We’ve been working with hundreds of companies around the world for the past 18 years in providing software resources and hosting such remote software teams. Here are some our tips about the right setup for collaboration and workflow for such remote teams.

Setup a clearly defined work process

This may sound obvious but you’d be surprised by how many teams we’ve come across that just assumed things about the work process for collaboration of remote and onsite teams. This is understandable though, when a team works side by side many of the work processes are automatically defined and agreed upon without explicitly defining them. An example would be the timing a push of latest code into the shared repository - if the team is all together very soon a standard of when a push is appropriate and acceptable is agreed upon. A few wrong moves by a new team member quickly gets fixed by visual (and sometimes very audible!) ques from the rest of the team. But now imaging when part of the team is spread out remotely. The same mechanisms of automatic agreement doesn’t happen fast and sometime never. There is no way out on this, for teams with remote members the lead has to layout a clear set of instructions for major work processes. What the major elements are depend on the nature of the project and the team members but here are some that are obvious candidates:

Work timing - when to be available, when are good times for pinging without advance notice, when not to poke, etc.

Tools - defined set of tools for collaboration like issue tracker, IDE (specially versions of IDE)

Reporting standard - when to cry for help, when to warn about delays, what to report and what not to worry too much about, etc.

Testing rules - what should be the minimum set of tests on the developer’s side (even if unit testing frameworks are available for the CI/CD), etc.

Code repository rules - when to push, who can merge, etc.

Meeting rules - what tools to use, what are the good times for combined calls, how long the meetings should be, etc.

Create an open communications channel

With team members spread out geographically the open communications channel is essential for a healthy team dynamics. One common strategy is to have video call regularly with the video on (visual is very important forming the bond between team members). An awareness withing the onsite team about keeping the remote team members in the loop on all important decision making process is absolutely essential. Running regular video meetings is one of the best way to avoid issues caused by communication gaps and it has the added benefit of making the remote team members feeling valued. These video meets should ideally to be planned in advance and hosted at a time that works for everyone. A random last minute email to setup these calls isn’t the way to do it. Formalize at least a regular video meet by setting up a recurring invite so that everyone are reminded before each session.

Regular team calls should have the goal of keeping remote team members updated and also getting feedback. Remote teams should not find out about important decisions at the last minute. This has huge impact in lowering morale within the team members and would start creating a divide between the onsite and remote staff. If there is a new process change or some important company news a specially rededicated call aimed at all the members should be placed to keep everyone on the same page.

Use team collaboration tools as much as possible

For onsite only teams we always push for face to face informal interactions more than a very process and tool centric interaction. This is completely the reverse when the teams are spread out. In such teams you should aim to have all major collaboration purely tool driven. A good example would be work distribution on a issue tracker. For onsite only teams it’s usually great to have a quick ad hoc meeting to split a task and then asking team members to just create and assign the tasks to themselves - it moves the needle move faster and just feels less clunky, less “bureaucratic”. But doing this for remote teams is recipe for disaster. It’s best to rely on the tools, have as much as possible of the discussion on the tools (e.g. a discussion thread on the issue tracker, or slack, etc.).

It can be difficult to keep track of the progress and monitor the status of the project at every stage for remote teams. Using a great project management tool like Atlassian Jira is essential. Such a tool must have features for creating tasks and subtasks, assigning them to team members, tracking the task and setting time estimates for those tasks, etc. Such a system should also have a way for discussing details of task, a way to collaborate at the task level with a log of what is going on. Here’s a screenshot with an example of an ideal task ticket tool feature.

Remote software teams - setting the culture

The pandemic has validated the concept that remote work is not only sustainable, it is actually better in some cases than onsite work. This is especially true for software development phase, where the work is very much supported by collaboration tools and the work products are digital and wire transmissible by it’s very nature. And the biggest benefit that came out a fully remote operation is that the key factor that makes software projects difficult - availability of talents - is resolved easily. Remote software resources can be found from anywhere in the world as and when needed. Given this state companies all around the world has embraced remote work and remote teams.

Although this paradigm shift geographically distributed remote team is happening at breakneck speed somethings remain the same. A software team is still a team of humans that must work together with passion to create great software. There is no way out on that theme. So the new challenges that companies are facing are the challenges of keeping the remote team motivated and connected. This is indeed a big challenge as team members from far away, from different time zones and maybe from different cultures make for a difficult setting for create an unified “team feel”. The usual strategies for bringing on the team feel can’t be done and you need to come up with new solutions. We wrote about our best strategies in a recent article about remote team building. Today’s post is about the other side of the equation - the changes and considerations of workflow, processes and policies that enhances the collaboration and the team feel of a remote software team. Here are some out biggest hit in this area:

Create a culture of empathy and collaboration

Empathy is the key to a sustainable creative culture that enhances and enforces the values of great software teams. With processes and talent in place the only factor that makes a software organization excel is its culture. This is absolutely essential for creative organizations and this one factor differentiates companies that are performing at the highest level with quality, scalability and repeatability of performance. And of all the strategies culture is the hardest one to get right.

The schematic here shows some of the guiding principles we aim for in setting up the culture for remote teams. If we can get these key features right in a remote software setup then we are usually on the right path of creating a culture that works. Remember, the culture of a remote team doesn’t happen overnight, it’s not like switch you can just turn on. You have to create the right environment, take the actions that moves the team towards the right direction and then hope that it will all work out and the team’s work culture will be the right one for software development. Every team will have it’s own unique way of doing things - it’s own culture. In the 18 years we have been running remote software teams hundreds of companies around the world we’ve seen hundreds of variations on team culture. Each one of them were different, some worked better than others but overall the environment for the team were more or less the same. So it’s like throwing a pair dice, but you can improve your chances of winning by getting the playing field tilt the right way! Here are those key factors in more detail:

Consensus driven

We usually start with a consensus driven decision process where all team members have equal say in major decisions for the software project or work process. The goal is to introduce by policy and with explicit management preference a process where a vote is taken on all decisions. There is not feel of someone having more power than other just because they are at different level of seniority or from different area of work (say someone from HR). This consensus driven culture will enhance the feeling within team member far from each other that they are individually valued and their thoughts are taken into consideration. We’ve found that it’s really easy for a remotely distributed team to start feeling that they have some disadvantage being away from a certain core group or geographic location. This is especially true when a certain portion of the team is onsite working together whereas the rest are remote.

Low red tape

There needs to be a strong concern to setup everyday work policies that require the least amount of red tape. The less cumbersome the process for say taking a holiday or reporting a project status is the less the team will feel that their time is being wasted. This is true for onsite teams (all of these points actually are relevant for onsite team) but it becomes very important for remote teams. Because of time zone differences or just the availability of the right person to move the process forward, any red tape becomes hugely frustrating very fast. This is something that’s totally avoidable. Remember that the goal is to take away as much as possible the “pains” of working remotely and red tape is the easiest evil to take away. You might have to fight a few battles with the management or the HR but it’s worth that fight.

Flat hierarchy

Software teams just don’t need a lot of hierarchy. Usually a team lead who looks after a bunch of developers (maybe with different levels of experience) is all that’s required to make progress. So, essentially at an everyday level there should be just 2 levels - the lead and the rest. On a reporting level the lead might have a layer or maximum two above her. But that should be it. Having a flat hierarchy just makes for a fast and efficient decision making ability and that creates an efficient team. Now in this mix when the remote team comes in, every problem related to complex hierarchy magnifies ten times. Every decision making start percolating on the layers, bouncing up and down the layers before something final can be achieved. So flat hierarchy is the only sane way of running remote teams. Ideally, individual remote team member should only have one level of management to worry about - so, for example, a remote developer should take instructions from just one team lead somewhere, etc.

Gelling events

These are events where the team members are brought together virtually and if possible physically to connect as individuals. We talked about some great strategies for gelling a remote software team in different post. These are essential in creating a culture within the software team.

Fun, relaxed and creative

This is for the overall tone of the workflows, communications and practices of remote work. By setting a tone of informality the management creates the feeling of ease within the remote software developers. This is essential for moving team forwards in creating the right work culture. In essence this is the background to all the other activities and actions that a company must do for a great software team that works remotely.

Software development with Unity

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

Unity the game engine

Unity started in 2005 with a very specific goal:

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

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

Multi platform support

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

Easy to use and learn

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

Documentation, tutorials and templates

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

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

Awesome forums and community

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

Rich marketplace for assets

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

Flexible Licensing Model

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

Analytics built in

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

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

Mobile app development in Bangladesh

Freelancers in countries around the world.

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

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

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

Native

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

Flutter

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

Ionic

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

Xamarin

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

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

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

Get an estimate for a mobile app

Top 5 challenges of building an effective software team

1. Finding the right people for your team

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

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

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

2. Getting your software developers to communicate effectively

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

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

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

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

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

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

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

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

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

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

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

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

Sourcing your software talents from around the world

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

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

Step 1: Find talents anywhere in the world

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

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

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

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

Step 3: Get your software made!

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

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

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

Why do software projects fail and how to save them

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

Facts & Data

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

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

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

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

Bad project planning

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

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

Lack of communications or excess of communications

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

Too many targets & unrealistic goals

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

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

Too large a team and too large a project!

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

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

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

— CHAOS Report 2015

Top 10 Questions you must ask your software vendor

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

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

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

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

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

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

2. What happens when you fail to deliver something?

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

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

3. What happens if a team member leaves suddenly?

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

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

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

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

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

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

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

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

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

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

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

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

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

Good luck with your vendor hunting!

How to motivate a remote team

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

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

— Survey by CoSo Cloud

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

Here are our top tips for motivating your team remotely.

1. Set clear expectations for your team

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

2. Be transparent about what is happening

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

3. Communicate regularly

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

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

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

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

— www.thinkwithgoogle.com

The biggest bugs in software history

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

The most expensive

Ariane 5 Flight 501

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

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

The deadliest

The patriot missile failure

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

The most fun

Windows 98 presentation BSOD with Bill Gates

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

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

How to make a software project plan that actually works

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

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

Decide on a project timeline and set deadlines

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

Create a list of tasks with a democratic estimation

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

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

— Joel Spolsky

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

Write down the resources needed for each task

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

Set up milestones that you'll need to meet

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

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

Stick with it!

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

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

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