It has been reported that Amazon will lay off 10,000 employees following the footstep of Meta, who has planned to let go of 11,000 workers. Elon Musk already fired 50% of Twitter employees last month.

All sectors are affected, but IT companies have undergone some of the most dramatic changes – with thousands of IT workers being let go in the last few months. These layoffs are having a massive impact on the lives of many and have created a wave of uncertainty in the industry.

IT Companies have lowered their growth/hiring targets to reduce burn rates and have adopted cost-cutting measures to stay afloat. This has resulted in thousands of workers in the IT sector losing their jobs.

This article will discuss the impact of these layoffs on the USA IT market and explore the implications for the future. We will also discuss how the affected workers can cope with the situation and look for solutions to their problems.

Which Tech Companies have Laid off?

Every week brings a new wave of layoffs in the IT sector. It all started earlier this year with smaller and medium IT companies who wanted to reduce their ongoing spend has now extended to big giants like Meta and Amazon.

Some of the most prominent tech companies who laid off their workforce following Meta and Amazon are;

• Adobe fired 100 staff on 6th December
• Lyst fired 50 staff on 29th November
• HP fired around 4000-6000 staff on 22nd November
• Cisco fired 4000 staff on 18th November
• Roku fired 200 staff on 17th November
• Uber fired 3,700 staff on 10th November
• Intel fired 10,500 staff on 19th October

These are some of the biggest tech companies that have laid off their staff. However, many other small and medium tech companies have also had to let go of their employees due to this severe recession.

Major Causes of massive layoffs in the USA IT market

Over-hiring during Pandemic and increase in interest rate by Federal Reserve to fight inflation are the major reasons for massive layoffs in the US IT market.

Many tech startups that experienced tremendous growth in 2020, particularly in the real estate, financial, and delivery sectors, are beginning to experience a slowdown in user activity.

During an employee Zoom call, Mark Zuckerberg, CEO of Meta, cited inflation and over-hiring as the main causes of the layoffs. He said that not only had online commerce returned to prior trends before the Pandemic, but that the macroeconomic downturn, increased competition, and ads signal loss had caused their revenue to be much lower than expected. 

Salesforce, a cloud-based company, is also reportedly cutting hundreds of jobs. In a statement, a Salesforce spokesperson stated that their sales performance process drives accountability, which can, unfortunately, lead to some leaving the business, and that they will support them through their transition.

The Pandemic has also brought about a shift in the way companies are hiring. Companies are now relying more heavily on remote working and automation and cutting costs in the process. This has led to a decrease in hiring in the US IT market.

Businesses are increasingly focusing on digital transformation, process optimization, and cost reduction. This has led to massive layoffs in the IT sector, as companies have been forced to make cuts to remain competitive.

The Federal Reserve’s recent 0.75% rate hike appears to have slowed down the job market. The cost of financing the projects becomes more expensive which is another reason why tech companies are laying off.

On December 14, the Federal Reserve sent a clear message that their battle against inflation is still ongoing. This was evidenced by their decision to raise the benchmark interest rate to the highest level in 15 years.

The Federal Open Market Committee voted to increase the overnight borrowing rate by a half a percentage point, bringing it to a targeted range between 4.25% and 4.5%. This is the most aggressive policy move since the early 1980s, with four straight three-quarter point hikes implemented over the past few months.

Higher interest rates have negatively impacted economic growth, leading to recession and unemployment.

It is likely that the layoffs will continue in the upcoming months. Companies are also beginning to make decisions on how to best manage their workforce in the coming months. They are implementing new strategies such as remote working, automation, and process optimization to remain competitive and remain profitable.

Impact of massive layoffs in the USA IT market

Whatever the causes might be, we can’t deny the harsh reality that it has hurt the US economy badly. Many US IT businesses have had to reduce their workforce, resulting in the layoffs of thousands of IT workers. This has created a ripple effect throughout the IT industry.

Some of the most devastating impacts of the layoffs include;

• Loss of knowledge and expertise

Many IT workers have decades of experience in their areas of expertise, and the layoffs have resulted in the loss of this valuable asset. This has created a significant gap in knowledge and expertise, which could be difficult to fill.

