Only simple and complicated problems can be solved with best practices.  The thing that simple and complicated problems have in common is that can solved with existing knowledge.  So, we can fix a flat tire as easily as we can perform heart surgery.  The former is simple the latter complicated, because it requires expertise.  The books I talk about here only work because they are attacking a simple problem: changing the structure of existing code.

A complex problem can only be solved with hindsight: existing knowledge cannot help you.  The design of software is a complex problem, requiring hindsight, and so hindsight should be built into your method.  (I.e., plan to throw many solutions away, you will anyway.)  These books will not help you with your toughest problems.

Isomorphism is a posh word that Hofstader, in Godel, Escher, Bach, talks a lot about.  Isomorphism is to do with the preservation of information.  So, an image of the sun scratched on to a cave wall by our ancestors has an isomorphic relationship with the Japanese flag.  At the heart of refactoring is isomorphism: we have to preserve the information we have, the behaviour of the code, whilst improving its structure or appearance.

Refactoring, Fowler
In Refactoring, Fowler teaches us how take an arbitrary collection of symbols (what we call code) and change their organisation whilst preserving their meaning.  There is nothing more to software design.  Our code needs to be as succinct, and meaningful, as it can be whilst remaining fit for purpose.  Refactoring teaches us how to do this.

Working Effectively With Legacy Code, Feathers
Michael Feathers says, in this book, that ‘legacy code is simply code without tests’.  Moments later he elaborates, telling us that,

Code without tests is bad code.  It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is.  With tests, we can change the behavior of our code quickly and verifiably.  Without them, we really don’t know if our code is getting better or worse.

Here Feathers highlights the relationship between tests and design, the former enables the latter.  My definition of legacy incorporates Feathers’: code that is hard to change is legacy.  Code with decent tests is easier to change then code without them.  But, code that is decomposed is also easier to change, as is code that relies on macros, as is code that is written in an object-oriented language.  So, even though not fully agreeing with Feathers, I would recommend this book as its contents are second to none.

Legacy Code is about how to get some tests written so we can verify that the changes we might make preserve the meaning of the code.  Legacy Code might could well have been subtitled, Applied Refactoring.

Refactoring to Patterns, Kerievsky.
This book is the link between design patterns, which are well-known solutions to programming problems, and refactoring.  Jorrit and I always says that a solution, to either a code problem or an organisational one, is easier to evolve to when some intermediate steps are known.  This books provides these intermediate steps.

Code Complete, McConnell
This books is probably the most important book in the list.  It offers best-practice solutions to simple problems, such as how to defend your code against invalid inputs, how to design loops and how to integrate code.  This may seem rudimentary, but many developers either don’t know or have forgotten these basics.

To manage the project effectively we compiled a scenario for a successful migration, based on information we gathered throughout the organisation. As part of this process we studied both the current process of funding the mortgage contracts and the process they are to migrate to. This presented an opportunity to dive into the funding practices of banks and link these to an implementation, i.e. proper engineering.

The migration requires to move from an existing funding methodology to the industry standard of Funds Transfer Pricing ¹ (FTP). Implementing this shift in internal accounting of the required funding needed a conversion methodology. After a literature search we suggested a methodology and implemented it. For the implementation we build a Microsoft Excel/VBA tool to do the relevant computations. Migration of the mortgage contract data from the old system required building custom SQL scripts in combination with the QRM Transaction Data Mart tool. Once the migration is complete all the mortgage information will be stored and processed in one place reducing operation risk.

We are very pleased that the contract has been extended, giving us the opportunity to complete this interesting migration work.

The Actuarial Association (Actuarieel Genootschap, AG) is the professional association of actuaries and actuarial specialists in the Netherlands, of which very nearly all actuaries are members. The AG has developed into a platform for actuaries to communicate among themselves and with society at large.

We are very happy to be on the steering committee responsible for the Actuarial Association’s new master program: Executive Master of Actuarial Science (EMAS). The committee helps shape the content and context of the course. Managing risk is one of the central themes as is best described by quoting the course website:

The demand for skilled actuarial professionals is growing. Actuaries are the leading professionals in finding ways to manage risk, and managing risk requires knowledge of several disciplines. Understanding how businesses operate, how legislation may have an impact and how financial economics may affect securities are all vital skills for an actuary. Globalization, the integration of financial markets, changing IT environments and market innovation in risk management ensure that the actuary field of action is becoming more challenging and complex by the day.

In response to these changes, the Dutch Actuarial Institute (Actuarieel Instituut) and TiasNimbas Business School (TiasNimbas) have developed the Executive Master of Actuarial Science (EMAS).

Taken from the executive master of actuarial science website

After being on the committee in the start up year we are happy to continue our engagement into the second year of the course.

As part of the validation we checked the cash flow model, the interest rate curve construction methodology and the inflation model. Finally, the implementation of the models in Excel/VBA was checked, that is to say the code used to implement the models was validated.

To gain more insight in these, matters Cardano started an interesting research project. We were asked to support Cardano’s effort, starting of with validating and optimising the Excel/VBA code used to model the pension rights. We completed our involvement in the project by providing a first analysis of the raw data.

Based on the model Cardano has published a paper; “Getting Real about Nominal Guarantees” by Theo Kocken, Bart Oldenkamp and Joeri Potters.

