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

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.