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!