Maintainable Code in the Era of Low-Code

Maintainable Code in the Era of Low-Code

Omnext just announced a new service for customers to help them understand the code maintainability of applications they build with OutSystems. This begs the question, what is maintainable code when we’re talking about a low-code platform? In this post we’ll highlight why this is a very relevant question to be asking, and why companies like KPMG (who build many low-code applications and happen to be “OutSystems 2018 Partner of the Year”) take this seriously.

Speed vs. Quality

Speed versus quality is a classic balancing act that applies to the process of building software. For those who prioritize quality, it makes sense that there would be a healthy skepticism of development platforms that promise greater speed. “If a platform helps a developer build software 10 times faster, surely this will lead to quality issues,” might be the thought process.

To address this concern, it’s helpful to substitute the word “speed” with “automation.” The speed increases delivered by low-code development platforms relate to things developers no longer have to do. Various studies show that as much as 60–80 percent of development time is spent on repetitive activities. The way we write code to take data from a database table and present it on a screen doesn’t vary much from screen to screen. The way we ensure a screen displays well regardless of form factor tends to be the same for each screen. The way we ensure security, internationalization, accessibility… you get the picture.

There are many accelerators already built into the leading IDEs to help automate these types of activities by generating various snippets of code. Low-code development platforms extend this further by allowing developers to visually model solutions without even having to write code. The platform takes care of all the repetitive stuff. Does this mean the developer is no longer coding? Absolutely not. The developer still has to model the logic and data of the application, design the screens, connect to data sources, maintain good architecture, and so on.

Speed vs. Control

Assembly Language Macros

This claim of 10x development speed is often perceived negatively by developers who worry they are losing control over the “code” of their application. I think of it differently. My first coding job was in assembly language, and it took forever to do even the most basic things. When macros were introduced to automate instruction coding for assembly, there was a similar concern from developers: “I don’t like it! I’m losing control!” When I transitioned to C++, I didn’t once miss loading registers or trying to squeeze code into a 4k segment—I was able to focus instead on what the software needed to actually do. Then came Java. No more worrying about garbage collection or wrestling with apps that needed to run on more than one operating system or platform. This felt like nirvana compared to before.

Each of these language evolutions automated many of their predecessors’ tasks; tasks that consumed so much of my time as a developer. Instead of hunting down memory leaks, I could focus on solving the business problem. The automation that low-code development platforms provide is the reason teams are able to deliver software substantially faster. I would say that those who worry about this being a loss of control are just kidding themselves. To me, that’s like worrying about what happens to your Javascript code after it is written.

Back to Quality

Growing up in the U.K., the phrase “more haste, less speed” was commonplace, and I never really thought too much about what it meant. Thanks to automation, low-code enables a much higher degree of “haste” than lower-level programming languages. You can deliver meaningful outcomes to the business faster compared to manual coding. But, like any programming language, a developer rushing to deliver solutions with low-code can make mistakes. “Speed” without quality can result in a poor architecture that, in turn, leads to issues in areas like performance, security, or maintainability.

So, how do you ensure quality with a low-code development platform? It turns out that it isn’t really that different compared with traditional programming languages. Best practices are defined that have to be checked, either manually or, better yet, with automation.

Enter Omnext

Omnext is a company focused on providing automation solutions that ensure the quality of software written in over 30 different languages. They have developed a solution for OutSystems customers based on the ISO-25010 guidelines for software maintainability and quality supplemented with OutSystems-specific best practices. They help organizations answer the following types of questions across a portfolio of OutSystems applications:

  • How has the maintainability changed since the last sprint?
  • How do the code quality and productivity of my scrum teams differ?
  • How can I reduce my maintenance costs?
  • To what extent are components re-used?

Omnext Fit Test provides a snapshot of an app’s current software risks. Customers can also sign up for a regular cadence of risk scans with the Stay Fit program. Results of the analysis are presented in an elegant dashboard within the Omnext Portal. A point-based scoring system makes issues easy to identify.

Omnext Dashboard

