Top 12 Software Development Deﬁnitions 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 deﬁne 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.
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.
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 ﬁxes 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 refers to all the additional growth and changes that get added to a project’s scope after you begin the development process.
For instance, you enter development with a speciﬁc product backlog that includes ﬁve requirements. That’s the scope you have agreed to focus on. If, by the time you’ve made it to mid-way through the project, you’ve now got 10 requirements, you’ve likely changed the scope of the project in some way. This is what we call ‘scope creep’.
Scope creep isn’t necessarily a bad thing, and the key to managing it is to acknowledge it and either vary the timeline or de-prioritise other features to include your additional scope.
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 beneﬁts 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.
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 ﬁnal 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 ﬂow of issues without an actual planning point. Once an item has ﬁnished 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 ﬁt.
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 ﬁts within: A proof of concept is the ﬁrst 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 ﬁrst 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 ﬁrst 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 ﬁrst version of a product with just enough features for users to provide constructive feedback for future development - because of this, it can be quite ﬂexible.
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?
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.
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 ﬁndings, the recommended action items will be presented as part of the deliverables.
Finally, let’s talk problem statements - we eluded to these earlier but let’s dive deeper and deﬁne the three types of problem statements:
Firstly, there are well-deﬁned problems. This means ensuring that there is a clear definition of the problem and the goal state. For example, being locked out of your house. In this example, the problem and the goal are well deﬁned.
Secondly, there are ill-deﬁned problems. That is where the goal and the means to reach a solution are to a large extent unknown. For example, ‘how do I get more users?’ We know that it’s possible to get more users, we just don’t have a hypothesis for how yet.
Lastly, what you really want to avoid is a wicked problem. A wicked problem is something that can’t be solved. These problems have such a level of abstraction or complexity that they can never be totally solved. ‘How can we eradicate poverty globally?’ is an example of a wicked problem.
Now that you’ve made it through all that, you’re ready and prepared to take the next step in developing your software project. Don’t forget you can always refer back to this article if you need a refresher.
If you’re ready to take the next step, book in for your product strategy session with us today.