New feature in a simple tool vs. comprehensive app: what's the difference?

The thing is, it’s not that difficult to explain the reason behind this. But in IT, it’s just not that obvious. Suppose you want to have a shed built. You hire someone who’s good at laying bricks. They level the floor, erect a number of walls, build a roof, and board up the interior. It’s inexpensive and it looks great — until, at some point, the shed starts to slope and isn’t that sturdy, and you discover it might actually be dangerous. But who cares? It’s a small and quite inconsequential shed, so it’s not that bad.

Now, let’s apply the same idea to a two-story school building. Can you adopt the same approach? Well, you can, but the stakes are pretty high. You’re dealing with significant risks, there’s a wealth of regulations, and anyone will understand a building like this should be built in a much more structured and safe way.

It’s really the same with software development, which is mainly about how your application will function. Will it be used often? Are the stakes high? Is it a quite large application? In that case, quality is crucial. It’s less essential if the stakes aren’t high and you mainly want to test it.

Shed versus school building

In this article, we want to provide more insight into the approach for these two product types. Generally speaking, when you build your own simple tool for internal use, the phases of the development process are different than when you create a complex application with hundreds of users.

So, in this article, we assume the following: ‘simple tool = shed’ and ‘comprehensive application = school building.’

How it works with a simple tool

With startups or relatively simple tools, you often see that someone is building an application on their own. Someone has a good idea, so a developer gets to work and builds it relatively fast.
Once the tool is used, bugs occur, which are fixed in a reactive way. There is little risk involved. The application only has a few users — or, it’s just used internally.

In this type of situation, the development process might take up 75% of the time commitment. The other 25% is spent on fixing bugs, fast deployment, and any related communications.

There’s nothing wrong with this. Particularly those who are in the pilot phase of their company want to launch features quickly, experiment, and learn. The same goes for an internal tool you’ve built — for example, for time registration. There are no external customers, so experimenting is relatively risk-free. You don’t have to perform quality assurance, such as code reviews and unit testing. If there are bugs, you just fix them, and it won’t cause much trouble.

How it works when you build a more comprehensive application

However, if your company has evolved and you’ve built a more mature product, you’ll have to go about it differently. An example includes a large-scale application that is connected to external services. Suppose you want to add QR code scanning to start a specific action. It’s a relatively simple feature, but it does have several dependencies. You will need to test the application thoroughly to avoid that users experience any disadvantages or, even worse, are no longer able to perform their tasks.

Obviously, the extent to which you do this also depends on the complexity of a feature or module. Complex ideas require thorough research: what’s the purpose of the feature, what should it look like, and what dependencies does it have? If it’s a particular button with an action, who can click it — anyone or only those with specific rights? Does this mean aspects such as security and authorization are relevant, too? How do we substantiate that users will appreciate this new feature?

Development

Once everything is clear and specified, the developers start building the feature.

Whereas the development of a simple tool might take up 75% of the total time commitment, the development of a complex tool is a relatively smaller part of the overall process that could even just take up 40%. What else needs to be done?

As you need to detect and fix any bugs, this takes a lot of time — especially when it involves complex functionalities with many dependencies. After all, a larger company has various quality standards you should adhere to. Processes have been set up in accordance with ISO standards. And don’t forget vulnerability scans that automatically check whether an application is working properly. Rather than just testing with dummy data, you want to perform thorough and extensive tests using realistic data.

Deployment

If everything works properly in the test environment, the feature moves on to production — or, deployment. This isn’t a small task, either, since someone will have to supervise and monitor it. Will the go-live of the feature go smoothly? With a small tool, you basically just press a button and it’s live. A complex tool with many users involves various risks you need to cover. What you don’t want is the go-live to shut down their application, which will prevent them from doing their jobs.

Other elements of sustainable development include:

• Maintenance: After everything has gone live, there may be maintenance costs. If the feature is in a critical, complex spot in the software, you may need to spend more time fixing bugs. If there are dependencies on APIs (and therefore third parties), you’ll need to keep them up to date.
• Documentation: in addition to documentation about the development process, you might want to consider email communications with users, manuals, onboarding content, release notes, and other forms of communication or explanatory documentation.
• Training costs: For certain software features, it might also be necessary to coach and train other teams.
• Unforeseen costs: You will always encounter surprises. If a new feature requires a lot of memory and storage, you need to support that by doing the necessary prep work with regards to the infrastructure of your application.