Omnext has developed their own ORQA index, a quality score based on the impact of any best practice violations and the effort required to resolve them. Adapted to include OutSystems best practices gathered from years of experience across large portfolios of applications, this index can be used to help prioritize any remediation efforts.

By comparing points-in-time, you can see whether new issues are being introduced as your teams deliver new releases. To facilitate the fixing of issues, the Omnext Portal provides more detailed views to help pinpoint exactly where in your OutSystems model those issues were found. Since organizations may have different standards, custom rules are also supported to further tailor the results of the analysis.

Omnext Code Analysis Dashboard

Tangible Benefits of Understanding Quality

Intuitively, we want our software to be of higher quality. When it comes to security and performance, the potential repercussions of low quality are self-explanatory. Low-code maintainability may have some less obvious benefits, but they, too, are important.

Future Readiness

Applications that are built following best practice guidelines are likely to last longer and add value to their users for a longer period. They are also easier to adapt to changing requirements.

Reduced Maintenance

It is easier to maintain an application that is built well. Less time spent on maintenance means extra time available to deliver new, high-value functionality.

Enhanced Reusability

Well-architected elements are more likely to be used again, and reuse can increase productivity.

Improved Skills

Sharing quality insights with your development team helps them understand how to architect higher quality applications, raising the overall skill level of your team.

Ultimately, while the higher level of abstraction enables much greater speed, developing with low-code is not that different compared to writing code by hand. Quality still needs to be built into your development practices, and by automating your quality checks, further efficiencies can be gained.

To find out more about how Omnext can help you identify opportunities that might be hiding in your OutSystems applications, check out their website. For a limited time, they are offering a free Quick Fit Test scan of an application. For those who need more assistance, Omnext has partnered with KPMG so you can take advantage of their depth of experience with OutSystems. KPMG will conduct expert reviews of an organization’s applications and draft up detailed improvement reports.

Now, go in haste.

Written by Mike Hughes – Senior Director of Product Marketing, OutSystems.

Link to original post: https://www.outsystems.com/blog/posts/maintainable-code-low-code/

Van AGILE documentatie naar FRAGILE documentatie?

Van AGILE documentatie naar FRAGILE documentatie?

Vandaag de dag werken de meeste organisaties volgens een Agile software-ontwikkelmethode. Hierin worden bestaande systemen onderhouden en nieuwe functionaliteiten en/of applicaties gerealiseerd. Deze applicaties moeten meestal nog lang onderhouden worden, wat in de tijd niet altijd plaatsvindt door dezelfde teamsamentelling. Belangrijk is dus dat van de essentiële functionaliteit (20% tot 30%) een goede actuele productbeschrijving aanwezig is.

Karakteristiek bij Agile development is dat gebruik wordt gemaakt van User stories. User stories zijn ontstaan binnen de Extreme Programming (XP) methodiek, waarbij ze primair gebruikt werden als een ‘speelstuk’ in de planning game. Alle user stories komen in principe op de backlog en bieden daarmee een geprioriteerde lijst waarmee de PO en het development team een volgende iteratie of release kunnen plannen. Per individuele story worden de benodigde taken (development, test, requirements, etc…) bepaald die nodig zijn om de gewenste functionaliteit op te kunnen leveren.

We zouden derhalve kunnen stellen dat een user story voor een significant deel een planningseenheid is. Uiteraard bevat een user story ook primaire requirements om de acceptatiecriteria van de story zo scherp te maken. Deze acceptatiecriteria kunnen vervolgens gebruikt worden om de story te valideren op volledigheid en correctheid.

Bij het gebruik van user stories wordt meestal voor iedere wijziging een nieuwe user story beschreven zonder de oude aan te passen. Hierdoor kan het lastig worden om na oplevering een scherp beeld te hebben van de actuele functionaliteit. User stories zijn hierdoor ongeschikt als product (applicatie) documentatie.

Zo wordt AGILE-documentatie m.i. dus FRAGILE-documentatie.

