Do any of these sound familiar?

  • Your velocity feels lower than it should be, but individual story estimates seem adequate.
  • Features built in one place introduce bugs somewhere else.
  • Lots of special cases must be considered for each task.
  • QA takes forever because there are so many paths to test.
  • You spend a lot of time handling fires.
  • Your team is big enough, but you can’t keep up with feature requests and bug fixes.
  • Sprint planning takes a long time, with long debates on different approaches.
Wolfram Schroers Portrait

There's no doubt about it: Large projects (> 100,000 lines of code) are challenging. Maybe you know this situation all too well – after having worked on your code for several years you may have adopted different paradigms. Requirements have changed and introduced conflicts. Parts of your code are called “legacy” and decisions had been made for “historical” reasons.

While working on my PhD thesis I needed to analyze and extend a program written by a research group over the course of several years. The program was working well and I was able to use it as a foundation for my own project. A few years later I was working on a different project and again had to deal with a code-base that had evolved for many more years. But this time it was remarkably different: build scripts failed randomly from one version to the other, it was unclear how to extend it, and subtle bugs led to failures that were very costly and hard to track down.

Seminar with Wolfram

After having worked on several projects like this I have started to see patterns. I have learned how to write effective documentation that gets read and applied. I have seen how identifying the tough spots and gradually refactoring your existing code base can help you address many of these issues. I have also become a strong proponent of continuous integration and continuous deployment and have experienced how these practices lead to more confidence in your code and facilitate the refactoring process.

Over the years I have learned about many different paradigms and worked with multiple technologies. These days I prefer to work with Python for everything related to scripting and task automation (with a little bash on macOS and Linux systems), Clojurescript with re-frame for web applications (Clojure for the backend), and Objective-C and Swift for iOS.

If you'd like to know how to improve your processes and architecture, I'd love to help you. Please drop me a line by email to dr.schroers@nua-schroers.de. You may as well use GPG, see Contact.

Professional Experience

Numerik & Analyse Schroers.
Managing Director. December 2009 – present.
Tamanguu GmbH & Co KG
CTO and Co-founder (Geschaeftsführer). March 2017 – September 2019.
National Taiwan University 國立台灣大學 and Academia Sinica 中央研究院.
Visiting faculty. October 2007 – August 2009.
DESY Zeuthen — NIC.
Postdoctoral research fellow. October 2004 – September 2007.
Center for Theoretical Physics, MIT, Cambridge, USA.
Feodor-Lynen research fellow of the Alexander von Humboldt foundation. August 2002 – September 2004.
Institut für Theoretische Physik, Regensburg University, Germany.
Postdoctoral Research Fellow. March 2002 – July 2002.
Fachbereich Physik, Wuppertal University, Germany.
Graduate Teaching and Research Assistant. October 2001 – February 2002.


Fachbereich Physik, Wuppertal University, Germany.
PhD studies, Dr.rer.nat. in Theoretical Physics. Magna cum laude. December 2001.
Fakultät für Physik und Astronomie, Bochum University, Germany.
Graduate studies, Diploma in Theoretical Physics. Summa cum laude. November 1996.

Philosophy of Teaching Statement

While working in Academia I have based my teaching efforts on a couple of principles and wrote these down in my Philosophy of Teaching statement. I still believe in these principles, so I keep this document.