my name is Torsten Mangner. I am a software developer and quality expert.
I am very interested in getting to know you and your project. Maybe there is a chance that a can support you. If you are also interested in a collaboration, or want to know more about me and my recent work, feel free to contact me
Who am I?
I like to be called a generalist and was able to gain experience in software development over the last 20 years. Since I am used to switch roles between developer, tester and coach, I tend to fastly become a real enrichment for every cross-functional team.
As an experienced software developer with a strong focus on quality, I aim for sharing my knowledge and experiences with my team colleagues. I do that by setting a good example and showing during my daily work how to:
- write clean, readable and comprehensible (and therefor maintainable) code
- write the right tests, so that they guide and help you, instead of hinder you
- learn and internalize the critical thinking of a tester
- use Continuous Delivery to improve quality and reduce risk
- use a minimum of documentation to help everyone on the team
Since a couple of years I fell as a part of the functional programming community, but also had the chance to gain alot of experience with “classical” paradigms. As a polyglot developer, I look into new languages and concepts every now and than, and try to recognize and leverage their unique strengths.
Whenever I am in project for a longer time, I tend to found communities of practice (e.g. software craft, testing) with colleagues of mine, to encourage knowledge exchange between different teams or even companies. Additionally I regularly visit meet ups and conferences (both as speaker and as attendee) to see further than the end of my own nose.
To be able to successfully bring our ideas of modern software development into the world, I founded a company named inoxio Quality Services GmbH together with two friends in 2007. Since then countless projects all over Germany utilised our know-how in the fields of development, testing and operations.
What have I done?
For a big german eCommerce platform, my team and I built a recommendation solution with a ployglot microservice architecture. And as good DevOps we ran the operation ourselves.
50+ Services, Clojure, Scala, Python, Kafka, Tensorflow, Redis, REST
The whole microservice landscape was migrated from a company-owned data center into Amazon’s Cloud with zero downtime.
For our own company I planned and developed a tailored invoice and accounting system, which is used successfully for over 10 years and is enhanced and improved every now and then.
Since in complex systems insufficient transparency is often jointly responsible for poor quality, I established holistic monitoring and alerting solutions for different projects.
Clojure, ClojureScript, Prometheus, Grafana, Graphite, Kibana
Besides time series data teams often have to boldly visualize team specific data. I developed tools, so that the teams can monitor those information with ease. These tools showed amongst others:
- for each repo, the number of commits, that are not deployed to LIVE yet
- the state of all autoscaling instances in the cloud
- the run time and status of long running jobs
- the quality of various recommendation types, so that stakeholders can evaluate those better
Software, that isn’t maintained, rots away quickly. I have always a special interest to improve the code quality of the software I am working on as a daily routine. At the end of the day I want to have less technical debt, better test coverage or less accidental complexity in the system.
What do I believe?
In case that your beliefs do not match mine, we should definitely have a word. I would love to hear which principles are making your projects successful.
There is no silver bullet
There is no best practices. No single technology can be the answer for an exisiting problem. Each challenge has to be seen in it’s context of the current circumstances.
1.01 ^ 365 = 37.78 0.99 ^ 365 = 0.02
Only if a team wants to improve itself every single day, it can achieve great things. Retrospectives with their blameless causal investigation are cornerstones for the continuous improvement of a team. Small experiments with measurable results help to adapt the team’s structure and mode of operation to its current needs.
You don’t need testers to ensure quality. Every team member can learn and internalize the critical thinking of a tester and so influence the quality of the product right from the start. You may need quality advocates to accompany and guide the team in this process.
Believing is not knowing. Only with correctly measured data, one can make informed decisions. Everything else is guessing. The transparency of a product can be improved with a comprehensive monitoring solution.
In the same way can tests, with their ability to verify and document essential aspects, deliver a clearer picture of internal processes of a system.
Too many tests on the wrong level of the test pyramid, make your tests slow unstable, unnecessarily complicated and hard to maintain. In the same time you loose the biggest advantage of a good test suite: your ability to make changes with confidence.
A nicely balanced test pyramid on the other hand, gives you fast feedback, shows which change led to unwanted side effects and verifies both the correctness of single components and their proper interaction.