Bent u het eens met deze stelling en benieuwd naar mijn visie over hoe dit op te lossen valt? Lees dan volgende week deel II uit deze blog-serie.

Voor iedereen die niet kan wachten en nu al graag het gesprek aan gaat, voel je vrij om contact met mij op te nemen!

Jaco de Vries

jaco.de.vries@omnext.com

New! – Automated OutSystems quality reviewing with Omnext

New! – Automated OutSystems quality reviewing with Omnext

As model driven development is emerging, OutSystems has become one of the leading low-code development platforms for developing both web and mobile applications. Model driven, or low-code development platforms such as OutSystems have one major advantage over their full-code cousins: rapid application development and full control over the application life cycle.

One thing must be kept in mind though: the delicate relationship between speed and quality. Building applications rapidly may result in applications that are of poorer quality. Even though low-code platforms such as OutSystems are closing the gap between IT and business, creating future-proof applications remains key when aiming for reaching maximum potential of these platforms.

Fortunately, OutSystems customers are realizing this exact point as well and they have been increasingly asking for governance on their software development processes. They are looking for answers to questions such as: How has the maintainability changed since last sprint? How does the code quality and productivity of my scrum teams differ? How can I reduce my maintenance costs? To what extent are components re-used?

In order to meet customer’s wishes and help them to reach the full potential that low-code platforms have to offer, Transfer Solutions and Omnext have joined forces to realize an automated quality scan for OutSystems.

Omnext has been specializing in analysing software applications for over 15 years and its technology, the Omnext Fit Test, is thus far already supporting over 30 different languages more modern ones such as Java, C# and SQL, but also legacy languages such as RPG and COBOL.

Together with both Transfer Solutions and OutSystems, quality rules were defined, based on the ISO-25010 guideline for software maintainability and guidelines on software quality, supplemented with OutSystems-specific best practices. The importance of these rules is adjustable and customers are able to add their own rules, hence enabling them to gain insight in the exact elements of an application that are of key interest to them.

After working together closely with Transfer Solutions and OutSystems for several months, Omnext has managed to add the OutSystems platform to its list of supported technologies and we are proud to present the result: The Fit Test 4 OutSystems.

The process to get insight in code quality, looks like this:

  1. Source code upload

A customer sends their OutSystems application exports (.oap file) to Omnext via a secure upload facility;

  1. Code scan

Omnext scans the models and code and presents the quality metrics in a user friendly dashboard, which provides detailed insight in a multitude of quality and productivity elements (see image below);

  1. Dashboard and Expert Review

The results as presented in the dashboard enable the customer to identify areas for improvements and if required, Transfer Solutions can offer its expertise in the form of Expert Reviews to really help customers take the next step in improving the quality of their applications.

The Fit Test 4 OutSystems can be executed as a single scan, but also as a repetitive cycle which allows customers to analyse their applications on a frequent basis. Especially in a continuous delivery context, having continuous insight in the quality and development of your application proves to be of great added value. To further support this in the future, Omnext, together with OutSystems is already exploring the possibility of using an API to automatically transfer the application sources to Omnext and have them analysed on the fly.

We believe that the Fit Test 4 OutSystems is a perfect addition to the OutSystems Platform. With it we ensure that our customers can deliver high quality OutSystems applications now and in the future.

If there are any questions in response to this blog post. Feel free to contact Omnext or Transfer Solutions.

Jacob Beeuwkes, Transfer Solutions
Francis Jansen, Omnext

1 + 1 = 3!

1 + 1 = 3!

 

Hedendaagse statische analysetools zoals SonarQube kunnen veel betekenen op het gebied van kwaliteitsverbetering van uw broncode. Bij een juiste inzet van deze tools wordt de introductie van nieuwe technische onderhoudbaarheidsrisico’s voor een belangrijk deel gemitigeerd, wat op lange termijn een grote besparing kan opleveren voor uw organisatie. Een groot nadeel van deze tools is echter dat de geconstateerde risico’s en overtredingen teveel toegespitst zijn op één, dan wel een beperkt aantal, technologie(ën)  en teveel technisch van aard zijn. Uw afdeling Risk Management zal vaak wel weet hebben dat deze tools worden ingezet, maar de toepasbaarheid van de tool voor hun is (waarschijnlijk) nihil. De reden hiervoor is dat de tools geen inzicht bieden in functionele risico’s.

