Introspection. Improvement
Are you planning to acquire a company or carve out a product? Make sure you understand their technology. And be sure it works to your business.
We have built multiple software products and have optimized our methods and enhanced our processes. We know what matters when it comes to extensibility and maintainability of software. And we have an excellent understanding of what makes teams efficient and effective.
When we do a technical due diligence of a company or team, we don't solely look at whether they are using suitable technology to create the solutions they are producing, we evaluate software architecture and design, look at component licenses, assess scalability and automation. We also look at the production and support processes (where applicable) and assess technical debt.
When it comes to information security, things get serious. Getting it wrong may mean losing your business. And unfortunately, it's quite easy to get it wrong.
We are happy to review your security concept and assess your operations. And of course we can show you how to address shortcomings we detect – or that you may already know of.
If you write software using modern frameworks, you are likely saving a lot of time because you can rely on centralized code to take care of many things. But have you noticed that you are still producing lots and lots of boilerplate code? That the larger your software gets, the more you repeat yourself?
As soon as you create a system that is more than a pet project, you will be dealing with a large object model. And you will be writing a lot of code around that. If you make a mistake, you will likely have to correct it in multiple places. Have you considered modelling your business domain and generating your boilerplate from these models?
Model driven software engineering had a bad reputation at some time because people tried to find a silver bullet and went a bit crazy. Done right, modelling and code generation save loads of time, assure consistency and greatly increase software quality. Let us show you how!
It's old news that the earlier you find a bug the less expensive it is to fix. Now even before you start writing the first line of code, you will have (or should have) thought about what is the right overall architecture for your system. If you get that wrong, very likely you're going to rebuild large portions of your product again – at a huge cost.
We have designed and architected many modules and applications and have done even more reviews for others over time. We can help you get system and software architecture right from the start. And while that doesn't mean you won't have to ever correct any mistakes, it will be much less expensive ones.
The typical software product starts with a few software engineers (or developers) writing code on their computers, running builds locally and launching test systems on their machines. And while there may be nothing wrong with that at the very beginning, it almost immediately leads to inconsistencies which in turn tend to become problems.
A lack of peer reviews means more bugs. Not standardizing code style means time wasted in code reviews. Not using static code analysis means finding bugs and vulnerabilities (too) late. Building and deploying manually means potential for mistakes when deploying productively, and increases the expected time to analyze a bug.
Setting up a good technical environment early on drastically reduces total project costs. And while we're at it, have you heard of agile production processes? Sure, it's a buzzword. But if you understand the concepts and put them into practice (instead of following a specific agile "framework" to the letter), things will be better.
Let us help you define or refine your processes. Start small, and once you see it's working, we will be glad to help you scale!
Not too long ago, writing good software was enough. These days, allowing for integration through APIs is absolutely required by customers. And because APIs are used by machines and not humans, their users can't simply adapt to changes, they just break. And have to be fixed by your customers, costing them money and time.
To keep one's customers happy, one has to make sure APIs remain stable over time, while being extensible where needed. One has to make sure they are clearly documented – and at the same time are as good and conformant to standards that they really wouldn't need much explanation.
Customers will love you for opening up your systems via APIs. Make sure they keep loving you. Let us review your API strategy and your APIs – best before you publish them. We will help you make sure your customers stay happy!
Octeris AG
Steinackerstrasse 17
8645 Jona
Switzerland
