Top 12 Software Development Definitions Explained


Starting a soft­ware de­vel­op­ment pro­ject can be daunt­ing enough with­out mis­un­der­stand­ing all the tech­ni­cal jar­gon that goes along with it - so we cre­ated this ar­ti­cle to help you out and get you up to speed.

Throughout this ar­ti­cle, we’re go­ing to de­fine and ex­plore the twelve most com­mon terms that you need to un­der­stand be­fore you jump into your next soft­ware pro­ject so that you can be as pre­pared as pos­si­ble.


To be­gin let’s dis­cuss what a plat­form is. A plat­form is how peo­ple ac­cess your ap­pli­ca­tion.

For ex­am­ple, if they ac­cess it through an in­ter­net browser like Chrome or Safari then you have a web ap­pli­ca­tion. If it is down­loaded through an app store di­rectly onto your phone or tablet then you’ve got a mo­bile ap­pli­ca­tion.

It is pos­si­ble to have a sin­gle code­base that can be ac­cessed across both web and mo­bile. This is called a cross-plat­form ap­pli­ca­tion. Though, cross-plat­form tech­nolo­gies have lost their ap­peal in re­cent years, with de­vel­op­ers in­stead favour­ing cre­at­ing one code­base for each plat­form.

The pri­mary rea­son for cre­at­ing two ver­sions, one for web and one for mo­bile, is that you can bet­ter lever­age na­tive func­tion­al­ity. For ex­am­ple, on mo­bile de­vices you can utilise your ge­olo­ca­tion or mi­cro­phone on a ded­i­cated mo­bile tech­nol­ogy stack. In turn, this can cre­ate a bet­ter user ex­pe­ri­ence.

Technical Debt

In soft­ware de­vel­op­ment, tech­ni­cal debt is a bit of a catchall term that refers to the im­plied cost of ad­di­tional work to ad­dress bugs or other code fixes that oc­cur through de­vel­op­ment. It’s im­por­tant to note here that every prod­uct has tech­ni­cal debt and it does­n’t mean any­thing is ‘bad’ or ‘broken’.

The best way to mit­i­gate tech­ni­cal debt is to ad­dress it in qual­ity con­trol it­er­a­tions, which is a process that is in­cluded in an ag­ile pro­ject man­age­ment process - we’ll touch on what an ag­ile process is a bit later.

Scope Creep

Scope creep refers to all the ad­di­tional growth and changes that get added to a pro­jec­t’s scope af­ter you be­gin the de­vel­op­ment process.

For in­stance, you en­ter de­vel­op­ment with a spe­cific prod­uct back­log that in­cludes five re­quire­ments. That’s the scope you have agreed to fo­cus on. If, by the time you’ve made it to mid-way through the pro­ject, you’ve now got 10 re­quire­ments, you’ve likely changed the scope of the pro­ject in some way. This is what we call ‘scope creep’.

Scope creep is­n’t nec­es­sar­ily a bad thing, and the key to man­ag­ing it is to ac­knowl­edge it and ei­ther vary the time­line or de-pri­ori­tise other fea­tures to in­clude your ad­di­tional scope.


API stands for ‘application pro­gram­ming in­ter­face’

An API in­te­gra­tion is es­sen­tially how dif­fer­ent sys­tems com­mu­ni­cate with each other. If sys­tem A needs to send data to sys­tem B then they will do so through an API in­te­gra­tion.

You’re prob­a­bly us­ing mul­ti­ple API’s with­out even know­ing it. Examples in­clude Outlook mail, HubSpot & Google Ads.

There are sev­eral ben­e­fits to us­ing an API. Firstly, it re­duces the amount of data en­try across your soft­ware land­scape. Secondly, you can trig­ger au­toma­tions in a dif­fer­ent sys­tem based on ac­tions taken on the ap­pli­ca­tion. And lastly, you are able to lever­age pre-ex­ist­ing func­tion­al­ity built-in an­other prod­uct.

Product Owner

Firstly, it’s im­por­tant to dis­tin­guish be­tween the prod­uct owner and the busi­ness owner. In some cases, these two roles may be per­formed by the same per­son, but they are two dis­tinct roles.

