Developments that are believed to be innovative can sometimes be disappointed in a WBSO application. In this blog I will highlight a number of developments in the industry that make it difficult to submit a successful WBSO project. Finally, I share a number of tips that will help you to arrive at a promising application.

WBSO in a dynamic IT playing field

The need to reinvent the wheel or to manage and maintain your own infrastructure has faded into the background. In that respect, development teams can focus on developments that give their software real added value for the end user. This also makes teams more agile, so that they are better able to respond to changing customer wishes or new technological insights that arise during the implementation of a project.

The flexibility that characterizes modern development is sometimes at odds with the level of detail expected in a WBSO project. There are often uncertainties about the technology choices to be made in the initial phase. It can be a struggle to name concrete classes in advance that play a role in the project. At the start, a team mainly focuses on making an inventory of features. In which classes they fall apart and how the mutual interaction works out is often not yet clear. However, it is essential to think about this in advance for a promising application.

The rise of no- and low-code development

With the emerging technologies of Betty Blocks and Mendix, a move to no- and low-code development is underway. Instead of writing programs in source code, these techniques make it possible to configure the data model, flow and logic. Interpretation to the underlying program code is hereby made abstract for the app developer who applies these techniques. Although describing this logic often requires a lot of thinking, these innovations do not qualify for WBSO.

Machine Learning and Big Data

With the increased availability of large amounts of (structured) data and the reduced costs of computing resources, developments in the field of machine learning and big data are within reach for a large number of developers. It is nice for them that there are libraries for environments such as R and Matlab, to develop algorithms that can be trained for different use cases.

Practice shows that these developments usually do not translate into a promising application. This can be perceived as a paradox, all the more so because companies consider these developments to be pre-eminently innovative.

Development in a formal programming language

The reason why developments within the above contexts do not qualify for WBSO is because the deliverables that arise are not written in a formal programming language. As of 2016, the aspect of the 'formal programming language' has been added to the definition of software in the law. However, the explanation of what constitutes a formal language is not enshrined in law.

With the experience I have gained in this area, it is reasonable to say that languages that can serve a general purpose (and are used for a wide variety of developments) can be justified within WBSO. Think of Java, C#, C++, PHP, JavaScript, Ruby, Python and Go.

A good start is half the work!

"Look before you leap." It is important that the application starts at the right level. The application or impact of an innovation is not directly relevant to a successful application. It is important that you have a goal in mind with the project and that you emphasize its distinctive character in terms of developing your own new technical knowledge and skills. It is important for the application that you demonstrate that you intend to deliver one or more software components. Matters that do not pass our attention when writing an application are described below:

• Emphasize technical deliverables that drive the intended innovation, not the functional components that live in the end-user world.

• Describe the technical bottleneck that arises during the development. Failure to match the speed or accuracy of a computation performed by the component is part of the problem, but not the technical bottleneck. That should be about why a regular programming technique is not sufficient to develop the component in such a way that the calculation can be performed with the required speed or accuracy. It is important to identify the cause of the bottleneck; this argues why it is a sticking point for you.

• State in the proposed technical solution which approach you choose to deal with the technical bottleneck. The solution direction will have to contain a new technical operating principle that you will incorporate into the software. The new operating principle is an important aspect of your description. After all, if you do not intend to develop a new principle, then this means that you are elaborating on an old routine (and the WBSO subsidy is not intended for this).

• You complete the technique of your application by making it plausible that the solution direction is not an A-B-C, but that there are technical risks that jeopardize the success of the proposed approach. Finally, do not lose sight of the connection between the above topics. Some subjects are obvious to the technically trained advisors of RVO who assess your application. If you believe that the technical principle is less widespread in the developer community, please explain the principle. This strengthens the content of your application!