• Reduced innovation

With fewer IT workers, businesses have had to reduce their innovation efforts, as they lack the resources to invest in new technologies or research. This could lead to industry stagnation, as businesses cannot compete with other companies investing in research and development.

• Disruption in business operations

The layoff has also disrupted business operations, as teams have had to adjust to the loss of key personnel. In some cases, businesses have had to completely restructure their teams and operations, leading to project delays or the loss of time and resources.

• Loss of Customer Confidence

Customers feel uncertain about the ability of the company to deliver on its promises after the old employees have been laid off. This has caused customers to become more cautious and hesitant when engaging with companies that have experienced massive layoffs.

• Increased competition

The layoffs have caused a surge in competition among IT companies, as they have to compete for fewer resources and talent. This could lead to decreased innovation and productivity, as companies have to focus on cost-cutting and efficiency over creativity and innovation.

• Damage to company image

The massive layoffs have caused a lot of damage to the reputation of the companies involved. Customers may view companies as less reliable, and employees may view them as less committed to their workforce. This could lead to long-term damage to the company’s image and reputation.

• Poor staff morale

The massive layoffs have caused a lot of distress and anxiety among IT workers. This has resulted in a decrease in morale, which can have a negative impact on productivity and efficiency. It can also lead to decreased loyalty and commitment among employees, who may feel uncertain about job security.

How can Hand-Picked help you?

Hand-Picked is the perfect partner for companies looking to access top talent. With our strict recruitment process, we can help you save time and money by quickly assessing and selecting the best IT professionals for your business at a fraction of cost.

Our rigorous process comprises several steps, including interviews, technical evaluations, coding and defending test projects. We look for talented people with a strong passion for technology, problem solving and ability to integrate into a team.

We are committed to providing a comprehensive service that is sure to meet all of your recruitment needs. Our experts are on hand to guide you through the recruitment process and help you find the perfect employees for your team.

Get the best talent in the industry with Hand-Picked & hire with confidence!

From your point of view as a CTO, quick and effortless scaling up of a team is an essential business operation to deliver a product in a shorter time-to-market. When your company is growing and you need to scale up your product and services to reach more customers, finding relevant resources becomes a time-consuming task.
Partnering a software outsourcing company can effortlessly scale up the team. Moreover, up to 40% of CTOs think that software development outsourcing can be convenient in a fast-paced environment.

On the other hand, if you’re a HR Manager you already know that hiring employees has always been a time-consuming and expensive task. This is particularly true considering the high turnover rate and dynamism of the IT labor market.
Having a partner that feeds your process with vetted IT resources is the key to streamline the IT resource onboarding process.
It also helps your company to reduce the hidden costs since more than 68% of companies spend at least one month to recruit a single developer. At the same time, one in five new recruits must be replaced.

The correct partner must meet many aspects including technical quality of the IT resources, a reasonable price, a quick end-to-end process, the ability to adapt to your specific needs and they must give you direct control over the talent so you can handle them as part of your IT team.

In the same way, a smart strategy to outsource IT resources requires selecting a provider that has available resources to be hired immediately. Those resources must be already trained to work independently but integrated and communicated with the rest of the team and in the same timezone.

About Hand-Picked

Hand-Picked is a Latam-based company that provides remote software developers selected by their high motivation and proved experience in the Industry, to startups and mid-sized companies all around the world. Since 2017 Hand-Picked developers have helped dozens of companies to successfully implement their projects.

Contact us

We had an ads system (picture something like Google Ads) in an e-commerce site. And to make it simple, let’s say that we had 3 key endpoints:

• One to retrieve ads
• Other to count impressions (a pixel request placed by the retrieved ad)
• The last one to count clicks and do the proper redirect

To count impressions, that endpoint should get an encrypted parameter, decrypt it, verify the (internal, decrypted) parameters with a signature, and then use those values impressions counting.

While the code that generated those links was deployed in servers that were readily updatable, the code that read those links (impressions counter) was deployed in an old monolithic system. Those servers were only deployable every 2 weeks.