The prod­uct owner is solely fo­cused on the prod­uct, mak­ing this a near full-time role. If you’re con­sid­er­ing start­ing a soft­ware pro­ject and al­ready per­form the busi­ness owner role, con­sider whether you have the time avail­able to do both.

It is crit­i­cal that the prod­uct owner is a sin­gle per­son so that there is a sin­gle voice that dis­tils stake­hold­ers feed­back and in­structs the de­vel­op­ment team. While this part of the role is im­por­tant, it’s equally im­por­tant to un­der­stand the needs of the end-users. It’s crit­i­cal to en­sure the prod­uct owner is acutely across the chal­lenges they are fac­ing and how your prod­uct can help them.

Project Management Methodologies

There are two method­olo­gies to be aware of; ag­ile and wa­ter­fall.

Before ag­ile be­came the de-facto ap­proach, there was wa­ter­fall. Essentially the wa­ter­fall method­ol­ogy is a lin­ear ap­proach which in­cludes roadmap­ping all your fea­tures and com­plet­ing them in se­quen­tial or­der, with a fi­nal re­lease at the end of the pro­ject.

The wa­ter­fall ap­proach does­n’t pri­ori­tise end-users and has a high risk of dis­sat­is­fac­tion. Imagine wait­ing un­til the very end to see your prod­uct only to re­alise it’s not what you ex­pected and it does­n’t meet the user’s needs.

In con­trast, ag­ile is an it­er­a­tive ap­proach to soft­ware de­liv­ery that builds in­cre­men­tally from the start of the pro­ject. It em­pha­sises rapid de­liv­ery in com­plete func­tional com­po­nents. These are sep­a­rated into it­er­a­tions and pri­ori­tised based on their im­por­tance. The fo­cus is on the end-user.

Kanban vs Scrum

While ag­ile is the method­ol­ogy of choice, there are sev­eral dif­fer­ent frame­works within ag­ile. Let’s take a look at the dif­fer­ence be­tween the two most pop­u­lar frame­works, Kanban and Scrum.

In Scrum, tra­di­tional plan­ning hap­pens at the be­gin­ning of an it­er­a­tion or sprint. At the end of the it­er­a­tion, the soft­ware is re-de­ployed. Following that, the team plans the next it­er­a­tion.

In con­trast, Kanban is a con­tin­u­ous flow of is­sues with­out an ac­tual plan­ning point. Once an item has fin­ished a stage, such as ‘Design,’ it is on-de­mand pulled into the next stage, which may be ‘Development’.

The main trade-off is struc­ture. For new pro­jects, where the op­er­at­ing rhythm has not yet been bed­ded down, the struc­ture of Scrum will al­most al­ways be a bet­ter fit.

Front End & Back End

The term ‘front end’ refers to what your user can see and in­ter­act with while us­ing your web­site or ap­pli­ca­tion, while the ‘back end’ is all of the in­fra­struc­ture that sup­ports it that they can’t see, such as the server and data­base.

Front end de­vel­op­ers work to op­ti­mise the user ex­pe­ri­ence by cre­at­ing a seam­less and en­joy­able ap­pli­ca­tion vi­su­ally, while back-end de­vel­op­ers fo­cus on stream­lin­ing the in­te­gra­tion, logic and func­tion­al­ity of the ap­pli­ca­tion.

Proof of Concept (POC)

POC is an ab­bre­vi­a­tion that you may not be fa­mil­iar with - it stands for ‘Proof of Concept’. There are four cat­e­gories that every pro­ject fits within: A proof of con­cept is the first cat­e­gory.

A proof of con­cept is an ex­per­i­ment or pi­lot pro­ject to demon­strate the fea­si­bil­ity of a de­sign con­cept or a busi­ness pro­posal. You may be asked to first pre­sent a proof of con­cept to se­cure fund­ing or in­vestors. Having a POC demon­strates that your idea or con­cept is vi­able be­cause it’s able to be val­i­dated by users.

Building a large prod­uct with­out first val­i­dat­ing it is risky. By start­ing small with a proof of con­cept you can make learn­ings early and lower your risk.

