It sounds so easy. In an application you should only offer the functions and options you want to maintain. Why would you do it any different? Doesn’t it save time to only build what is needed? It might surprise you, but no. Sometimes building only what is needed takes more time. And still…. you should do that.
In my experience, there are two main areas, where offering less takes more time:
1. A lot of configuration or other settings
2. Complicated validation of data
A lot of configuration or other settings
If you ever worked on or with an app with configuration or settings, you probably know the situation. You can change something here, you can change something there. Different screens for entering the settings, but all of them affect the same functionality. And if x is yes, then y does not affect anything. But if x is no, y completely changes everything. Unless, of course, z is set to ‘always’.
When you start building, most of the time there are just a few options. But the more you build, the more options you get. In the beginning, you still know every variation. Then it grows and grows. Or time passes. You haven’t worked on those settings for months or years.
When the next group of options is added, it needs to be quick. Finding out how it works with all the existing options, why would you? You know in which settings must be set to make it work. And your customer knows that also. Or you will tell it once.
Then time passes again or the options grow even further. Another customer sees the option and tries to use it. But it doesn’t work. He calls the service desk, they don’t know either. Developers get involved, if you are lucky, the one that built it. The code is opened. No, it doesn’t work in this situation. It only works when x is yes. But the customer has x is no. And is not going to change that. So it took a lot of time and still the customer is not happy.
Complicated validation of data
You build an app for internal use. So you know exactly who is going to use it. You know what they know. And you can train them if needed. So, when you build a bit more complicated screen, they will know what they can and cannot enter. So, validation is not so important. Everybody will know what is allowed and not allowed.
Then this screen isn’t used for a while. Or the persons who frequently used the screen leave the company. New people start working with the screen. Or the screen is opened again after months of not using it. And then you notice: people don’t know anymore what is allowed or not. Mistakes are made. And if you are unlucky: your app is failing, because of invalid data.
Saving time is not always saving time
The mistake people make is that they build for the current knowledge for the current users. But knowledge becomes less when time passes. And users can leave. When you build something complicated, no matter if this is for data entry or configurations/settings, you shouldn’t build it for the current situation. Build it for the future. Build it for the users, that will work with it in three years. Build it for the knowledge, that is present in three years.
And yes, that means you should only build what you want to support. When you don’t want to build functionality for a combination of options, make sure a user cannot choose it. When you are not allowed to enter ‘No’ in field ‘A’ and ‘Yes’ in field ‘B’, don’t allow it. And preferably: give good error messages. Try to prevent that people need help, by giving them the information they need to know what is allowed.
This costs extra time, I know. And now it is time that might seem wasted. But most of the time it will save a lot of time in the future. I think everyone has experience with a situation, where a user did something and no one knows why it didn’t work as expected. How much time this costs. And how many people get involved with a problem like this. So why not avoid it? Even if it is with some extra time 3 years earlier.