Avoid flexibility!

On the project I am working on, the software should be able to do anything. It should be possible to make all kind of transactions, it should be possible to ad an unlimited amount of Mortgages (and to pay back an unlimited amount of Mortgages). The whole application should be unlimited.
When I came into the project, there was already a basis for this. The user is able to combine all kind of inputs (Transaction, ToPay, ToReceive, and some other things) all these inputs can have an unlimited number of items.
There is a difference between "design time" and "runtime". Design time is where the administrator can create models, by combining those input-designs and creating default items for them.
The runtime is when the design is used to make an invoice. The input-design becomes an input and the default item an item. I really liked this idea, but after some time things where getting difficult. One of the things is that inputs have dependencies, and different inputs have different behaviour for these dependencies.

In Holland we have some kind of tax which needs some money from a transaction and money from a Leasehold. But how do you know which transaction belongs to which leasehold? Ok we only take one leasehold and combine all the transactions, that is enough for this tax. But how do other inputs work with dependencies? and how can we make it as flexible as possible?

This is why I want to say, stop with this stupid flexibility! it only cost valuable time to implement things and make it possible for the user to do everything!

Flexibility is good and in software development it is very useful to have (without flexible code it gets difficult to add features to the code). But please stop asking for "everthing should be possible"-applications...

It's all about the language

In software development it is very important to name your classes, methods, properties, etc in the right way, so you can find them quickly. It is also important to name them the way you talk about them, this became very clear to me during my current project.

The project I am currently working on is a project for solicitors. The project is only focussing an a relative small part, namely invoice creation.
Solicitors are working with cases (at least here in the Netherlands they are). For such a case they create an invoice. In this new software they want to choose from several types of things, when they are involved in selling/buying a house, they want to choose that specific invoice model and when they are involved in setting up a will, they want to choose that invoice model.
Each model has some elements. In case of selling/buying a house there is a transaction, some tax and other important stuff.

This is really simple, but when I stepped into the project, there where not such types. Instead there where some types called Case, CaseComponent and CaseComponentAspect. Every day there was a discussion between the developers and the domain expert about what the meaning of these types where. At some point the developers made a "conversion list" telling what the domain expert said and how they called it.
According to the domain expert these things where called: Case, InvoiceModel and InvoiceElement. This is exactly how I expected it to be and soon I pushed the other developers to change it. After the refactoring there weren't any discussions about the naming and everything is clear to everyone.

Therefore, please choose your type names carefully, so that every member of the team knows where you are talking about...