• Link generator –> in servers that could update
• Link/impression reader –> in servers that couldn’t update

When this code was released, both servers (clusters indeed, but let’s call them servers for simplification) were running JDK 1.5.

In a given moment the server which was part of the readily updatable ones, got updated to JDK 1.6, and at that point.. we lost something…

In the morning we were alerted by the abnormality of having 0 (zero) impressions. Fall that could not be attributed to anything organic, but a code issue.

So, what was happening?

HashMap implementation changes

Remember that I said we were creating those links with a big encrypted parameter? That had a signature mechanism that was analyzed by the impression reader server code, and if the signature (simply done by hashing) wasn’t correct, the impression was discarded.
So the code for the impression counter link was something like:

for (String key: parametersMap.keySet()) {
    appendParameter(key, parametersMap.get(key),paramsBuilder); // Appends parameter
    stringToHash += parametersMap.get(key); // append value for the string to hash to get a signature
}

// calculate the hash and add some salt
stringToHash += secret;

signature = calulateHash(stringToHash);

appendParameter("signature", signature, paramsBuilder); // Appends parameter

On the reader/impression counter side:

for (String key: parametersMap.keySet()) { // before this, this code put the parameters into a Map
    stringToHash += parametersMap.get(key);
}

// calculate the hash and add some salt
stringToHash += secret;

signatureToVerify = calulateHash(stringToHash);

Can you spot the error there? It happens that in JDK 1.6, there was a slight change in the hashing code in HashMap, which made another slight change in the order elements were placed in the internal hashtable (an array).

So at the point where the impression counter server did .keySet, it provided those keys/values in an original order (by JDK 1.5) while the new code that generated that, was delivering those values in a different order (by JDK 1.6).

Obviously the bug is that relying on that order from the HashMap to append and retrieve values was a violation of the HashMap contract (and Set for instance), where it is expressed that you shouldn’t rely on the HashMap keys order.

This class makes no guarantees as to the order of the map; in particular, it does not guarantee that the order will remain constant over time.

Extracted from the HashMap class Javadoc

Developer’s quick solution to save the day

As the server that counted those impressions wasn’t available for an update (next code upload was scheduled for the next 2 weeks!), we had to do something on the ‘pixel generator’ with that link.

As the counter was expecting those parameters in a given order, we decided to use the old HashMap code, so we could get the same order to verify the signature.

The parametersMap object ended up being an instance of the HashMap15 class, for the sake of letting it sort those elements as the impression counter endpoint expected them to be.

Cleanup and conclusion

In a next release we did sort those keys before relying on the order and ditched that temporary class. (It wasn’t an elegant solution to keep).

So that’s the story of why we should know about data structures, contracts and reading docs… or maybe about minor bugs that could go unnoticed until big consequences happen. Have you ever had to resort to this kind of tricks to save the day and continue operations?

A Tale of Two Cities Book Cover Photo by Lisa from Pexels

Accesses

Let’s take advantage of your new hire from the start. We don’t want to waste hours in an initial setup when we have the chance to move with anticipation. So in this case, if you need to work with your infrastructure team to grant access to git, VPNs, JIRA, etc, you’ll need to create your preferred corporate secure email or in case that’s not available, use the developer’s email (With Hand-Picked, you can use their @hand-picked.io address for this purpose).

With the email as a starting point, you can create all other dependant accounts, and just wait for those confirmation or verification clicks on day 1.

Objectives

There are always tasks in our backlogs that need to be done that are suitable for onboarding processes. Also there are new features or big changes to implement. It is very important to have both kinds of tasks ready for your new developer, so you can assign them right away.

Suggest reading material

Is there any heavy download that the developer may need to start? Is there a way to start doing it before day 1? Sharing a link before starting could make this ready for the project beginning. Also, every project has peculiarities that make it different than the previous one. Maybe you use a novel library, VM or architecture that would need some reading?

An enthusiast developer undoubtedly would go and check and study all this new info beforehand.

Build Instructions

