Loading...

Software development is a decathlon (and low-code only gives you running shoes for two events)

Software development is a decathlon (and low-code only gives you running shoes for two events)

Software development is a decathlon (and low-code only gives you running shoes for two events)

Building apps with Power Apps feels easy. Drag some controls onto a canvas, connect to a SharePoint List, throw in a few formulas — ta-da! A working prototype.

Except… that’s not the race. That’s the warm-up.

Shipping real apps (you know, the ones that solve real problems, scale beyond one user, and don’t fall apart next month) is more like a decathlon. You’re not just doing one thing well; you’re juggling ten disciplines at once. And low-code helps with maybe two or three.

The real decathlon of software delivery

Here’s what it actually takes:

  1. Requirement engineering Translating vague requests like “can you make it more user-friendly?” into testable, buildable, traceable features

  2. Problem solving & edge case hunting Understanding the business logic behind the button, not just placing the button

  3. Logical thinking & pattern recognition Building once, reusing often; not repeating the same formula across 27 controls

  4. Syntax fluency Whether it’s Power Fx, JavaScript, or a flow expression; your logic still has to make sense, and perform

  5. Data modeling Designing structures that can scale, not storing everything in one flat SharePoint list with 200 columns

  6. UI/UX & accessibility Not just “looks fine on my screen”, but intuitive, inclusive, and mobile-friendly

  7. Testing & quality assurance Writing clear test cases, automating where possible, and validating edge scenarios, not just hoping

  8. Documentation & supportability If no one else can understand, update, or fix your app six months from now, it’s not a product; it’s a liability

  9. Integration & maintainability Connecting systems in a way that survives password changes, API limits, and platform updates

  10. Lifecycle management & accountability Versioning, auditing, knowing who owns what, and not deploying straight to production from someone’s trial environment

drowning child meme

What Power Apps made easier

To be fair, low-code did remove some friction:

  • You can sketch out a UI fast
  • You can connect to data without writing custom code
  • You can build logic with Power Fx instead of full-stack frameworks

These are real advantages, especially for business users and prototyping. But let’s not kid ourselves. (at least not when nobody from MS is listening)

What’s still hard (and still matters)

  • You still have to do requirement engineering, even if the stakeholder is standing next to you.
  • You still need testing and documentation, especially when multiple people build on the same solution.
  • You still need to care about supportability, ownership, and accountability, because “the person who built it left the company” is not a great helpdesk answer.

And all those apps? They need to be maintainable and reusable, not a pile of one-offs duct-taped together in someone’s personal environment.

Low-code doesn’t remove complexity. It just delays it.

And unless you’ve trained for the full decathlon, it’ll hit you in production.

Fusion teams win races

Power Apps shines when it’s part of a fusion team setup: business experts, pro devs, testers, IT, ops, all pulling in the same direction. It’s not about replacing developers. It’s about speeding up delivery without compromising on the fundamentals: clarity, quality, accountability. Because building fast isn’t the point. Building well, fast: that’s the win.

Final lap: Know what race you’re in

Low-code is powerful. But it’s not a shortcut to quality. If you only train for the “fun” parts — the visual design, the first-click wow moment — you’ll be in trouble by lap three. The real work is the rest of the decathlon: Requirements. Testing. Ownership. Reusability. The things that make software work long after the demo ends. So yes; lace up those low-code running shoes. But don’t skip leg day. You’re still in the full race.

Published on:

Learn more
Need help with this product?

We can help you with Software development is a decathlon (and low-code only gives you running shoes for two events)

If you want help implementing, troubleshooting, or improving this product, contact us and we’ll point you in the right direction.

Luise Freese: Consultant & MVP
Luise Freese: Consultant & MVP

Recent content on Luise Freese: Consultant & MVP

Share post:

Related posts

You are holding GitHub Copilot Wrong!

Most developers think that one can’t really use GitHub Copilot wrong. There is a chat interface that lets you also choose a model, so th...

8 months ago

You are holding GitHub Copilot Wrong!

Part 0 showed why constant prompting, re-prompting, and steering GitHub Copilot feels fragile. Not because Copilot is unreliable, but because ...

8 months ago

Building a Multi-Hierarchy Ticket Classification System (Because Keywords Aren't Enough)

Look, I love a good keyword-based system as much as the next developer. They’re fast, predictable, and when your user says “VPN,&r...

9 months ago

Secretless cross-tenant dataverse access

Client secrets are like hiding your house key under the mat; easy to grab and impossible to audit. Certificates are just slightly better, beca...

10 months ago

How Azure CLI handles your tokens and what you might be ignoring

Running az login feels like magic. A browser pops up, you pick an account, and from then on, everything just works. No more passwords, no more...

10 months ago

How Dev Proxy teaches you to make your apps more resilient

I added Microsoft Dev Proxy to my Mermaid → Dataverse converter, because I wanted to test how it handled rate limits and API errors. What I go...

11 months ago

Building Azure functions that never store secrets — ever

What if your function could hit Microsoft Graph with no client secrets, no certs, and no Key Vault entries? That is exactly what a Managed id...

11 months ago

Introducing Mermaid to Dataverse Converter

Why diagrams matter (and why they usually fail us) Entity-Relationship Diagrams (ERDs) are the universal shorthand for talking about data mode...

12 months ago

It’s OK to be seen trying

It’s OK to be seen trying Somewhere along the way, we started believing that you’re only allowed to speak after you’ve figured everything out....

1 year ago

Stuck in pilot - Part 1: no foundations, no future

“We just need to test the AI. We’ll figure out the data later.” That sentence has quietly killed more AI pilots than any model failure ever ...

1 year ago

Newsletter

Get the latest Dynamics 365 and Power Platform content in your inbox

A curated digest of community blogs, product news, videos, and podcasts — delivered without the noise.

Weekly updates Unsubscribe anytime Fresh community picks
We use your email only for the newsletter and you can unsubscribe at any time.
By subscribing, you agree to the privacy policy.