There’s a ton of jargon around technology in startups, so here’s a list of common terms that you may hear when talking tech with founders and devs.
Front-End and Back-End
The Front End is the part of the system that the user interacts with. The Back End is the bit that manages data and communications. In a Web-based system, the Front End is everything that happens in the browser and the Back End is everything that happens on the server.
Front End developers are more skilled with UI and UX (see below), while Back End developers are more skilled with Dev Ops (see below).
UI and UX
Not the same thing, but closely related.
UI stands for User Interface, and is the part of the system that the user actually interacts with (see Front End).
UX stands for User eXperience, and is the user’s overall experience of the product. This includes the User Interface but also includes performance, workflow, platform, branding and a bunch of other stuff.
Put simply: UI is what the users interact with, UX is how the users feel about the product.
Dev Ops
Short for Developer Operations, Dev Ops is the growing merger between Developers (who write code) and Operations (who manage servers).
The increase in use of Cloud services has meant that the role of Operations has decreased within organisations, since the actual computers are virtual and inaccessible. Developers now tend to deploy their code direct to the servers themselves, usually using some form of CI (see below), and therefore assume responsibility for managing the servers themselves too.
CI and CD (Continuous Integration and Deployment)
In the old days, code would be written, reviewed, tested and deployed as a series of separate steps, usually by different people. CI is the process of automatically testing new changes to the code, and CD is the process of automatically deploying approved changes to the live servers.
CI systems are merged with VCS (see below) to trigger tests whenever a developer commits code. Any failing tests are automatically flagged back to the developer, and usually there is a code of practice that says the dev must immediately fix the code so the tests pass.
CD systems take that one step further and automatically deploy code that is committed and passes all tests. Modern tech startups use CD routinely and make lots of small changes to their code base rather than large infrequent “version releases” which was the standard for desktop applications twenty years ago.
VCS (Version Control System)
Version Control manages changes to a code base.
In simple terms, every time a developer changes some code, they “commit” their changes to the VCS. The VCS records the change and allows the developer to “revert” it (undo the change). Previous changes are kept and the entire code base can be rolled back to a previous version if required.
90% of the time, for startups anyway, the VCS used is Git. Most startups also store their code on an online repository manager, like Github or BitBucket. Often this is integrated with a CI and/or CD (see above) system so that committed changes are automatically tested and sometimes deployed.
Compiled vs Interpreted
Some coding languages are compiled (C, C++, C#, Go, Java) and some are interpreted (Ruby, Python, Javascript, PHP).
Compiled languages are compiled to a final form which is then executed by the computer.
Interpreted languages are executed line-by-line directly from the source code by another program.
Compiled languages usually (but not always) execute faster; they need less CPU time to perform the same tasks.
Interpreted languages are usually (but not always) more flexible; easier to change and manage.
There is no “right choice” for all circumstances. Usually choice of language is a matter of personal preference by the developer.
MVC
Model-View-Controller Architecture, made famous by Ruby on Rails.
It’s a method of organising a web application that makes it easier to understand, easier to test and less prone to bugs. There are MVC frameworks for every single programming language, to a varying degree of usefulness and acceptance.
SQL and NoSQL
Traditional database use a language called SQL (Structured Query Language) to manage structured data in databases. About ten years ago there was a movement to abandon SQL because of performance problems and instead use unstructured data in “documents” stored in a flat list of documents called a document store. This would allow data to be stored and retrieved much more quickly, as long as that data was self-contained – trying to link multiple documents together in a document store gets tricky. NoSQL solutions such as MongoDb and Redis have become very popular for storing website data because they simplify most tasks involved with it.
SQL vs NoSQL tends to be a developer choice made along personal preferences and prejudices. A lot of older developers refuse to use NoSQL solutions because they don’t trust them. Younger developers tend to prefer NoSQL solutions because they’re simpler to use and don’t involve so much work (or learning SQL).
Framework
Web development is very similar across a range of applications: the are incoming requests, the request is processed and triggers some business logic, which results in a response sent back to the browser. So a lot of web applications are doing the exact same thing, with just different business logic rules in the middle. So web developers have standardised on similar ways of doing this job, and these common sets of code are called “frameworks”. Common frameworks are Rails or Django, written in Ruby and Python respectively.
Using a framework speeds up development because a large part of the code required is already written and tested. However, it reduces flexibility because the framework makes assumptions about the application, and if those assumptions are not true then the framework doesn’t support the application. Generally speaking, the more assumptions the framework makes then the less code the developer has to write but the less flexibility the framework has.
There are also frameworks for app development, front-end javascript applications, Internet of Things applications, and almost every conceivable situation where two or more developers will be writing similar code.
Internet Of Things
The Internet connects computers, but increasingly computers capable of connecting to the internet are becoming so cheap and small that they can be put into everyday objects.
The Internet of Things (IoT) is the concept that some computers on the internet are actually not general-purpose computers but are everyday objects like air conditioning controllers, drones, fridges, all the way down to shoes and clothing. This enables them to be controlled by other computers (like phones) on the internet.
The dark side of IoT is that security has so far been ill-considered and badly implemented on a lot of IoT applications and that this stream of data about people’s stuff (and potentially control of that stuff) is available to hackers (and interested government bodies) for nefarious ends.
That’s it for this list, let us know if there’s a term you’ve heard that you’d like to know the meaning of and we’ll dig out an explanation and add it.
