January 6, 2023 - Blog

Lessons Learned In Low Code

OutSystems Partners

At Version 1 we have been working with OutSystems since 2019 – and have recently had a series of large public sector projects go live.

Whilst every project has its own challenges, this blog explains some of the low-code-specific challenges that have popped up along the way, despite our best efforts.

We get it, developers move fast with OutSystems. That’s fantastic, and typically results in 30-50% less development time than traditional coding.  But invariably our projects have fixed deadlines and a set of minimum viable product requirements that must be delivered for the first release. The danger we see is in a few areas, as highlighted below.

Perfect is the Enemy of Complete

Can the customer’s product team keep pace with the changes, and keep a backlog for future sprints, that is not just a constant iteration cycle around some of the main screens?  This requires a step back after each sprint, to look at the progress against MVP, and strong control over what is ‘good enough’ for this release, knowing things can always improve.

Sometimes it takes an experienced agile business analyst to really lean in and help prioritise; sometimes it takes strong and active project management or governance, that really leans into the content of each sprint.  But the focus should be in making all required features work, and then improving them – instead of trying to really optimise one at the expense of others.

Negating the Admin Users

Are we spending enough time outside the main happy path – with the role of administrators, helpdesk operations, and supervisors to act on behalf of any one of the other actors in the scenario?  Especially with large public sector customers, people sometimes just don’t get the technology, so we need to make sure we can troubleshoot and support effectively.

One pattern we often surface is to make all the system data available to a supervisor role in the super-easy “list and details” routine. In this way, at least one end user can trace a problem through the tables, if it’s not obvious on the main user interface for some reason.  We do not want to have to rely on direct database access for routine data tracing and investigation.

Short-Circuiting the Testing

It’s really easy at the start of a project to just get into feature-factory mode, and churn out screens at a speed that is really exciting.  But testing those properly takes time, partly to look at the described feature and validations to ensure it works as expected – but also to look at the different end-user personas, and then do some exploratory testing to see how robust the solution is, and if strange data or click combinations come up with something unexpected.

One option for handling that is to include the functional testing in the developer’s definition of done – building up the regression suite

Not Getting Out of Agile Development Mode

As described above, low code development can sometimes be seen as “agile on steroids” – we become obsessed with more features, more validations, and constantly improving the overall user experience.  That’s brilliant – up to a point.

With a large-scale project, especially in the public sector, we typically must launch the first release with a big bang deployment.  This means that there should be a set of functionalities that is stable and tested, with training and documentation produced, and a data model defined for data migration activity (more on that later).  This, by definition, means we should switch from agile development to waterfall-style release mode – yes, that means defining user acceptance testing and training plans, plus penetration and performance tests, alongside data migration testing and validation.

The anti-pattern here is “just one more feature” – allowing changes to screens and function to go on past the agreed deadline, eating into other activities.  While we love the agile development phase, and all its flexibility and user focus, at some point we have to stop, change gear, and really make sure that we are ready to release.

Ideally, we would have time during the development phase to consolidate.  We prefer to leave the last development sprint before the release phase for any tidying up, small pieces of user feedback, and to look at any structural improvements that need to be made. That means all user facing features are done before that – and if not, then governance needs to be involved to look at scope and launch date, rather than squeezing the release window.

We also counsel around once every 5-6 sprints at most, that we have a consolidation sprint where we do not add features, but we catch up with feedback and technical debt or restructuring that might be needed.  This also helps take single-purpose features and make them reusable for future projects.

But the lessons here are simple – control the project cadence and be prepared to change gears to ensure a really controlled, successful release – and this means being ruthless with deciding what’s essential versus what improvements can be kept for later.

Trying to Solve Everything with One Platform

When all you have is a hammer, everything looks like a nail.

Never was a truer word spoken than when you invest in a massively capable development platform like OutSystems.

But the reality of it is, that no solution exists in isolation.  From the basics like email and SMS integration to location and map services, and then integration with the rest of the application and desktop infrastructure, there is a range of internal and external components that need to be connected to complete your architecture picture.  Some common options we see are:

  1. Identity – early on a single sign-on solution is seen as desirable but frequently overlooked. But at least the authentication should be integrated with Active Directory, Okta, or another provider.  It’s worth putting the effort in early on to get this done, as there will never be a good time to switch over.
  2. Data Warehouse / Analytics – whilst we love a good dashboard view in OutSystems, that’s probably best for the operational reporting, and the day-to-day. In customers where we’ve had the option to connect to a separate data tool by exposing APIs, we’ve been able to tap into a different skill set and a different view when it comes to progress reporting, benefits realisation, and even help troubleshoot potential data errors.
  3. API Management – either Integration PaaS options like Boomi or Workato, or Azure / AWS / GCP API management tools – with public sector customers, something is normally required to help manage traffic through a firewall and connect to on-premise solutions from a cloud-hosted instance.
  4. SaaS options – the world is well connected now, and many things have leading SaaS options that are just easy for the end user to consume – think about email & SMS (e.g. Twilio, or UK’s Gov.Notify solution). Maps, location, and distance calculation – Google / Bing Maps, ArcGIS.  Document storage if needed (we often keep ours as binary content in the database).  It’s often worth leaving a budget for these at the start to help MVP, and if you want to improve later, well, there’s a clear cost-benefit for that.

Hopefully these come up naturally in a discovery or architecture conversation at the project scoping stage.  But even if you bootstrapped a standalone MVP, at some point it’s worth opening the door to see where your low-code applications fit with the rest of the stack. Talk to our experts today about our OutSystems software solutions.

About our OutSystems’ Experience

Version 1 is proud to be an OutSystems Partner. As a long-term market leader, OutSystems are focused on constantly improving the developer experience and platform operation. This allows partners like Version 1 to focus on our customers’ needs and experiences – helping them achieve a faster ROI, and getting through more of the digital transformation backlog, with leaner, more effective teams.

News & Insights