Hvordan kan man spare 80% af omkostningerne på udvikling?

How to Save 80% of Your Software Development Costs?

How do you quickly succeed with making robust software? At GPower, the keyword is reuse, but as is the case with many other things, care must be taken when reusing.

The public space is full of examples of software that exceeds deadlines and budgets. One could list numerous examples, but it suffices to remark that cost increases in the 100m € class are well-known in public IT in Denmark (For more information, click here). Obviously, a plethora of circumstances contribute to the price tag on software development, but where to start if you want to make it quicker and cheaper?

Reuse

Looking at the actual development phase, there is a single thing that decreases cost and time: Reuse. If you can reuse code from previous projects, large savings are possible. Many of the time-consuming tasks lie in developing code blocks that are very generic and not unique to the actual project. If these parts are developed in advance, the development task is significantly reduced. Actually, our experience shows that as much as 80% of the code base can be established in advance, so there are rather large rewards at stake.

In order to realize these savings, a very structured approach to reuse is required. If your approach is the classic “cut and paste”, there are many caveats in code reuse. An in-depth knowledge of the original code is required, such that you are completely aware of the purpose of the code and the limitations it may contain.

Modular Software

Furthermore, it is important to encapsulate the code efficiently. If it is to be used several times, changes will inevitably occur. Therefore, all code should reside in well-defined modules with lucid interfaces, and they should generally be designed in accordance with the SOLID principles. Overall, the code should not be seen as a fluttering piece of code but as a tool, and as with all tools, it is worth spending time making it properly, such that it will last and can be applied in many situations.

When we talk about 80% savings, it is naturally not just restricted to the development phase. If 80% of the code is reusable, it obviously yields an according cost saving in the test phase if the code is made modular. The design phase can also be completed significantly faster, if you know exactly what tools are available in your toolbox. Not to mention maintenance: Everything that happens after deployment also benefits from code reuse, since the building blocks gets much more mileage, so the code has been tested to a much larger extent. And since maintenance is a continuous task, massive savings are possible in the long run.

Book a Non-binding Meeting

Does it sound interesting to you? Right now, you can book a non-binding meeting with us!

Call or write us: +45 51 90 57 90 or gpower@gpower.io.

Fem ting, du bør gøre, når du opgraderer TestStand

Five Things To Do when Upgrading TestStand

What to do when your test system is running on an obsolete version of TestStand and you are not all confident transferring the code to the newest version of TestStand? Here are five advices on how to upgrade your test system.

Should you change a test system if it is not broken? Most people would probably answer no, and therefore many test stations are left untouched for many years. Because it works. Mostly. But there comes a time where upgrading the system cannot be postponed any longer. Maybe due to externally imposed requirements, compatibility issues or internal pressure, but something must be done.

The system is disconnected from the progress, and the current TestStand is probably several versions away. It is tempting to just crank the version one level up to keep the train running. That said, the future-proof solution is to upgrade to the current version of TestStand.

It can seem like an unmanageable task, and you might fear that the test system no longer will work in the new version of TestStand. The goods, however, is that in 99 cases out of 100, there will be no errors. The old software will be completely compatible with e.g. TS2019, and you could just move your sequences and code modules straight into the new IDE (unless you’re dealing with TS 4.2.1 or older versions, then you will have to manually migrate your sequences and configuration files etc. (see here). However, the latent problems would remain in the code, and you would have no real benefit of upgrading TestStand. In order to make the most of a TestStand upgrade, five advices:

1) Research new features

Before you start upgrading, take the time to review what new features have been added to TestStand. Browse through the documentation on NI’s website, and preferably have a look at the examples being published by NI’s application engineers. Maybe new features have been implemented that solve the challenges you have been struggling with previously – and perhaps only found half a solution.

2) Do not reuse old code uncritically

Be absolutely confident about what you reuse and why you can reuse it. As a default, you cannot reuse anything until the opposite has been proved. Is the code developed using best practices? What was best practice when the code was developed, might not be the case anymore.

3) Pay the “technical debt”

Use the opportunity to clean up in what at the time was the easiest solution to get something to work in a hurry. Typically, some very short shortcuts were taken, and therefore maybe only solved a problem partially. Over time, many of these solutions will add up to a large quantity of what we call technical debt.

4) Examine your own process

How do things work in practice? Is it the optimal process? Would we actually rather do things in a different way? Often, one of the biggest problems can be the culture in the company and overcoming the “that’s the way we use to do it” paradigm.

5) Involve the people that will use the system

It is also important not only to involve test developers in the upgrade, but also operators and any other person that may use the system in their everyday. Maybe some of the new features would solve the nuisances the experience during their workday. In the end, consider it an inspection, because honestly, when will you get the opportunity to change the system again? Seize the chance to get back to the cutting edge, such that the task will not be even more difficult in a couple of years.

In case you have any unanswered questions, do not hesitate to contact us. We are experienced with all parts of the process: Training co-workers in the newest version of TestStand, code review, and best practices in development and maintenance of code.