With projects complexity increasing by the day, build processes also became lengthier and more complex. Be sure that in your company’s wiki or knowledge base the process is up to date, so that doesn’t become a problem during the first build for your new hire. Obviously, it could happen that there is no doc available, so anything will help, from an email to a quick chat telling about any quirks in the process. This also includes accesses to any Continuous Integration platforms you may use, at least in the development environment (if every commit or pull request trigger new builds where the developer may need to check for errors).

Communication

Development teams spend a substantial amount of time in communication platforms, less than with their IDEs, but a lot nonetheless. As with other accesses, this one is particularly important as generally different teams are in the same platform, which may help with the initial setup (or any greeting or welcome rite you may have).

Project Tracking

So you have your objectives, deadlines and user stories. How the new developer will check them out? Let’s make sure they have access to the tool you use for this purpose.

Is your project starting from scratch and are you creating a remote team? Start creating boards on Trello and analyze it later in case you need an upgrade to Jira or other platform.

Introduce them to their peers

Introducing the rest of the team is of key importance as the developer starts working on their assignments. Sooner than later they will interact with designers, QAs, other developers, etc. Be sure you introduced them or let them know those names so they can quickly jump into those needed conversations.

Anything extra to sign?

Legal stuff, always important to have them already done so we can let creativity flow. If you need any extra NDAs or contracts, be sure to sign those deals before day 1. If you hire through Hand-Picked, we’ll be sure to remind you about this.

Company equipment

In case your Company workflow involves providing a laptop or equipment that may have already solved many points previously mentioned (already installed VPN, emails accounts already setup, necessary software installed) be sure to ship it at least one week before the initial date with your new developer.

Different countries have different times for their customs processing and anticipating it for at least one week with express shipping carriers -like DHL or FedEx- will make this less of a problem.

Final thoughts

What do you think about these points? Many apply to both new in-house developers and contractors, so we hope this guide helped you.

Hire your next Hand-Picked developer

Hand-Picked developers are motivated from start, so you will find them actively looking to integrate into your team as soon as possible. They will be open to any suggestions even before the contract begins, so you are welcome to communicate even if there is some time left before the project starts.

Cover Photo by Annie Spratt on Unsplash

Algorithms and Data Structures, why?

So let’s approach this question describing when knowledge of algorithms and data structures kick in -in unexpected ways sometimes- into our jobs.

One of the clearest examples is the usage of indexes in databases. It happens that certain queries start being very slow in systems where load and size have increased. Even optimizing the query (tables order, using less data, etc) would not be enough and the need of creating an index arises. Why indexes? Well, basic understanding of data structures make it easy to understand how data access speed is influenced by the data structures enabling it. The most common index in databases are B-tree indexes, which enable searches, access, etc in logarithmmic time. So we have it, algorithms and data structures come along again.

There is something called, “The Law of leaky abstractions” or “leaky abstractions” as is. Simply said, we could trust that the database itself will take the query and run it in efficiently. As we said before, this happens to be wrong in the long run. Sooner than later, the developer (or DBA?) will have to get his hands dirty and make that query perform better, regardless of semantics.

How does this all DB SQL Query thing relates with algorithmic tests? Well, those tests will reveal if the developer is aware of performance impact on many decisions during development. Unnecessary loops, or extra storage used may show disregard on knowing how things work, or that some knowledge is missing.

In some interviews we could find that developers rely too much on a given language libraries (data structures, strings, etc), to the extent that they think the library does magic and they wouldn’t explain “how they would implement it if they had to”. This kind of shallow knowledge gives us developers that, for example, don’t know how sorting works or why allocating memory for arrays in each write access is not good.

Solutions made by aware developers will always have those performance concerns on the radar, which makes those kind of solutions desirable. Clients know that, and in their search for great developers, most of them will want to be sure that the candidate has what it takes.

That’s the reason why at Hand-Picked we do both automated algorithm tests and live coding interviews. We are interested in knowing that our developers will make the cut and have low chances of obvious performance blunders.

I would like to mention some notes about performance in general, there is a saying

Premature optimization is the root of all evil

Credited to Donald Knuth, in a longer sentence

