(WIP) How to explain your App to Engineering?

Describing an App to engineers can be challenging. Where to begin? In fact, why not leave it to the designers? After all, isn't it the business analyst, designer, engineering manager, or someone else's job to describe how the App should work for engineering?

The truth is many product owners and product managers who are embarking on their first products have never engineered an App. They tend to retreat to more comfortable business requirements and shy away from the technical parts. In normal circumstances, they would account and accept recommendations from Engineers who are supposed to know better. Unfortunately, under time and budget pressure, they are inclined to make product decisions that neglect Engineering wisdom, leading to technical debt.

At best, such owners and managers make promises to pay the debt in the future. At worst, the debt is forgotten, left to compound with ignorance, and creates friction in the future. Often, the tipping point is product failure. No one knows why it failed and has to bear the consequences of debt at the worst timing.

If you are a product owner or product manager embarking on a new App or have always wondered if sending over a list of features is the best thing to do, read on.

The Benefits of understanding some Engineering

The goal of understanding Engineering is not to replace your engineers or to vet their work. Instead, one of the purposes is to show engineers that you care about their work and have invested time to learn about what they do. If you do not invest time to learn and understand, you are in a much less favourable position to make good product decisions under stress.

The other objective is to acquire engineering knowledge that acts as a counterweight in times of stress. The know-how provides a balance against your immediate instincts. It is about giving that additional space to think before deciding, leading to better decisions.

The caveat here is to be mindful of the wisdom that knowing a little is a dangerous thing. Just because you read articles about particular up-and-coming technologies does not automatically mean that they are the best choice for a project. Listen to the experts, do your due diligence and decide.

The Essential Concepts

Here are fundamental concepts that a new product owner or product manager should be aware of:

• Tech Stack

• The difference between frontend and backend

• Environments

• Automated testing

• Infrastructure

• Stories

What is a "Tech Stack"?

An App comprises multiple technologies called a Tech Stack, categorised into either frontend or backend technologies.

There are varying definitions all over the Internet, and one of the easiest ways is to categorise the technologies into either frontend or backend technologies.

The frontend is the interface that the user interacts with. Conventionally, this can be a web page or a mobile app, or it can even be a voice interface like your smart speaker. On the other hand, the backend is like your computer's CPU - you usually don't see it, but it is an essential component doing the heavy lifting behind the scenes.

Frontend and Backend technologies

Common frontend technologies include HTML, CSS, Javascript, Swift, Kotlin. These technologies breathe life into designs and give form to the Apps that people use. Browsers and operating systems convert the software code written using those technologies into the user's tangible interface.

Engineers use backend technologies like PHP, .NET, Java, Javascript and Python to create APIs, connect with databases, implement business rules, user authentication, blockchain validation, machine learning and more.

For example, consider the LinkedIn App. First, the frontend creates a text box that enables you to type a post. Then, when you hit send, the frontend delivers your post to a backend that saves your post to a database. Simultaneously, the backend publishes an alert to your followers. Within a few seconds, on the frontend of the LinkedIn App that your followers use, a notification about your post appears, prompting them to tap on it to find out more.

Combined, the frontend and the backend delivers the full functionality of the App to both internal and external stakeholders.

Unbeknownst to you, a band of experts called User Experience (UX) designers have orchestrated the seamless tweeting experience that you didn't think twice.

See the pink highlight on your lengthy tweet telling you that you have exceeded the maximum number of characters you can use for a tweet?

Yep. That's what the UX designers told the frontend engineers to do so that you know that you have broken the rules.

UX designers collaborate closely with the frontend and backend engineers to deliver a carefully crafted experience that meets and hopefully exceed your expectations. Interested to learn more about UX and what it means for your App? Check out "Nothing is New about User Experience (UX)".

Can I freely mix and match Frontend and Backend technologies?

It depends. Certain backend technologies may have preferred frontend technologies that work with them out-of-the-box. So while other technologies may work, they can require more effort. The choice of technologies also does not always come down to purely technical considerations, and other pragmatic concerns may apply.

