Top 12 Software Development Definitions Explained
Starting a software development project can be daunting enough without misunderstanding all the technical jargon that goes along with it - so we created this article to help you out and get you up to speed.
Throughout this article, we’re going to define and explore the twelve most common terms that you need to understand before you jump into your next software project so that you can be as prepared as possible.
Prefer to watch or listen instead?
Platform
To begin let's discuss what a platform is. A platform is how people access your application.
For example, if they access it through an internet browser like Chrome or Safari then you have a web application. If it is downloaded through an app store directly onto your phone or tablet then you've got a mobile application.
It is possible to have a single codebase that can be accessed across both web and mobile. This is called a cross-platform application. Though, cross-platform technologies have lost their appeal in recent years, with developers instead favouring creating one codebase for each platform.
The primary reason for creating two versions, one for web and one for mobile, is that you can better leverage native functionality. For example, on mobile devices you can utilise your geolocation or microphone on a dedicated mobile technology stack. In turn, this can create a better user experience.
Technical Debt
In software development, technical debt is a bit of a catchall term that refers to the implied cost of additional work to address bugs or other code fixes that occur through development. It’s important to note here that every product has technical debt and it doesn’t mean anything is 'bad' or 'broken'.
The best way to mitigate technical debt is to address it in quality control iterations, which is a process that is included in an agile project management process - we'll touch on what an agile process is a bit later.
Scope Creep
Scope creep refers to the additional growth and changes that get added to a project’s scope after development begins.
For instance, you start with a specific product backlog that includes five requirements. That’s your initial scope. If, by mid-project, you now have ten requirements, you’ve likely altered the scope, which we call ‘scope creep’.
Scope creep isn’t inherently negative. The key to managing it is to acknowledge the changes and either adjust the timeline or de-prioritise other features to include the new scope.
API’s
API stands for ‘application programming interface’
An API integration is essentially how different systems communicate with each other. If system A needs to send data to system B then they will do so through an API integration.
You’re probably using multiple API’s without even knowing it. Examples include Outlook mail, HubSpot & Google Ads.
There are several benefits to using an API. Firstly, it reduces the amount of data entry across your software landscape. Secondly, you can trigger automations in a different system based on actions taken on the application. And lastly, you are able to leverage pre-existing functionality built-in another product.
Product Owner
Firstly, it's important to distinguish between the product owner and the business owner. In some cases, these two roles may be performed by the same person, but they are two distinct roles.
The product owner is solely focused on the product, making this a near full-time role. If you’re considering starting a software project and already perform the business owner role, consider whether you have the time available to do both.
It is critical that the product owner is a single person so that there is a single voice that distils stakeholders feedback and instructs the development team. While this part of the role is important, it’s equally important to understand the needs of the end-users. It’s critical to ensure the product owner is acutely across the challenges they are facing and how your product can help them.
Project Management Methodologies
There are two methodologies to be aware of; agile and waterfall.
Before agile became the de-facto approach, there was waterfall. Essentially the waterfall methodology is a linear approach which includes roadmapping all your features and completing them in sequential order, with a final release at the end of the project.
The waterfall approach doesn’t prioritise end-users and has a high risk of dissatisfaction. Imagine waiting until the very end to see your product only to realise it’s not what you expected and it doesn’t meet the user's needs.
In contrast, agile is an iterative approach to software delivery that builds incrementally from the start of the project. It emphasises rapid delivery in complete functional components. These are separated into iterations and prioritised based on their importance. The focus is on the end-user.
Kanban vs Scrum
While agile is the methodology of choice, there are several different frameworks within agile. Let’s take a look at the difference between the two most popular frameworks, Kanban and Scrum.
In Scrum, traditional planning happens at the beginning of an iteration or sprint. At the end of the iteration, the software is re-deployed. Following that, the team plans the next iteration.
In contrast, Kanban is a continuous flow of issues without an actual planning point. Once an item has finished a stage, such as ‘Design,’ it is on-demand pulled into the next stage, which may be ‘Development’.
The main trade-off is structure. For new projects, where the operating rhythm has not yet been bedded down, the structure of Scrum will almost always be a better fit.
Front End & Back End
The term ‘front end’ refers to what your user can see and interact with while using your website or application, while the ‘back end’ is all of the infrastructure that supports it that they can’t see, such as the server and database.
Front end developers work to optimise the user experience by creating a seamless and enjoyable application visually, while back-end developers focus on streamlining the integration, logic and functionality of the application.
Proof of Concept (POC)
POC is an abbreviation that you may not be familiar with - it stands for ‘Proof of Concept’. There are four categories that every project fits within: A proof of concept is the first category.
A proof of concept is an experiment or pilot project to demonstrate the feasibility of a design concept or a business proposal. You may be asked to first present a proof of concept to secure funding or investors. Having a POC demonstrates that your idea or concept is viable because it's able to be validated by users.
Building a large product without first validating it is risky. By starting small with a proof of concept you can make learnings early and lower your risk.
Minimum Viable Product (MVP)
The second category of project is an MVP.
While you’re forgiven for thinking it probably stands for ‘most valuable player’, in the software development world it’s instead referring to the ‘Minimum Viable Product’.
A minimum viable product is the first version of a product with just enough features for users to provide constructive feedback for future development - because of this, it can be quite flexible.
There are a few instances where an MVP is what you need: you may be looking to move quickly and are negotiable on the scope of the project, your solution might be technically feasible and you’re ready to commercialise it, or you may only need one of either a web platform or a mobile app. In any of these cases, an MVP is for you.
Remember, an MVP is all about staying lean. What is the bare minimum you need to make learnings?
Product Development
It's the largest type of project and generally requires four weeks of scoping to investigate the problem, design a solution and explore technical questions.
It covers the complete process of bringing a new product to market, renewing an existing product or introducing a product in a new market.
It’s important to still consider agile principles during larger product development builds. Building for too long without testing your market exposes you to the risk of building features your users don’t need.
Custom Consultation
Finally, when there is no immediate path to development then the suitable project type is custom consultation.
A consultation is necessary when there is a challenge in the software industry that is so complex it cannot be solved by building a solution. We call these complex challenges ‘wicked problems’.
No two problems are the same which means every consultation is unique. However, there are some similarities. Every problem needs to be understood before it can be solved. At the end of the ‘understanding’ phase, a decision must be made - what artefacts should be produced to create the best pathway forward?
This doesn’t necessarily mean building a new application. Based on the team's research and findings, the recommended action items will be presented as part of the deliverables.
Problem Statements
Lastly, let’s define the three types of problem statements:
1.Well-defined problems: Clearly defined problems and goals (e.g., being locked out of your house).
2.Ill-defined problems: The goal and solution are largely unknown (e.g., ‘How do I get more users?’).
3.Wicked problems: Problems that can’t be solved due to their complexity (e.g., ‘How can we eradicate poverty globally?’).
Now that you’re familiar with these terms, you’re ready to take the next step in developing your software project. Feel free to refer back to this article whenever you need a refresher.