which basically states that acting on performance when it isn’t important, does more harm than good. Will you spend time trying out an idea for your customers to use, or rather seeing if you’ll need a Big Data database to store analytics? Above all, even though algorithmic knowledge is valuable, it is more valuable for the developer to have criteria when taking decisions. So there is also other phrase about priorities.

Make it work, Make it nice, Make it fast

This formulation of this statement has been attributed to Kent Beck

We can see that making it work (correct, do what it is intended) and ‘nice’ (which means, making maintainable code in some way) come first. What will you make fast if it doesn’t work at all? Rhetoric question, as it may happen that not making something fast enough, may make the thing NOT WORK AT ALL for a given volume, users quantity or data amount. So always pay attention, it may happen that performance could be of utter importance.

These two phrases and that counter-argument may look contradictory but they are put together here just to show how good criteria must always be on top.

Conclusion

As performance is an important point in Software Development, Hand-Picked verifies the algorithmic knowledge of its candidates through an Automated Coding Platform and a Live Coding interview. This way we know we are dealing with a candidate that has the proper tools to solve performance problems that may arise during their engagements. But we don’t exaggerate it, solving CS Olympics level problems isn’t a requirement to enter the Hand-Picked network, just a good level of criteria when coding.

Cover Photo by Alvaro Reyes on Unsplash

Wireframing / Interface Design

So you’ve come up with an idea. You create a new Activity or Fragment, a layout, some views –similar to this other big App-, so it shouldn’t be wrong, right? Soon you realize that this approach doesn’t scale well.

What if you needed to visualize different ideas without spending time compiling? What if a product manager intends to tell you an idea? Will he code? We wouldn’t expect that from the design team either.

Wireframing is the tool that comes in handy to represent visually your app (or website). Anyone may make a low-detail representation of the intended screen and the user flow. Some say wireframing is the skeletal outline of the app, which is very accurate: You may see that most wireframes are just black lines on a white canvas. Also, this helps in getting feedback about the interface before writing a single line of code.

Most tools these days offer the collaboration feature, where interfaces can be shared across the team or also might be edited collaboratively in real time. Also these tools may vary in terms of features, some will look more like skeletons (or even like hand-written), others with high-resolution (such tools may offer also exporting resources to use right away in your project), some others may implement “click-like” features to navigate the flow as if it were an app, or maybe support large canvases to cover an entire app (navigation flow) in just one screen.

You may find some of these tools (and discipline) with different names, that may have a similar meaning: Wireframes, Mockups, Interface Design, Workflow design, UX Design or Screen Design to name a few.

Last but not least, a very and simple tool is always drawing interfaces using just pencil and paper. Before remote came in as a norm (by the way Hand-Picked was already remote before it was cool), teams used to draw interfaces on paper or whiteboards. I guess it will return in some way in the future but you can already use it by yourself if you have that task. Sometimes it’s kind of refreshing and satisfactory to see how a screen we drew on paper ended up in a final working product.

Note: In many teams the figure of a Product Manager (or Product Owners, or a mixed collaboration with designers) will be in charge of delivering Wireframes as an input for developers. Developers with wireframes and designs (if such Wireframes are low-res) would then be in charge of following that documentation. This doesn’t make this practice something exclusive to Product Managers or Designers. Be it your initiative within an existing project or you creating your own app, you will benefit from wireframing ideas before jumping in to your preferred IDE.

Note 2: Always try to make screens that have one important objective for the user. This will end up with simple to use interfaces that even our grandmas will be able to use (tech-savvy grandmas).

A/B Testing

We start getting serious, we mean business. What am I talking about? For any project, we (plus the stakeholders) will have an objective. Name it, more users, more engagement, more sales, more usage, it won’t matter if the software is for an NGO or it’s profit driven, all the endeavour will have a target to reach.

So in this process, new ideas will come up, and we will decide how to implement them. But, what if the idea has some cons that may happen to hurt the objective? Maybe we need that extra field in the registration screen for marketing purposes (so, more revenue); but will that affect Sign Ups in general with this additional nuisance? (Let’s face it, in mobile each extra field is kind of an effort for the user). How much will it hurt?