For example, organisations may stipulate specific technologies that align with in-house expertise, performance, security and support requirements. In such cases, you will want to communicate such needs to external engineering teams. However, where there are no organisational constraints, it is best to let the engineers recommend technologies.

Can an App be just made up of Frontend technologies without a Backend?

Yes! Product teams sometimes build frontend-only prototypes for testing or demonstration purposes. Some Apps can also deliver their full functionality without a backend, such as the Calculator App commonly available on most computers and mobile devices. One distinct advantage of Frontend-only Apps is their offline nature, ensuring that they continue to work without an internet connection.

Environments

Much like the secretive test tracks used by car manufacturers to test out prototype models away from prying public eyes, the equivalent is called the development environment in the world of Apps. The development environment is used exclusively by Engineers for development purposes. Two other environments, staging and production, serve internal and public stakeholders, respectively.

Product teams most often demo their Apps in the staging environment to internal stakeholders before deploying them to the production environment.

Each environment has its unique URL and access control to ensure that only authorised individuals can access the resources within that environment.

All three types of environments separate data, credentials and operate within their sandbox, providing safety to their respective users.

Automated testing

Product teams do testing to reassure stakeholders that the system they created works as expected. Then, when engineers update the system, they, too, want to be reassured that everything continues to work as expected after the change. Automated testing enables that reassurance.

Automated testing is writing code to test code. Consequently, it comes at a cost in the form of an effort multiplier on every engineering task. Therefore, when you are budgeting and planning, adding a 30% buffer to include automated testing as part of your workflow is recommended.

The inverse of automated testing is manual testing, and it is generally not sustainable given the repetition and permutations that build up over time. Thus, it is probably not the best use of an engineer's time, and neither is it work that motivates them.

Let's consider two scenarios. In scenario A, the engineers test every line of code, and in scenario B, the engineers do not write test code but do manual testing. In A, the product team feels confident in making any new change to the system but concedes that they can only complete two out of five stories within the time frame. In B, the product team is confident to deliver all five Stories within the time frame but worry about breaking existing code, the sustainability of manual testing and making changes in the future.

As a product owner, you will need to decide whether to test, how to test and the extent of testing.

Michael Feathers, the author of the aptly titled Working Effectively with Legacy Code, describes legacy code as code without test coverage.

It is not hard to see how new code can quickly become legacy code if we work with that definition. Time has no role to play in "ageing" any code into legacy code. And legacy code is characterised as hard-to-maintain code that hinders improvements.

Product owners and managers must juggle business and product stability goals. Unfortunately, there is no single best way to navigate the conundrum of prioritising business or product stability. A stable product has no purpose if it does not deliver business objectives, and stakeholders cannot depend on an unstable product to meet their long-term goals. Keep in mind that prolonged indecision may also be worse than picking the second-best option early.

After understanding the tradeoffs, this is an important topic you should discuss with your engineering team. Share your concerns and tap into the engineering team's past experiences to advise you on the best approach. Teams often try to reach a target test code coverage over time without being idealistic, so they start somewhere closer to scenario B and move towards A as the project progresses.

Infrastructure

Like a city infrastructure, which provides physical resources such as buildings and electricity to offer services to people, an App's infrastructure refers to the resources that host your App's systems that deliver your App's services. In reality, the resources are computers, also called Servers, located in a physical building called a data centre and running your App's codes.

Typical resource providers include:

• Cloud providers like Amazon Web Services (AWS), Microsoft Azure, Google Cloud

• Organisation data centres with their servers

• Other providers leasing out their resources.

Infrastructures can vary significantly in terms of design and costs depending on the needs of the App. Here are some key infrastructure considerations that influence infrastructure design.

Performance

Engineers want to know how many users and how many transactions per second you expect on a high level. Although, transactions here is a loose term. It can refer to the average number of messages sent for a chat App. Whereas for an eCommerce App, it can refer to the average number of checkouts per second. The engineer responsible for architecting the infrastructure will use these estimates to design a suitable solution. There is no need to provide an exact number as the architect looks out for the order of magnitude than differences within the same order.

