Low-code platforms in the RAD vs. Agile speed wars
How do developers feel about so-called ‘low code’ platforms?
In truth, we don’t really know yet as their very existence is a comparatively new phenomenon on the clock that tracks spacetime in the total software application development universe.
One player in this space is OutSystems. The company has a low code platform to allow programmers to visually develop an application, integrate with existing systems and add their own code when needed.
In this age of code automation, intelligent provisioning, containerised application structures and packaged services… could low code come out of its ‘only used by incompetent and lazy programmers’ reputation and finally feature as a useful means of production in high intensity software shops?
VP for UK and Ireland at OutSystems Nick Pike (obviously) thinks that low code will be popularised and he now takes time to clarify its place in a world where high velocity programming must very clearly understand and appreciate the difference between Rapid Application Development (RAD) and Agile development.
Code fast, always
Both RAD and Agile are broadly thought of as a means of coding fast, to put it simplistically, but what is the difference?
“RAD and Agile both emphasise early and continuous software delivery and welcome changing requirements even in late development. However, Agile prescribes its methods and ideal working environments. RAD is far more flexible, emphasising quality outcomes over the exact way and timeframe in which they are delivered,” said Pike.
RAD methodology
Pike says that the essence of RAD is its flexibility to adapt to changing customer vision throughout the development cycle. It starts by defining a loose set of requirements, so developers get an idea of what the product needs to achieve — and this couldn’t be further away from those detailed spec sheets of the past.
“Developers then create a prototype that satisfies all or some of the requirements. This prototype may cut corners to reach a working state and that’s acceptable because any technical debt accrued will be paid down at a later stage. This prototype is presented to the client and feedback collected. At this point, clients may change their mind or discover that something that seemed right on paper makes no sense in practice. This kind of revision is an accepted part of the RAD approach and developers return to step two to revise the product,” said OutSystems’ Pike.
If client feedback is entirely positive then developers can move to the ultimate step of finalising the product and it can be handed to the client with confidence that it meets their requirements.
RAD benefits
Pike and the OutSystems team detail the following potential benefits of RAD:
- Speed: Thanks to the feedback from the prototype phase, there is a far greater likelihood that the product delivered will be acceptable to the client the first time.
- Cost: Developers build the exact systems the client requires and nothing more instead of building out complex features that may not make the final cut. The prototype stage of RAD eliminates this costly exercise.
- Developer Satisfaction: The client is there every step of the way as developers present their work frequently. Not only does the client become more confident, but the development team no longer feels divorced from those who will be using their software.
Is 2018 the year of low code?
Well definitely somewhat maybe… but in a world of faster development, knowing where we stand on RAD vs. Agile is fundamental if we are to speed up.