De effectiviteit van zo’n analyse tool zou veel groter kunnen worden als naast de technische risico’s ook de functionele risico’s in kaart worden gebracht.

 

Wat heeft de functionele vraag met de broncode te maken?

 

Wat als je uitgaat dat een stuk technische broncode feitelijk niets anders is dan een implementatie van een functionele vraag? Dan zou je dus mogen concluderen dat functionele risico’s afgeleid kunnen worden op basis van technische risico’s? Het antwoord op deze vraag is: ja, en heel goed ook.

Maar waarom zou je functionele risico’s in kaart willen hebben? De volgende vijf antwoorden zijn ondermeer te geven:

  1. Omdat de gebruiker denkt en praat in functionele termen en niet in technische termen;
  2. Wijzigingsverzoeken zijn bijna altijd functioneel van aard. “De gebruiker wenst…”;
  3. De impactanalyse van een Request For Change (RFC) kan veel beter worden ingeschat als de RFC-behandelaar beschikt over feiten die gerelateerd zijn aan de broncode die geraakt wordt in het wijzigingsverzoek;
  4. De kwaliteit van een technisch aanpassing kan achteraf bij een vervolgmeting worden gecontroleerd door de functionele wijziging te volgen en af te zetten tegen de verwachte impact. Met andere worden, de cirkel is rond: je verwacht een bepaalde impact op een RFC, de RFC wordt geïmplementeerd en je controleert daarna of jouw inschatting al dan terecht is geweest. Hoe lerend kun je zijn als organisatie?
  5. Klanten die het beheer van hun systeem hebben uitbesteed, willen heel graag de kwaliteitsontwikkeling van hun systeem volgen maar hebben de technische kennis niet in huis oftewel: de leverancier geeft geen transparantie en openheid.

Het zou dus mooi zijn als je beschikt over een tool waarin het mogelijk is meerdere technologieën in onder te brengen en de broncode zodanig weet te visualiseren dat ook de eindgebruiker een functionele blik op het systeem krijgt.

 

Hoe helpt dit de kloof tussen eindgebruiker en techneut te dichten?

 

Is zoiets te realiseren en hoe werkt zoiets in de praktijk? Ja: vanuit mijn ervaring kan ik aangeven dat dit zeker te bewerkstelligen is. Hierbij zijn de verschillende partijen betrokken en de volgende stappen kunnen genomen worden:

  • de afdeling Functioneel Beheer stelt een lijst op van alle functionele componenten die in het systeem zijn ondergebracht
  • De afdeling Development stelt een lijst op van alle technische componenten die in het versiebeheer zijn ondergebracht;
  • Beide lijsten worden via een koppeling aan elkaar gerelateerd. Dat is een handmatig proces waarvoor het noodzakelijk is dat beide partijen om de tafel gaan zitten.
  • De uitkomst van de koppeling wordt in de tool ingeregeld en de kwaliteitsmeting wordt uitgevoerd.

Hiermee is het mogelijk om de klassieke kloof tussen eindgebruiker en techneut te overbruggen. Aan de tool wordt wel als eis gesteld dat zij heel veel technologieën moet ondersteunen (van klassieke programmeertalen tot workflow, 4GL’s, document generatoren, etc.) en tot in hoge mate inregelbaar moet zijn.

Dan en slechts dan is deze kloof te overbruggen en kan de som “1 + 1 = 3” worden gemaakt!

Vragen? Neem contact met ons op. 

 

 

Business Rule Mining in het Omnext® Portaal