In most cases there will be no other chance to try it out (as you may have different public or business than some other studies, it won’t be enough to go and check some 3rd party stats). Here it comes, A/B Testing. This ‘technique’ allows us to release features to a subset of users before applying it to all of them. So in case we see that the feature was successful, we would have a green light to rollout it to all users. To know if it was successful we’ll need to have implemented analytics in the app, something explained next in the article.

In Android A/B Testing could be as simple as toggling features by asking for remote configurations (per user maybe). The backend code may support this or we may use Android utilities like “Firebase Remote Config” and Google Analytics for Firebase. The new Firebase A/B Testing service has it all integrated, so it is also a well suited alternative if our target phones will have all Google Apps.

There are also approaches to take in case of having a Clean Architecture, where we could switch Views the behaviour based on what we configure in Firebase Remote Configuration, which is retrieved from the FirebaseRemoteConfig class. There is a good tutorial about AB Testing in a Clean Architecture project.

Analytics

We’ve talked about A/B Testing as one of the tools to improve and make our app successful. In other cases, to have new ideas, it is precise to know where will those have the most impact. For example, knowing what are the screens or features users use more frequently. Or where users have navigation issues or slow downs.

Integrating an analytics system in the app is of utter importance to have visibility about our app performance (business-wise).

In general, the process involved in most systems is as follows:

• Setup the library for the specific analytics service
• Log events (or screens and information) in particular parts of the app that you need to measure
• Debug events and see reports. Most platforms give flexibility for reporting, even with SQL-like filters.
• Iterate with new events and continue measuring

What services options are there? Google Analytics for Firebase might be the go-to option for Android, but as Google Analytics was first made for Web, it may be missing some points. It is also said that it’s a bit slow to update. Something interesting is that it can log events but also track screens, with integration with what are screens in Android, Activities. For the moment, Google Analytics for Firebase is free without quotas nor paid tiers. Time will tell in the future.

There are also two options that try to innovate in the analytics scene, Amplitude and Mixpanel. Among so many features, both provide incredible visualizations and charts, and advanced querying capabilities.

I want to note something that is not an analytics service per se, but something to govern them all. You will find that if you need to use multiple services, you will have to have your own layer that logs events in those different services. Or at least, to be a bit agnostic of the service, you would prefer to have that layer. Additionally, it will happen that the Product team will have their requirements for analytics and from that point until having those reports in production (with your LogEvent calls in the middle) some mistakes will occur.

So there is where a tool like Avo comes forward. Avo allows Product Managers, Developers and Data Scientists to work together on the same analytics plan. Said simply, while a Product Manager may define what information they require for different events, Avo has the capability to manage ‘branches’ and generate code. Imagine a PM creating a “CONFIRM_PURCHASE” event with some info required like “DATE”, “PRODUCTS”. Well, Avo will generate the method to call: Avo.confirmPurchase(date, products), amazing uh?

Avo might look like something advanced, but it has proven to make the analytics code development easier in large multidisciplinary teams.

There is more…

This second part focused more on the business side of the project. Far from being over, the next part will go back to the code side of things when making Professional Android Apps!

Cover photo: Photo by Alvaro Reyes on Unsplash

Wireframing by hand: Photo by Kelly Sikkema on Unsplash

Have you recently managed to earn an Android Developer Certification? Or maybe just finished your first personal project? Being in charge of an Android app that has gained quite a market share? Or the team has just grown due to upcoming new features to make?

The next decisions and steps to take will have to tackle scalability and make you and your team Android Pros.

This guide is a summary of some tools and aspects the project will have to cover besides Fragments and Views.

Architecture

When an app becomes increasingly complex, with more features and aspects, making changes starts being problematic. Code duplication, newly introduced bugs, difficulty to change parts become common occurrences that hinder progress.

One of the steps for preparing for it, is establishing a good architecture, that takes into account modularity prospects of how much of a scope the project will have.

Is it a card game? Will you have to add different games afterwards? Is it a delivery app? What about adding pharmacies to it? How will you attach prescriptions? Is it a chat app? What about adding payments to it?

