One of my personal favourite quotes and probably one of the most famous quotes in marketing comes from Harvard Business School Professor Theodore Levitt:
“People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!”
This simply means that people don’t want to know about the tools, they want a solution to their problem.
However, as true as it is when dealing with software products it is almost inevitable that you are going to face new terminology used by the dev team and a general understanding of the terms and concepts used can come in real handy.
There are certain limitations, advantages and disadvantages that need to be considered and the more we understand these the more realistic expectations we will have and that can almost guarantee a better outcome and less headache down the road.
Here we have collected some of the most used terms in our everyday lingo to help you grasp everything more easily:
- Backend: the backbone users can’t see
- Frontend: the user facing part of the system
- Full Stack: the developer can handle almost all parts of the code
- DataBase: where the system stores the data
- Native: built for a specific OS or hardware
- Flutter: toolkit for using one codebase on multiple platforms
- WebView: showing a webpage in an app
- PWA: progressive web application
- API: interface between software (parts)
- UI: user interface, how it looks
- UX: user experience, how it works
- Agile: iterative collaboration
- Migration: moving data from one system to the next
- Technical debt: shortcuts in the code
- Refactoring: making the code better quality
- Alpha: first version for internal tests
- Beta: feature ready version for external tests
- RC: final version before release
- CR: request for added or altered functionality
Backend
Generally refers to any part of a website, mobile app or software program that users do not see. The backend is the “data access layer” and is generally the “server side” that is in charge for tasks like:
- processing incoming requests
- running scripts
- accessing data
- storing or updating records in a database
- encrypting and decrypting data
- handling file uploads and downloads
- processing user input
If you imagine the software as a fast-food chain, when you enter the door (open an app, visit a website) you face the menu on the wall (UI) and talk to the cashier to place your order (frontend). However, the kitchen actually preparing your order is in the background, you most probably can’t see how your order is processed and how your meal is cooked but it is in charge of putting together your food. In this analogy the kitchen is the backend part of the system.
Frontend
As opposed to the backend, the frontend is the “presentation layer” or “client side” so the part of the software that your users see and interact with. The backend and frontend work closely in tandem to create the full user experience. Data generated in the backend is passed to the frontend and presented to the users.
Usually the frontend is in charge of tasks like:
- application or page layout
- graphics
- audio and video elements
- text content
- user interface elements (buttons, links, toolbars, navigation bars, etc.)
- input areas (dialog boxes), form fields, text areas, etc.
- user flow (how one interface leads to the next)
- user preferences, themes, and customizations
There are examples of frontend only solutions and applications with really lightweight backends, for example a static website can function with almost no backend but as soon as you want to sync between multiple devices, have user logins..etc. you need to start thinking about the backend requirements as well.
Full Stack
A full stack developer simply means that she or he can handle both frontend and backend related tasks (or client and server side) and sometimes even has DataBase, DevOps and Mobile app development skills as well. So, you basically get a person who can handle almost all development tasks needed to build your software product which is great because that person has a full understanding of all the requirements and a really clear vision of all the components and how they interact.
This is a great advantage but generally full stack developers are more expensive and after a certain complexity your project might need developers specialised in one specific area.
DataBase
A database is essentially an organized collection of structured information. There are many different types but some of the most common databases can be imagined as multiple Excel sheet like row and column tables linked together. So for example your electricity service provider most probably uses a database to manage billing, client-related issues, handle fault data, etc. assigned to the different accounts.
This is where your software stores, reads and writes information.
Native
Native software is designed and developed to run on a specific operating system or hardware. It has a clear advantage as it is optimized for the given setup and can get the most out of it.
On the other hand, if you need to have an iOS app, an Android app and a Windows and Mac version as well, you might be able to use some common components but you will most likely end up with 4 native teams, working on 4 different codebases trying to achieve essentially the same goal. This not only means at least quadruple of the initial development costs but also mean multiplied costs for maintenance and future development.
There are also cross-platform software that can be run on multiple operating systems or computer architectures but more on that later.
To bring an example, Game Boy games on the little cartridges contain code that runs natively on the Game Boy console and were specifically developed for that hardware. If you would like to play Game Boy games on any other hardware, for example on your Windows laptop, you need to use an emulator which basically simulates an actual Game Boy. This usually comes at the cost of speed and resource usage.
Flutter
There are solutions to overcome the problem that multiple platforms bring. We for example use Flutter a lot lately. It is Google’s UI toolkit for building natively compiled applications for mobile, web, desktop, and embedded devices from a single codebase.
This means the team needs to develop and maintain only a single codebase which is a huge advantage but at the end they are still able to produce (essentially translate) native code that can be used on multiple platforms.
However, such technologies come a long way and work really well but they are still relatively new so there specific tasks they can’t fully handle yet and it is almost impossible to work the same everywhere, so for example we recently run into an issue that was only present on iOS and worked perfectly on Android so you can expect some platform-specific behaviour that will be more tricky to fix.
Web View
As described previously, writing native code every time you add a new platform can be a rather costly expedition. However, there are ways to reuse previously built components. For example, if you already have a website that has the required functionality, there is a built-in component on Android devices that lets you display the webpage directly in your mobile application, hence the name Web View.
This can save an awful lot of time as you can reuse ready made parts, open up existing links and speed up the development but on the other hand it is usually recommended to be used for non-essential or non-key parts of the app. This is because the user experience might differ from the app, it has limitations as you can’t change the existing behaviour and might navigate outside of the app (open the browser app) which is generally considered as a bad user experience.
Adding web views to the native app results in a so-called “hybrid app”.
PWA – progressive web app
I think the second part of the acronym speaks for itself, you basically get a web application, an app built on web technologies we all know and love, like HTML, CSS, and JavaScript..etc. The interesting part is the first letter as “progressive” brings in a bunch of new technologies, the user experience is enhanced gradually based on new browser capabilities.
The idea is to build an app that almost feels native like, does not need store approval , has advanced capabilities, yet it is lightweight, cheaper, quicker and easier to build and maintain. There are many great examples like Twitter and Starbucks that can put this all into perspective.
APIs
API stands for Application Programming Interface and has many different uses but essentially it provides an interface that allows multiple applications to interact with and obtain data from one and another. APIs operate on an agreement of inputs and outputs so provide a set “menu” of options and the connected software doesn’t need to know how the other operates internally.
APIs are a great way of building integration between multiple systems, like your CRM system storing customer information providing client data to an SMS sending marketing campaign system or to stay at the topic of PWAs, the web app might call an API to access the camera of your phone.
UI – user interface
The user interface nowadays is one of the most crucial parts of any software product as it can really make or break it and most modern software has a GUI so a graphical user interface. A typical example of a hardware device with a UI is a TV with its remote.
It sounds really simple and such an everyday thing as it surrounds us everywhere but in practice designing an easy to use and effective user interface is quite a challenge. I think we can all pick some examples from our memories where we tried to use a system and we just could not find what we were looking for. That is how frustrating a bad UI can get.
UX – user experience
UX is an equally important part of a good system and the UX design defines how the user gets from one screen to the next, how the flow goes and basically everything the end-user experiences (quite literally) and is responsible for the usability, accessibility and ease of use of the software. The UI and the UX go hand-in-hand and they are closely interlinked so they often get mixed but in reality they are two separate and distinct topics.
Agile
It sort of became a buzzword that is used everywhere but that is not necessarily a problem. Agile software development is good, it means you can adapt to changes quicker, you can react to new requirements, you can change directions more easily and it puts a great emphasis on a collaborative approach.
As opposed to more traditional methods where you had a long list of features already written and you were walking through them until you reached the end, agile allows change throughout the process, enables adaptive planning, continuous evolutionary improvement and delivers work in smaller increments in a much more flexible way.
Migration
I think we all experienced migration in one form or another, like migrating your data from your old phone to the new one you just bought. Quite similarly, if you for example already had an existing software and you just built a new one and you would like to bring all the user data from the old system to the new one, you will need a data migration.
This quite often is not as easy as it might seem as the new system might use newer technologies, a different data structure..etc. so you might need to reorganize or transform the existing data as part of the migration.
Technical debt
Technical debt or code debt is an interesting concept as it refers to the projected cost of additional rework caused by choosing an easy (and often limited) solution now over a better but longer to implement approach. Technical debt like financial debt is not necessarily a bad thing, it allows you to get to your goals quicker, like release a software version earlier but similarly to financial debt it has to be tracked and eventually paid back otherwise it will cause trouble later down the road.
Refactoring
Unfortunately, code refactoring is a necessary evil as when it is done right it should not change the functionality (external behaviour) of the software so it has no real user value at first sight. However, it has to be done regularly as it greatly improves maintainability and extensibility and results in a much more effective code.
So, in short it will be easier to fix bugs and add new functionality after a successful code refactoring and it also ensures a higher quality product.
Alpha version
The alpha version of a software is ready for internal testing and the development of the expected functionality is almost complete. To put it simply, at this stage the code is almost ready, most of the major issues are ironed out but you still expect to see a few hiccups here and there and there might be known problems that you still need to fix. This is mostly considered as a developer build (version).
Beta version
The next phase after the alpha version and testing is the Beta version. This version now has all the features you want to release but there are still possible smaller issues. This release is often handed out to a selected user group who participate in the testing and can report bugs or want early access to new added functionality.
RC – release candidate
After the Beta phase usually comes the RC. This is basically the version that you still want to test yet another time to ensure the best quality possible but it is generally considered to be done, stable and ready to publish. This is your final version before the actual release of the software.
CR – change request
Change requests usually come into the picture when you are working on a custom development project and there was an agreed set of functionality you fixed with the dev team but you would like to alter that or add new functionality.
Is there a software tech term you could not find here? Is there a definition your would like us to improve? You found what you were looking for but got confused? – Please don’t hesitate, just drop us a line and start a discussion with the team.
