Thread by @oliverjumpertz

Assumptions in software engineering are bad.

They are what you think but very often not what was really requested or expected.

By not asking questions, you put everything at risk.

This is a story of how assumptions nearly killed a multi-million dollar project.

A thread. ↓

0. Foreword

I can't tell you everything because this is a story that really happened.

I would break several laws and NDAs by giving you names and too many details.

Still, I will do my best to give you this as an example of why you should turn assumptions into knowledge.

1. The story

Some time ago, a medium-sized financial software company got a contract to develop a multi-million dollar wealth management system for a European private bank.

Wealth management systems are software systems that automatically manage your money.

Customers buy a bank's service to manage their money for them, and the bank, in return, does everything to manage this money in exchange for a fee.

Wealth management is not exclusive to wealthy clients, thanks to automated systems.

This automation includes rebalancing portfolios when certain thresholds are broken.

The bank's investment managers create so-called model portfolios, a relative distribution of money to certain assets (shares, bonds, etc.).

Every customer gets a model portfolio assigned.

When a customer transfers money to their account, the automated system buys assets relative to the allocation in a customer's model portfolio.

When some assets gain too much value, they are sold, and other assets are bought in return. This is called rebalancing.

Those systems also allow a thorough analysis of all customer's portfolios.

They create reports when certain thresholds are broken or on certain points in time, as required by law.

Investment managers can always monitor all portfolios and jump in if something goes wrong.

As the bank itself was not fully agile yet, a hybrid approach was chosen.

The first part of the project consisted of getting all requirements clear and creating rough prototypes of the final solution.

This first phase was called "exploration."

A team of 6 business analysts and technical personnel was assigned to do workshops with the private bank's business and technical staff.

There existed a rough list of required features, but they had to be fully understood first.

After this phase, the process would move on to a more agile approach with sprints and short cycles of development and feedback.

This was to ensure that the bank's staff could actually keep up with the pace and nothing would get lost in the process.

The full project had already been sold for a fixed amount of money.

There was a fixed deadline.

The goal was to determine which features would fit in without breaking the budget while still resulting in a usable product.

Every requested feature was thoroughly discussed, understood, documented, and then transformed into a rough concept.

Wireframes were created, public interfaces were designed, and feature after feature, the exploration phase progressed.

The exploration team had already prioritized features they wanted to talk about in the beginning.

They moved things to the top that seemed important to be discussed and others to the bottom that didn't seem so important.

This is where one "small" feature was actually moved all the way to the bottom.

The headline read: "Bank's own fund."

There was no other description for it, and buying and selling funds and analyzing them is a core competency of all wealth management systems.

Only, nearly at the end, the exploration team finally scheduled a meeting for the least important feature of all, the bank's personal fund.

Three months had already passed since the beginning of the project, and the exploration phase was about to end.

Many features had already been prioritized or even cut from the scope to keep the project within budget.

There was nearly no more space for further adjustments.

Features could still be cut but hardly extended.

Half an hour passed, and the bank's staff still told the story about the fund while the exploration team's members wrote down their notes.

No member of the exploration team saw an issue with the bank's own fund. But these were actually multiple funds the bank set up themselves.

No exploration team member dared to ask many questions because funds were a core competency of a wealth management system.

And the whole team agreed that it was all about putting these funds into the bank's customer's portfolios.

The team at least agreed until one of the bank's investment managers started to talk about order breakdown.

This is a process in which a huge order is sent to the markets, with a breakdown structure, showing individual orders making up the larger one.

Still, no one from the exploration team asked another question or became curious enough to question the usage of an order breakdown for a fund order.

Instead, they scheduled another meeting and talked to other colleagues about it.

The common conception was: "This is special handling of the bank. They do it for all their orders which must be why they do it here."

Another week passed, and both teams met again.

This time, someone finally took the chance to ask about the order breakdown.

This exploration team member finally questioned the choice of a breakdown structure, but he only looked into confused eyes.

"Is there another way we could manage the fund and order underlying assets to rebalance the fund?" was the question the bank's staff threw back.

And this is where a super small feature suddenly and temporarily became one of the largest in the whole project.

Fund management is regulated thoroughly. Although close to wealth management, there are so many more functionalities required to do it.

Gladly, as it turned out, the bank paid another company for the regulatory stuff of their own funds.

They only wanted to use the wealth management system to rebalance their funds.

This is perfectly fine to do and didn't add much overhead to the project.

2. What had happened?

Both parties involved, the bank and the software company, made some crucial mistakes.

No side asked enough questions right at the beginning.

The bank had assumed that the software company had the same knowledge as them-which they didn't.

The software company assumed, through their experience, that this "fund feature" was about buying and selling funds-which it wasn't.

No side dared to ask questions about this feature.

The software company should have proactively asked whether this feature was really about what they thought it was.

The bank should have proactively asked whether this was something that the wealth management solution of the software company could provide.

3. The lesson learned

Assuming something is never a good idea.

Whenever you are unsure, better ask a question too much.

And ask your questions as early as possible.

This can save you from many issues.

As soon as you are unsure, don't hesitate to ask whether you are right or not.

Someone with more knowledge than you can then jump in and correct your misconception.

This is the way you can get it right the first time and not only realize you made a mistake too late.

If the issue in the story above had ended differently, the whole project would have been a failure before it even really began.

A fixed-size, fixed-budget project that suddenly gets a required feature that takes years of development is doomed to fail.

4. Thread end

That's it for this thread.

I hope you learned something valuable.

If you enjoyed reading this Thread, consider dropping a like, retweet the first tweet, and follow me (@oliverjumpertz) for more content like this.