Photo by Marvin Meyer on Unsplash

When you have software developed professionally, you may be confronted with technical terms and abbreviations. In this blog post, I would like to give you an overview of some technical terms that are commonly used by software developers during the requirements analysis and implementation phase.


This term is probably most often used when it comes to developing new software, or extending existing programs. But what exactly does it mean when we’re outside of the construction business? In fact, software architecture is not that far removed from "real" architecture. When an architect designs a house, the goal is always the same: to construct a building. This building has one or more doors, windows and rooms, which are bounded by walls and a roof. Sounds very simple in principle, but of course there is much more than that: How exactly are the rooms laid out, where are the doors placed, what is the floor plan, how well is everything isolated, and so on. This list can be continued almost indefinitely up to the closing mechanism of a window.

Software Architecture is actually quite similar to this. The product is always the same: a computer program. But there are infinite variants of how to develop a specific program, how it behaves, how it stores data, how it handles user input. However, many variants are not suitable in reality, because they are inefficient or error-prone. Furthermore, software evolves, so the architecture must also be flexible.

Therefore it is very important to choose a solid architecture from the beginning. The following methods listed in this article support the developer in writing robust code.


This abbreviation stands for General Responsibility Assignment Software Patterns and describes a set of basic principles, which are used in the software development and serve as orientation. Compared to the GoF (Gang OF Four) Design Patterns, which formulates specific solutions, GRASP only describes principles.

These patterns have the goal of making software as readable and maintainable as possible by clearly structuring the source code, assigning tasks, reducing dependencies to a minimum and avoiding side effects.


These abbreviations denote two implementation strategies. TDD stands for Test-Driven Development and BDD for Behavior-Driven Development.

  • TDD describes the strategy that one writes automated tests first, before actually building the component. This has the advantage that the developer first thinks about how this component should behave and catchs possible edge cases early, before the program is even published. This is, among other things, the reason why we pursue this strategy when developing programs. Learn more about this method in our separate blog post about TDD.

  • BDD refers to the test strategy of writing automated tests from the user's point of view, preferably by a business analyst who is an expert in the domain and therefore knows the problem best.

There is also the Code-Driven Development strategy, in which a component is implemented first and only then tested. This may seem intuitive at first glance, but it can be error-prone and can also lead to duplicating the code.


In computer science, an interface is a connection from one component to any other component. One of the best known interface types is probably the REST-API (Representational State Transfer Application Programming Interface) from a client (e.g. the browser) to a server. With this interface, the server provides an area to which the browser or, for example, a mobile app can connect to receive and modify data and initiate processes. However, there are many more interfaces that can be used anywhere to operate a self-contained system from the outside. This can also be done on the same computer, for example, when the server communicates with the database, which runs on the same computer.


This abbreviation stands for "Model View Controller" and describes a model for abstracting a program into three components. The data model (Model), the presentation (View) and the controller (Controller). This pattern is used relatively frequently in practice, including in Ruby on Rails.