My next side project will be an Azure app that aids people in decision making via interactive algorithms that analyze the data underlying the interactive controls, the data stored about the specific user, and the general data stored in the system that is relevant to the particular decision.
Examples of the types of decisions the app will aid people in making are:
- financial investment portfolio asset class allocations
- choosing between different employment offers
- choosing between different residences (including buy vs. rent)
- choosing between different vehicles
- choosing between different colleges
I plan to start developing the app with a focus on aiding in investment decisions. In 2008 I created software for backtesting parametrized technical indicators commonly used in trading. That software did not result in an strategy algorithm that produced annualized returns that were sufficiently high and consistent, but I did learn a things from the experience that will help with the architecture, design, and implementation of this app.
- The backtesting software and the investment strategy being tested need to be high performance and parallelized, as the results never come out fast enough. This means the backtesting software needs to at least be multi-threaded and optimized native code. It would be even better if it were distributed across multiple machines as well.
- While very tight coupling between the backtesting code and the strategy code provides significant opportunities for optimization, it does not allow trying out different investment strategies without also changing the backtesting software. This means the backtesting software developed initially needs a well defined interface. Creating more specialized backtesting software should be deferred to the future even if that means higher operating costs now.
- Software is needed for analyzing and comparing the results of the backtesting runs on investment strategies, but runtime performance isn’t a gating factor for this software. This mean this code can be written in Python or IronPython.
- Software is needed to manage the results data and tie it to the specific version of the code the produced. The results data is too large to commit to source code revision control systems. This means a reliable and durable mechanism is needed to map strategy code and backtesting code to specific results and vice versa.
This app meets the goals I set for my next side project as it will be an Azure app and I’ll be able to make use of my recently created multi-threaded C++ unit testing framework in the development of the backtesting software. I may even find it necessary to enhance the framework to support multi-processed applications if single-process multi-threaded performance proves underwhelming.
Now I just need to come up with a name for this project and get started!