While engineers can estimate performance through simulations, they can never really simulate the real world, so it is always a good idea to over-provide for resources and scale back as you start to collect data around the type and volume of traffic.

Redundancy

Redundancy is the provision of additional resources to avoid downtime. There are many redundancy options along with various cost implications. For example, you can have multiple resources within a physical data centre so that if one goes down, another resource takes over the traffic. Extrapolating the same concept, you can have resources across multiple data centres across different physical locations to ensure that you can route traffic to another centre if one centre goes down. Costs generally follow a similar multiple to the degree of redundancy, so if you have 100% redundancy, it follows that you pay twice the price of the main set of resources as compared to having no redundancy.

One added value of redundant resources is that load balancers can typically distribute traffic amongst the resources to improve performance during regular times.

Location

You will generally want your infrastructure to be as close as possible to your App users to maximise speed. Cloud providers like AWS allow you to select resources anywhere in the world across many different countries. And yes, you can have multiple resources providing service across various countries.

China

China is an exceptional region in that services hosted on resources within the area may not be accessible outside of China and vice-versa. Therefore, do not automatically assume that your App will work in China. However, if you would like your App to be accessible to people located within China, let the Engineering team know about it so that they may assess your requirements and decide on the best course forward.

Organisation limitations

If you communicate to an external engineering team, it may be worthwhile to determine if your organisation has any preferences or policies relating to infrastructure. For example, banks or governments may not allow unsecured public infrastructure and mandate backend systems hosted within internal resources. Internal resources may consequently limit the choice of technologies that engineering teams can use.

Using Stories to communicate requirements

If you communicate to an external engineering team, it may be worthwhile to determine if your organisation has any preferences or policies relating to infrastructure. For example, banks or governments may not allow unsecured public infrastructure and mandate backend systems hosted within internal resources. Internal resources may consequently limit the choice of technologies that engineering teams can use.

The following are three different ways of describing a requirement for an App that enables virtual presentations:

Example of a typical feature description:

View list of attendees and questions asked.

Example of a User Story:

As a meeting moderator, I want to see a list of attendees and their questions to unmute the questioners with the most appropriate questions.

Example of a Job Story:

When I want to select attendees to pose their questions in a virtual presentation, I want to see a list of attendees who have asked questions and the questions they asked to identify the most appropriate questions and unmute the questioner.

It is not hard to see how the story format provides a more helpful context for engineers reviewing and creating frontend and backend solutions. The general rule of thumb is the more details that you can provide, the better.

Aren't Stories just tasks or features?

In short, yes. The industry, unfortunately, loves to create jargon. Some are useful, while some are pure marketing fluff. Remember Web 2.0? Stories, fortunately, belong to the helpful camp, as they imply a deliberately user-centred format for describing tasks or requirements. Thus, elements like motivation, the user and their goals are included in the description to support a Human-centered design and development process.

So, nothing stopping anyone from calling it a task and further extending the idea. Just make sure that it is human-centred regardless.

Leave the solutions at the door.

It is an instinct to ideate solutions to problems. Yet, we have found that teams develop better solutions when they focus on questions and learning. So, if you are approaching an engineering team for the first time, aim to provide as many details as possible, ask questions, but leave the App sketches at the door. Set up a separate session on a different day to discuss solutions.

“Alright, say no more, let me show you my engineering chops! Give me a challenge!”

Great! One of the best ways to understand engineering is to do it. If you are looking for an engineering exercise to start, try this: Create a Calendar that runs in your browser.

To sweeten the challenge (what's a challenge without a reward?), every month, we will give away two iPads, one to the best Calendar made by a product owner or product manager. And another one to any engineer. Email the link of your git repository to the.calendar.challenge@redairship.com and send us a link to your Linkedin profile.

Please note that only Singapore residents can claim prizes.