Modernisatie van applicaties: een moeilijk en vaak tijdrovend karwei. Wat als wij u vertellen dat wij alle expertise in huis hebben om de zogenoemde ‘business rules’ uit uw software te halen? Door de broncode om te keren en deze regels inzichtelijk te maken kunt u zelf bepalen welke regels nog geschikt zijn voor de toekomst. Sterker nog: uw hele bedrijfsstructuur wordt weer opgehelderd. Hoe vaak komt het niet voor dat wijzigingen in berekeningen, of andere cruciale bedrijfsstrategieën alleen worden door gevoerd in de broncode van uw software? Het Omnext® Portaal biedt alle inzichten.

Onze collega Coen Burki heeft een boekje over ‘Business Rule Mining’ opengedaan afgelopen 30 maart. Hierboven vindt u de opname van de webinar. Bent u geïnteresseerd in deze oplossing, of wilt u gewoonweg meer weten? Neem contact met ons op, dan sturen wij Coen!

Geïnteresseerd in dit onderwerp?

Meer informatie

De enige waarheid zit in de code

De enige waarheid zit in de code

Steeds vaker krijg we in onze software-analysepraktijk te maken met de vraag of wij met behulp van onze analyse software kennis uit bestaande systemen naar boven kunnen halen. Veel bedrijven zijn namelijk afhankelijk geworden van slecht gedocumenteerde en zeer lastig te onderhouden softwaresystemen. Men wil de risico’s hiervan mitigeren door het moderniseren of vervangen van deze software. Er zit echter jarenlange belangrijke domeinkennis en ervaring in de software verstopt, die men niet wil verliezen. Hoe zorgt u ervoor dat u deze kennis kunt behouden?

 

Top-down vs. bottom-up benadering

Een manier om de kennis die in software verstopt zit weer boven water te krijgen, is het interviewen van subject matter experts, waarbij door middel van een top-down approach o.a. bedrijfsprocessen/services en bedrijfsregels worden geanalyseerd en beschreven. Dit is een prima manier om ‘met de kennis van nu’ naar de organisatie en de behoefte aan geautomatiseerde ondersteuning te kijken. Een nadeel van deze methode is dat men niet alle kennis die in de loop der jaren in de softwaresystemen is verwerkt, paraat heeft. Het risico is dan ook dat men zeer relevante bedrijfsregels bij de top-down benadering over het hoofd ziet.

Bij Omnext pleiten we dan ook voor een combinatie van een top-down en een bottom-up benadering. Bij de bottom-up benadering wordt kennis uit de bestaande software gedestilleerd en beschreven. Er wordt niet voor niets vaak gezegd dat de enige waarheid verstopt zit in de code.

 

Beperk de scope

Van belang bij het expliciet maken van kennis in de broncode is het bepalen van de juiste scope. Om de bottum-up benadering goed in te kunnen zetten kan het gebruik van de juiste tools de benodigde inspanning drastisch verlagen.

Documentatie moet ‘lean and mean’ zijn. Net voldoende om het systeem goed te kunnen onderhouden. Het heeft geen zin om documentatie te produceren met informatie die eenvoudig al uit de software is te halen. Zo zijn schermbeschrijvingen en screenshots wat ons betreft niet zo interessant. Veel interessanter zijn de validatie- en rekenregels. Ook documentatie over het onderhouden van stamgegevens is niet interessant. Daar zitten over het algemeen weinig interessante bedrijfsregels in. Ook blijkt vaak 30% van de broncode van legacysystemen ‘dood’ te zijn. Ook hiervan wil je geen documentatie opleveren.

Afhankelijk van het doel kan het interessant zijn om je te beperken tot dat gedeelte van de code wat in de afgelopen periode nog actief is onderhouden. Hiermee kan je  de scope ook zomaar tot 10% van het totaal reduceren!

Daarnaast is het niet zinvol om voor de hand liggende te functionaliteit te documenteren. Iedereen weet ondertussen wel hoe je een postcode valideert. Focus je bij de documentatie dan ook op die delen van de software die uniek zijn voor jouw business. Vanuit onze ervaring weten we dat dit vaak maar 20% van het totaal is.

Vragen? Neem contact met ons op.