We may not predict the future but with some idea of the scope we will be able to think about how to modularize the project.

Also, architecture can take care of possible bugs and stability (for example, if we go the Google route, using their components that take care of configuration changes, stability issues, concurrency, etc), and make testing easier.

You can take a look at Google’s recommendation for apps architecture.

Not taking Google’s as a last word, you can also check out concepts and approach about MVP (Model-View-Presenter) by Netflix.

Modules

While “module” sounds like an abstract concept for separation of concerns or sub-units of code, in Android projects it can be the concrete concept of Modules. Those parts in which an Android Project can be composed of.

We may have one only module for the entire app (not bad if we are just starting and trying out an idea) but it will become more evident the need to divide the code.

Separation of concerns, from a functional or non-functional point of view can both work: We can separate layers (UI, Data, Network, etc), features (Auth, BigFeature1, BigFeature2, Commons, etc) or a mix.

In case of having multiple teams for different parts of the app (imagine a supermarket app where electronics appliances screens are totally different from the groceries ones), different modules may provide a natural separation among teams as well. This is useful as well in remote and distributed teams.

Here a bit more conceptual in-depth presentation about modules.

Demo Apps

The bigger the app, the more it will take to build, it is kind of a fact.

What if we want to (manually) test a part of the app we are working on? What if building takes 15 minutes? This WILL happen, sadly. In this case, modularizing among features may help as you may add mini-apps, maybe called “demos” or feature “Activities”, which will make it possible to have fast cycles for your features development.

In an Square talk they tell about one approach to have fast builds and development with this kind of architecture (video above).

Dependencies

It will become prevalent that different modules, will end up connecting, or said better, depending upon themselves.

Just imagine your “Auth” module being asked for sessions from multiple parts of the app. Dependency Injection will come to the rescue for this and for easier Testing as well.

You won’t see any big Android project without a kind of Dependency Injection applied to it. Currently on Android, Hint is taking the position from Dagger as the recommended standard to follow (pushed by Google).

Testing

Putting the religion aspect aside, more automated Testing will help the project. At least, avoiding to have the same bug twice.

The battery of tests will go from testing code/behavior one class at a time up to end to end tests that follow user paths in the app (for example, from login until saving changes in the app).

There is a Testing Pyramid that graphically explains three testing categories.

Some things we’ll have to consider:

• The need of implementing Dependency Injection in the project is inevitable. (At least, it will help with mocking features that are not meant to be tested in certain Unit Tests. It will also have a performance impact on Testing as well. Let’s avoid accessing the database or network when running a logic test.)
• Small tests should be fast and generally only test Kotlin/Java code. Large tests, may need to run on real devices or emulation. That’s why some companies have phone farms or use services like AWS Device Farm or Firebase Test Lab.

The Fundamentals of Testing (for Android) can be seen here in the Android Developer site.

Another aspect of testing that appears is how much of our app we are testing. This can be reflected by Code Coverage. Nowadays Android Studio has a built-in feature that allows you to run code with code coverage. Use it at your own ‘risk’, do not try to reach 100% without a second thought. Some parts in the code will be much more critical than others, focus on them first.
Android Studio: how to run tests with code coverage.

Continuous Integration

How we can reduce the chances of delivering new bugs into production after making a new bunch of code (new features, fixes, etc)? What about having builds ready for QA? Or.. how will all those tests run when integrating code in our Master branch?

Here is when Continuous Integration takes their role in the project. Basically (but not restricted to) at least all new commits in our main branch (Master? but it could also be made for every feature branch) will trigger a new build. That build will itself be tested, both automatically and manually by our QA team (if we have any, please have one). It may also deliver those builds, making them accessible to anyone interested (QA, ourselves, Product management, etc).

Nowadays Jenkins CI is one of the most used, but some other tools can be used as well, Bitrise, Github Actions or even Gitlab CI.

In general it will be duty of one of the developers (or maybe a delivery manager?) to configure the platform and project with the steps to execute when integrating. Obviously we will want to run tests and make the build. Additionally many actions in this article series will end up running from CI as we want every “health” check for our project to be run automatically.