A common theme among geniuses at one end of the spectrum and us normal people somewhere in the middle, is that creative breakthroughs have nothing to do with intelligence. Richard Feynman had an I.Q. of only – only! – 125. Yet, he invented the Feynman Diagram, won the noble prize, contributed to numerous committees and research areas. He had a career that was book-ended by the Manhattan Project on one end and the investigation into the Challenger Disaster at the other.

Breakthroughs are fractal, so what precedes a big breakthrough also precedes a small breakthrough. This year at the Testing and Finance Conference we’ll be talking about how we solve problems using that we call Preparationism.

We spoke to the company’s representatives, one tester and one developer. In their innocence, they thought their problems were unique to them, and this innocence – you could also call it arrogance – meant that solutions must be unique to them. This is what leads to the ‘it won’t work here’ mentality. Their company was dying. Off the shelf solutions – software quality assurance and half decent management – won’t work. A pickle.

On the way home, my train was re-directed to Central Station. I wanted to reflect on the day and so walked to the central library and up to the sixth floor, where I often sit. Out of the corner of my eye, I saw Collin’s How The Mighty Fall. His model goes something like this:

• Stage 1 – Hubris Born of Success.
• Stage 2 – Undisciplined Pursuit of More.
• Stage 3 – Denial of Risk and Peril.
• Stage 4 – Grasping for Salvation (AKA Panic).
• Stage 5 – Capitulation to Irrelevance or Death.

I merged the model for technical and organisational debt – the dashed line – to Collins’ life cycle.

At stage one, a software team is developing features. They are cutting corners but their debt is low, they have not made too many mistakes and they can pay for them with enthusiasm. At point two, what Collins calls an undisciplined pursuit of more, organisational and technical debt are growing, yet its exponential nature is not yet apparent. A common feature here is long hours and low automation – the company are sending men to do machine’s jobs – and older projects are biting you back. At stage three, just before technical and organisation debt explode, projects are painful to complete, blame looks like a management practice, fights occur between the responsible and irresponsible, run time errors are all over the place.

Et voila! You’re team is dead. Debt, complexity of products and the time taken to fix bugs in a growing system, are all exponential in nature. But, poor linear humans don’t know this until it’s too late. That’s why companies die quickly. It’s how a programmer or team become useless overnight. It’s why young companies grind to a halt.

The feeling that a company’s problems are unique and therefore their solutions must be unique, is a common error. It’s arrogance born of innocence. Teams and companies who learn this before the exponential point of return survive. Those that don’t, die. There is a period, and it can last some time, at point four, where companies panic. This is a precursor to death.

What a hardware and financial engineer have in common is that they are specialists and they have to coordinate their activities with software engineers. There are a number of team and organisational structures that are useful for coordinating work and allowing room for integration issues to be attacked and for conflicts to be resolved. In February, I was invited to Germany to work with a mobile phone manufacturer. It taught them about the T-Bar organisational structures, but more importantly, how to evolve them over time, and how the structure is related to leadership, strategic human resource and management.

Starting with Grayling’s Towards the Light The Story of the Struggles for Liberty and Rights that Made the Modern West, we travelled through the ages, stopping off in the deep South of the United States, the streets of London with her Suffragettes and then hopped over to the French revolution, which in turn saw Europe’s Jewry emancipated. They say that the American Civil War was the first major challenge to liberty, the Nazis of Germany was the second. However, the Conservative Rebels wanted to maintain the power and political structures. The Nazis wanted to go backwards. This is known in Organisational Theory as a retromovement.

What started out as a bit of fun, a sweeping romp through history, ended up as a reasonably serious study cumulating in this model:

People tweeted it, and blogged about it, and emailed their friends. We were happy, and will be happy to return to Belgium Test Days. It was a laugh.

Bottom up

At the basis of the triangle software meets finance. The combination of the two allows the translation of clever mathematical finance into a solid computer program that can be used in production. Our model is about operationalising, thus digitalising, financial knowledge. Only with expertise from both domains can one deliver the high quality information systems upon which modern financial institutions are utterly dependent. Creating solid information sources which communicate with each other and the end users directly results in a flexible platform that can quickly deliver new functionality.
A prerequisite for this model is a guarantee that all information sources are working as expected and can safely be changed if required. Best practices in engineering can achieve this. We suggest using test driven design, mocks, setting up version control and continuous integration. These technical practices should be complemented with a continuous improvement track for development teams. The need to stay ahead of the curve drives the continuous improvement process. Among the tools that can be used are retrospectives, standup meetings, well thought out training program, planning and tracking tools.
A cornerstone in any software project must be domain knowledge, financial knowledge in this case. We can offer detailed financial modelling knowledge; solid architectural experience, understanding the relevant market data and how to manage it and intimate knowledge of the mathematical details. In addition we offer contract knowledge of most financial instruments, understand and have experience in dealing with pension and insurance contracts.
The emphasis is on bringing expertise together in a cross functional team, rather than uniting all knowledge in a single, or handful, of experts. Allowing for deeper knowledge with individuals, while allowing for broader knowledge for the team as a whole.

Top down

With the best practices management is presented with new information. Some might not have been available before, some in a different detail level, which raises the question of how to use this information. As engineers its our responsibility to explain which are the levers that can be pulled, the buttons that can be pushed and what their effect will be. Once management is comfortable with these decisions, they can redirect more focus to strategical decisions. Only monitoring projects and course correcting if the necessity arises.

Management will be left with self organising teams. Leaving them to focus on strategic decisions and monitoring rather than being involved with day to day activities. The company will see increase in continuity, since the knowledge of the systems will be spread over various team members.