Minimum Viable Product (MVP)

The sec­ond cat­e­gory of pro­ject is an MVP.

While you’re for­given for think­ing it prob­a­bly stands for ‘most valu­able play­er’, in the soft­ware de­vel­op­ment world it’s in­stead re­fer­ring to the ‘Minimum Viable Product’.

A min­i­mum vi­able prod­uct is the first ver­sion of a prod­uct with just enough fea­tures for users to pro­vide con­struc­tive feed­back for fu­ture de­vel­op­ment - be­cause of this, it can be quite flex­i­ble.

There are a few in­stances where an MVP is what you need: you may be look­ing to move quickly and are ne­go­tiable on the scope of the pro­ject, your so­lu­tion might be tech­ni­cally fea­si­ble and you’re ready to com­mer­cialise it, or you may only need one of ei­ther a web plat­form or a mo­bile app. In any of these cases, an MVP is for you.

Remember, an MVP is all about stay­ing lean. What is the bare min­i­mum you need to make learn­ings?

Product Development

It’s the largest type of pro­ject and gen­er­ally re­quires four weeks of scop­ing to in­ves­ti­gate the prob­lem, de­sign a so­lu­tion and ex­plore tech­ni­cal ques­tions.

It cov­ers the com­plete process of bring­ing a new prod­uct to mar­ket, re­new­ing an ex­ist­ing prod­uct or in­tro­duc­ing a prod­uct in a new mar­ket.

It’s im­por­tant to still con­sider ag­ile prin­ci­ples dur­ing larger prod­uct de­vel­op­ment builds. Building for too long with­out test­ing your mar­ket ex­poses you to the risk of build­ing fea­tures your users don’t need.

Custom Consultation

Finally, when there is no im­me­di­ate path to de­vel­op­ment then the suit­able pro­ject type is cus­tom con­sul­ta­tion.

A con­sul­ta­tion is nec­es­sary when there is a chal­lenge in the soft­ware in­dus­try that is so com­plex it can­not be solved by build­ing a so­lu­tion. We call these com­plex chal­lenges ‘wicked prob­lems’.

No two prob­lems are the same which means every con­sul­ta­tion is unique. However, there are some sim­i­lar­i­ties. Every prob­lem needs to be un­der­stood be­fore it can be solved. At the end of the ‘understanding’ phase, a de­ci­sion must be made - what arte­facts should be pro­duced to cre­ate the best path­way for­ward?

This does­n’t nec­es­sar­ily mean build­ing a new ap­pli­ca­tion. Based on the team’s re­search and find­ings, the rec­om­mended ac­tion items will be pre­sented as part of the de­liv­er­ables.

Problem Statements

Finally, let’s talk prob­lem state­ments - we eluded to these ear­lier but let’s dive deeper and de­fine the three types of prob­lem state­ments:

Firstly, there are well-de­fined prob­lems. This means en­sur­ing that there is a clear de­f­i­n­i­tion of the prob­lem and the goal state. For ex­am­ple, be­ing locked out of your house. In this ex­am­ple, the prob­lem and the goal are well de­fined.

Secondly, there are ill-de­fined prob­lems. That is where the goal and the means to reach a so­lu­tion are to a large ex­tent un­known. For ex­am­ple, ‘how do I get more users?’ We know that it’s pos­si­ble to get more users, we just don’t have a hy­poth­e­sis for how yet.

Lastly, what you re­ally want to avoid is a wicked prob­lem. A wicked prob­lem is some­thing that can’t be solved. These prob­lems have such a level of ab­strac­tion or com­plex­ity that they can never be to­tally solved. ‘How can we erad­i­cate poverty glob­ally?’ is an ex­am­ple of a wicked prob­lem.

Now that you’ve made it through all that, you’re ready and pre­pared to take the next step in de­vel­op­ing your soft­ware pro­ject. Don’t for­get you can al­ways re­fer back to this ar­ti­cle if you need a re­fresher.

If you’re ready to take the next step, book in for your prod­uct strat­egy ses­sion with us to­day.

Discover Software


Alex Hudson

Digital cre­ative and hater of gluten

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion