At the beginning of every software development is always the idea: What should the software be able to do? And what do you need it for anyway? Users of software never need code. They need what the code does. So we start right there: with the benefit for the user. We formulate it and question it until we understand it. And then we question it again. After all, we want to be sure what the user really needs (and not just what he thinks he needs).
Users often do not know what they really need. Therefore we have to give them a feeling for the possible future software solution. With the short-term development of prototypes – also called “minimum viable products” (MVP) – we create a simplified version of the possible result. Users can see immediately whether we have understood what it is all about. And we can take a first look at the technology: Where are the challenges of integration into existing systems? And what do we need to consider from a technical perspective as the project progresses?
We know the planned benefit for the user. And we have the results of the prototypes. Now we can compare the user experience with the technical conditions of the software: Which of these are a particular challenge for the project? For which ones have we not yet found an implementation path? And which ones are perhaps not as important for the user experience as we thought?
Here we collect the exact requirements of the users of a new software. We document them and make them measurable. In this way we create a target system with which we can check when our work has been successful.
To ensure that the project is completed on time, on budget and on schedule, we are now reviewing and simplifying the requirements once again. Then we simplify them further. And one step further. In the end we see crystal clear what the user wants. And then we plan the project so that the highest priorities are processed first. Then we get started!
The foundation of every software development is the architecture. It is the framework of everything we build on it. Thus it not only opens up possibilities – it can also restrict them. Our task here is to find a balance between user experience and framework. For example, between existing systems, the planned scaling and the planned budget for the software.
We analyse the existing data models or create new ones. We also compare them with existing or new applications. Where are important functions performed? Where is what information needed or generated? We determine exactly that and incorporate it into the architecture.
We take a close look at the existing infrastructure – or define the infrastructure that still needs to be created. How can we integrate the applications so that the project goals are achieved? And how can we ensure expandability and scaling? Good questions to which we find an answer.
Information security is an unavoidable topic today. We evaluate existing or missing security systems and processes. And we look for solutions for possible gaps. We take all findings into account for the further course of the project.
We write code. Code that achieves exactly the benefits we have defined in advance. Which is powerful and scalable. Which is easy to maintain and extend. And which is absolutely stable. Sounds like the basics of software development? They are basics. And thus for us they are a matter of course.
We work according to Scrum, Kanban or comparable other management methods, but in any case always agile. Every 14 days we start a new sprint with a new goal. We work through the users’ priorities step by step and let them decide whether we are on the right track based on interim results. After a careful retrospective we then plan the priorities for the next sprint. This way nobody runs around headless, hectic or actionistic. Instead, we work in a focused manner towards the common goal.
Recently we have started to use Kotlin, Java and document-based databases. We don’t do that because for us it is a panacea for all conceivable applications. But because we consider it A) to be particularly powerful in most cases. And because we B) are simply really good at it. In development we then work with common tools such as IntelliJ, git, Gradle, Docker and Kubernetes.
In our contracts we make sure that they fully reflect our agile way of working. This means (perhaps annoying) obligations for the client. But we believe that the best results are achieved when everyone plays their part. After all, we are a team that can only dream together – and succeed.
During the development we pay attention to a high test coverage. This is the only way we can detect errors early on and minimize unnecessary effort. For us, quality assurance is an integral part of development. Only in this way can we avoid frustration and make the user experience a pleasure. Our approach is a “continuous deployment” approach: We must always be able to quickly complete changes that have been started and bring the code back live. As a result, errors are noticed more quickly – and we can react to them more quickly.
We are experts in many test procedures, such as automated surface tests, unit tests or system tests. It is important to us that the success of the code is already measured during the coding process, i.e. it is precisely defined what result the code should achieve (User Acceptance Test). And that we can also carry out additions to complex systems quickly and reliably thanks to our high test coverage.
We are also fast through the use of crowdtesting solutions with which we can successfully run individual test runs in the shortest possible time. With thousands of software testers that we can fall back on at short notice, we also notice hidden errors which we can then immediately correct.
In our Scrum teams we permanently integrate Quality Assurance (QA) experts who ensure quality throughout the entire development process up to the successful release. Sometimes everything takes a moment longer at short notice, but always pays off in the end. Follow-up costs for fixing insufficient quality are avoided right from the start.