Check out this practical introduction to Android Continuous Integration.

There is more..

That’s all for this first part of the series. I promise, there is a lot more to cover when making Scalable Professional Android apps!

Nowadays it is becoming more and more common to find distributed software development teams – a.k.a. IT teams -. No matter the reasons, developers are scattered along a country, a continent or the whole world, constantly collaborating each other to deliver great products and experiences: this is a fact. But there is also a common set of concerns for those in charge of building distributed IT teams, for example

Does developers in other countries have the skills my project needs?

How can I coordinate and control a remote team?

Will the members of the team be able to effectively communicate each others?

How can I protected my business’ IP?

Here are some key aspects that you should consider to build successful remote teams across different countries without sacrificing product quality nor compromising business deadlines.

The right skills, ready to go

Looking for the right developer among the universe of all freelance developers is a really hard and time-consuming task. You will probably have to discard dozens of candidates before you find out a few that fit your needs for a position or a project. Hand-Picked candidates are already tested in specific skills and fluid English so you will interview only the top-notch developers.

Check the background of each candidate, see what they have done, how long they have worked for a company and what that company says about them. It’s not enough that they are qualified but they also need to be experienced.

Make sure they will be available full time or part time as your project require. If part-time is the case be sure they work the half of the day that best matches your business time, according to the developer’s timezone.

Finally check that the developer is able to start in the date you need. Hi talented developers do not last available so much, that’s why if you are interested you must be clear and ask a period to make a good decision.

Hand-Picked have the resources to start new projects right away. Handling the same project in-house might involve weeks or months to hire the right people, train them, and provide the support they need. For most implementations Hand-Picked will bring years of experience from the beginning, saving time and money.

Saving costs

Hiring IT freelancers may make you save a considerable part of the total cost of in-house IT staff which is a great news specially for small and mid-sized business. Let’s consider this saving:

• Reduction in costs related to searching for candidates, hiring and training them
• No need of company-paid benefits like social security, medicare, unemployment insurance, medical insurance, paid leave and some other taxes
• Reduction in indirect costs like cleaning supplies, office equipment, in addition to administrative costs
• As you only pay for worked days you don’t pay vacations
• Fixed costs become variable costs so you pay for them only when you need them

You can have top-notch freelance developers between 50 and 100 US dollars per hour. With that in mind and depending on the source you ask, the cost of hiring a developer is around 50% of the cost for an in-house developer. To get the total amount just multiply the unit saving amount by the amount of positions you need to cover…

Take advantage of timezone

In my experience this is the key to make a project succeed: communication. Work in a near timezone means have at least 4 hours overlapping between the freelancer and the headquarters. This allows a daily meeting in which each developer may report progress, issues and receive requirements. Technical calls are also convenient – or needed – more or less frequently and working both parts in a convenient time makes this sustainable over time.

Here is were nearshore outsourcing takes advantage. Being in the same continent is important because of two reasons: Daily, because of the benefits of time overlapping described above. The second reason is that from time to time you may need that both parts of the team work physically together and traveling across continents involves extra costs and drawback like jet lag.

IP & contracts matter

Legally protect your work may result as important as the invention itself. I’m sure you will consult a professional but just keep in mind a few tips before signing a contract with freelance contractors:

• Have a signed NDA before sharing any information you consider sensitive
• State in the contract that the contractor transfers you all ownership and rights over the work done, including know-how, design, inventions, etc.
• State in the contract that, after the termination of the relationship, the contractor MUST destroy everything you consider private or sensitive information for your business
• State in the contract that the contractor cannot share or divulge in any way any private information given to him to do his work
• State in the contract that the contractor cannot use any work product (i.e. source code) developed for your business in another project for another client or for himself

Conclusion

Hand-Picked developers have more than 10 years helping US startups and mid-sized companies to achieve their IT goals. We offer ready-to-go, high-quality and trained talent with a similar culture, speaking fluent english at a near timezone and letting your business reduce costs without taking extra risks: Hand-Picked developers will work with the same commitment than anyone else in your team. This is the commitment we have assumed.