Should .NET Developers Stick or Switch to Power Platform?

Neil: [00:00:00] Should .NET developers stick with C# and SQL Server or switch to Power Platform and embrace Power Apps and Dataverse?

Keith Atherton is a proper professional developer who has successfully made the leap from NET to Power Platform. You'll find out how in this episode.

G'day and welcome to Amazing Apps.

I'm your host, Microsoft MVP, Neil Benson. I'm on a mission to help you master agile practices and build amazing apps on the Microsoft Power Platform and Dynamics 365. Amazing Apps is a result of my curiosity and experiments with new ways of building amazing business apps and high performing teams. It's full of advice from my guests and examples from some of my work over the last few years, leading business applications teams and practices.

If you enjoy this episode, head over to https://amazingapps.show for additional resources. You'll also find more episodes of Amazing Apps, as well as videos, free workshops, eBooks, and my online training courses.

Keith Atherton is a developer with over 20 years' experience in object oriented programming to develop business applications in everything from asp.net and Visual Basic to Oracle databases with PL/SQL, C++ and Java, right up to C# and SQL Server.

Along the way, he acquired a sleeve full of Microsoft certifications that would make a Boy Scout jealous, and he's a Microsoft Certified Trainer as well. A couple of years ago, Keith made the switch to Power Apps development on Dataverse and gained his Microsoft MVP award for his thought leadership in the business apps community.

I thought Keith was the perfect person to share the story of a NET developer adopting the Power Platform for building business apps.

And so I asked him about what developers lose and gain using Power Platform compared to developing an app from scratch. He shares the power of rapidly prototyping applications in Power Apps, even compared to wireframing [00:02:00] tools like Balsamiq or Figma.

When should developers use a low code option or write code to meet a requirement?

The value of documenting your own solutions and decisions, even if it's just for your own benefit later.

How Keith thinks about keeping his skills up to date and mastering so many competencies through a weekly learning routine.

And finally, how Keith would love to be able to write C# in the Power Fx editor. Wouldn't that be something?

This is Amazing Apps episode 153. Here's Keith Atherton.

Keith, welcome to Amazing Applications. It's great to have you on the show. How are you doing?

Keith Atherton: I'm doing great. Thanks, Neil. Great to be here.

Neil: I'd love to have you on the show just to talk about your journey. Cause when we met in Las Vegas a few weeks ago, that was actually at the Microsoft Power Platform Conference. I was really interested to hear your story as a professional developer, moving into this wonderful world of low code platform and what that's like.

What have you had to give up? What have you had to gain in order to make that journey a success? We'd love to dive into your story and hear some of those, some of those tales from your recent history.

Keith Atherton: Fantastic. Yeah, that'd be lovely to, to delve into that. Yeah, it was great to meet you in Vegas as well. That was, uh, A wonderful conference, for sure.

I was lucky enough to go to the first one in Orlando, which was brilliant. And I really didn't know too many people at that one, so it was great to get out there and introduce myself and saw some great sessions. This one was a bit different. I've been a bit more active in the community and like yourself, I'd love to go back to Vegas and catch that third one next year as well.

Neil: So tell us a little bit about how you got started with the Power Platform and what you were doing before that. Maybe if we start there, you've been a developer for 20 something years. What was that journey like?

Keith Atherton: Yeah, absolutely. So, I've been a developer for about 23 years and most of that time has been Microsoft Technologies, mostly NET. SQL Server, lots of on prem and lots of, uh, you know, code first or pro code options, depending how people want to phrase that. And so really that was my comfort zone for a long period of time.

And then really about two years ago, I started a new [00:04:00] role and it was a bit of a varied role. It was consultancy and it was whatever the client wanted or what we thought would be a good fit, we'd be pitching. And the first few projects I worked on were using the Power Platform. So it was really, you know, low code, no code, that kind of concept, completely new to me.

I'd done bits of Power BI and, you know, a few things here and there before, but not really delved into it, what are Power Apps? How do you develop them? What does that involve? So yeah, really that, that really involved me kind of going, uh, you know, full in to using a low code, learning about the Power Platform, what the capabilities were.

It was a totally new platform to me. So yeah, it's been a, it's been quite a journey.

Neil: So coming from that kind of on premise world, lots of SQL server and lots of development. You've had to, I guess, write your own things that today we take for granted when we spin up a Dataverse environment and there's, there's a security model there and there's authentication is there and there's tables and, you know, all that kind of indexing and everything's handled for us.

Were you developing all of that kind of engineering and infrastructure work for your applications in the past?

Keith Atherton: Yeah, that's exactly right. And it would almost be the case of, you know, maybe to a fault, always building something from the ground up. You know, there could be things off the shelf, maybe a Dynamics app or, or even SharePoint sometimes, but we, you know, many of the roles that I had were building something from the ground up.

Again, using those technologies, NET, SQL Server, sometimes Oracle, uh, you know, sometimes that's straight outside of the Microsoft ecosystem, uh, you know, use things like Java with Oracle and depending on, you know, what the, uh, the client was using or what that organization that I've worked for was using. So yeah, really, you're absolutely right.

It was often the case of how do we build this from scratch? We'll use SQL Server, we'll create stored procedures, we'll create the indexes that we need, and really do the fine tuning instead of, as you say, rely on the auto tuning that you get with Dataverse and some of the other abstractions that you get with the Power Platform.

So, yeah, I kind of came from that background fully armed to say, right, How do [00:06:00] we build this from scratch? No, no, no, no. You've got a platform that you can build upon.

Neil: Do you feel like now you've given something up because you've, you've got some constraints and some restrictions and, and, uh, there's entitlements and things you get with a platform that you don't have if you're building your own infrastructure, or do you think you've gained more freedom to be able to do more abstracted, higher level work because you're not having to do some of the plumbing?

Keith Atherton: Yeah, that's a good point. My first thought, which was, you know, I've changed since then. When I first started using the Power Platform was that I may have to be giving up some of these skills and thinking I don't really want to lose you know, lose these NET skills because they've been so valuable. And again, you can build so many things.

You can use it with. With Maui, with WinForms, with web, you know, there's so many options. Even the Unity game development engine, uh, which, uh, once upon a time I used to do game development as well. I thought, well, this is so transferable and so powerful as well that I would miss that. But I think during that, um, that learning curve of getting to know the power platform, uh, I realized it wasn't a zero sum game, you know, that I could use it to extend the platform by creating plugins or whether it be PCF components, you know, when they're required, you know, when it's required, it's not always the case. And sometimes it's quite rare in my experience, but when you need them, it's still useful to fall back on those skills. So I found that I could unite that pro code with the low code as well.

So I was actually really pleased and I kind of, uh, you know, took to it more and got more interested when I realized there are options that I can use.

Neil: Tell me about some of the pleasant surprises you found working with the Power Platform. Maybe things you didn't expect and that have worked out really well and maybe some of the things you miss when it comes to custom development on the NET platform.

Keith Atherton: Yeah, I think some of the pleasant surprises were, I think you touched upon before with the security model with Dataverse and many other things that you don't need to build that from [00:08:00] scratch. So there are things that you can get up and running much quicker. And one of the things that appealed to me was being able to create POCs, proof of concepts or prototypes or things very, very quickly.

That if I was to do it from the ground up, even using a JavaScript framework or an ORM tool, you can speed things up and get a pattern of reusability. But I did find with the Power Platform, you can spin something up very quick. Does this work or not?

Even creating UIs when I'm pitching things for clients. I don't need separate wireframing tools. I can actually just mock it up often in a canvas app or a model driven app. And that's going to be close to what the final thing may look, or a lot closer than using Balsamiq or, you know, there's so many great tools. I found that I can actually get closer to what the end result may look like, which can be more appealing for us as well as the client as well.

So yeah, I think things like that were, you know, nice surprises and surprised me as well, getting out of my comfort zone and saying, well, you don't need to build it from the ground up. You don't need to start writing those SQL scripts straight away. You can actually jump in and leverage the platform and plumb things together.

Neil: I remember, using a wireframing tool called Axure RP Pro, I built out all the screens and the forms and the views for CRM 3. 0 and then I transferred them all to CRM 4. 0 and you could have these little annotations on all the widgets on the, on the screen. And then when you could generate either an HTML prototype or a word document and all your annotations came across. So you could have the data type, maximum field length, um, the schema name, the display name for all the, you know, the attributes of the fields on the forms. But man, it was painstaking and it was, you know, pixel perfect design took forever. Uh, and now we can put together a prototype really quickly.

Um, just do it in, you know, in a model driven app or in a canvas app. Like you said, it's come a long way.

Keith Atherton: Yeah, it really has. And I find them all for the good, you know, whether you can use that or use Figma with it or whatever the case may be. Yeah, the fact that I don't need to start from first, almost first principles and [00:10:00] build something from the ground up, uh, it really kind of surprised me because I did think, well, you know, as you say, one thought was moving to that means leaving things behind.

If I'm not doing, and to some respects, if I'm not using NET every day, which I was before, I'm not as maybe current as up to date as I would have been if I was using it every day. But there's only so many hours, so it's kind of picking and choosing the right tools. And I think, yeah, the Power Platform for, you know, for many solutions can be a really good fit.

Neil: One of the challenges I have with a lot of customers who want to exploit all the capability of this low code, no code platform is they, they want us to avoid writing code as much as possible. That's kind of the edict from IT and then the business users have got this crazy requirement that can only be solved with custom code or, um, you've got an option to use, uh, let's say a business rule or JavaScript.

You'll run into a limitation of business rules eventually, and you'll have to write some dirty JavaScript to get something done on the user interface. And now you've got the user interface customization or backend customization in different places. Some of it's in code, some of it's in a flow or some of it's in TypeScript, some of it's in a business rule, and that's just really hard to maintain.

How do you walk that fine line between choosing to do something in code and use a low code component?

Keith Atherton: Yeah, that's a really, it's a really great question because there's a challenge there with, as you say, when you've got something like a plugin or a business rule or different snippets of code here and there, and I even had this going through a bit of a coaching session with someone today new to the Power Platform, um, And she asked it almost the same question saying, when I'm in Visual Studio, you've got all the code files I can search them all and see it all in one go. But when you, as you say, you know, I'm in a, let's say a canvas app, I'm in the editor. Like, oh no, no, you need to click the button, then go to unselect. Then you can see Power Fx. Oh, by the way, there's a plugin that runs under the bonnet as well. And you know, that, that is using C sharp.

So there [00:12:00] is, yeah, you're absolutely right. The principle I go in with is to try and keep it as simple as possible. So it, you know, the less moving parts, the better, if I can do something low code or out of the box and it's fit for purpose, that's awesome.

If you do need something a bit more niche, and I do need some kind of bespoke or custom thing, you know, whether you need to look at a PCF component, some code first component, if it does lend itself to that, Okay, then we go there if we really need to.

And I think it goes back to other IT principles like documenting things really well as well. So if we do have things and they may appear hidden or not appear, as the case may be, but they are in different places or, you know, under the bonnet somewhere or under the hood rather, um, then having that good documentation, being able to know where things are for even me, you know, with a bad memory coming to in six months, you know, how does this feel getting updated?

I can't find out where. But it'd be great to have that logged in and documented so we're to refer to and say, Oh, by the way, there's also this to bear in mind. So yeah, that can be a big help.

Neil: Yeah. So I encourage my teams to document functionality in a wiki as we develop things. Generally, iteratively over a series of sprints, we're continually refining a feature. And so we may add components to it, but I also like to capture not just where things are and how things work, but why, like, why did we choose that option?

We had different options available. We chose this option because we believed it was going to be easier to maintain or cheaper to deploy. So it's answering that question when somebody else picks it up a year from now, I go, what were they thinking? Well, why did

they do it like

that?

Keith Atherton: you make a good point there as well, because I think when you architect or design a solution, it's sometimes great to know, and I did this with game design before, when there's so many moving parts, and it would almost blur into a simulation at some point, which was, okay, the obvious I this problem would be to do this, but here's why I didn't do this.

And sometimes having that reason why not [00:14:00] was a useful thing, rather than, I've come to this again, like, what were you thinking, Keith? Like, you know, you've, you've, you've got three moving parts instead of one. Why did you choose this? But it was a useful thing to say, oh, we tried this, but it didn't work because of this limitation or it wasn't responsive enough or whatever the reason may be.

And that's why we choose this option. So, yeah, I think documentation in all respects is, it really pays dividends.

Neil: So there's other qualities that come with a NET solution. Things like being able to unit test and do regression testing much more easily. There's some great frameworks for automated testing. You've got things like GitHub AI for helping you write the code. Those, some of those tools just aren't there yet in the Power Platform.

Um, Power Fx has come a long way in the last couple of years, but it's, it's, you know, still a relatively immature, it's not even a scripting language, you know, it's a formula, uh, I don't know what, how to characterize it, but we're not quite there with Power Fx. Do you miss some of those, professional developer capabilities when you're working with the Power Platform?

Keith Atherton: You're asking the tough, tough questions now, Neil. Uh, yeah, you, you, you're absolutely right. I think Power Fx being a declarative language, quite macro like or script like, you know, there are certain limitations. Luckily, there are good investments. We see things like user defined functions on the way. Uh, things like, you know, named formulas and a few other things in the pipeline or in preview.

So I think there are capabilities, but I agree. I think. When you compare it to fully OO language, like, like .NET or C++, i, it, it's totally different. It really is totally different. And I, I think that's when there's extensions, like PCFs or even leveraging something, you know, something hosted in Azure and you are using a proco code first option, maybe they can be architected and work, work well together.

Um, there are some things I find you, you know, there, there is much more power in some OO languages. But again, it's the right tool for the job. You know, when you're in Excel, when you're in, you know, uh, you know, in a canvas app, when using Power Fx, there are certain capabilities and [00:16:00] selfishly, when I was first learning about the Power Platform, part of the fun was being able to work within these constraints to make it do what I wanted it to do.

And so it's like solving a puzzle with some new tools and having that bit of a challenge of all. How are you going to do this? Because you've only got this, you can't create an interface, you can't use these design patterns within coding, but how can you do it within Power Fx, which is not some big clunky mess, you know, how can it be elegant as well?

And I think that kind of taking that challenge uh, helped, uh, you know, uh, capture my interest and I was part of a new learning curve when I started it. So, uh, so far, so good, but I imagine there will be times I'll start hitting that ceiling and I need to maybe look at some pro code options.

Neil: It also depends on what flavor of applications you're building. You can use Power Platform and build applications that are personal productivity or team productivity applications. My teams tend to build applications for enterprises where there's dozens or hundreds, thousands of users.

And it's some kind of mission critical business application that's driving the whole enterprise. In which case we are probably more open to using pro code solutions. We might need the scalability or the monitoring capability it comes with, with function, uh, apps or with logic apps. Um, whereas, uh, at the other end of the spectrum, you might be happy with a, a power automate flow and some of the, the simple kind of monitoring capabilities that come with that.

So it really does depend on, you know, what, what your flavor is and, uh, how much you need to invest.

Keith Atherton: Yeah, totally agree. I think, yeah, back to, you know, the right tool for the job, as you say. How do you need to scale? Are you looking at, app service with replicas and you scale out and it has that full capability? Can it be handled within a, within a Power App, and I think, using Dataverse as the backend, pros and cons, you know, you can get direct to Dataverse, you've got less layers when you, when you contact it. But then again, you may have to rely on auto tuning and you can't do the same kind of indexing or things you may do if you did a stored procedure in SQL Server.

So again, [00:18:00] I think, uh, some things for that can be useful is, you know, creating that test data to kind of mimic the volume of data that a production environment may have and seeing, does this scale? Does this work? Is this fit for purpose? But you're right, I think there are so many factors and so many options to take into account, for sure.

Neil: Keith, one of the things I get a sense of from your journey is you've got this wealth of experience as a professional developer. You've picked up the Power Platform. It seems like just a few years. Now you've got LinkedIn learning courses that you're delivering, teaching other people how to learn the Power Platform.

You must have a rare talent for picking up new technologies. You dropped the fact that you've, you've dabbled with, uh, Oracle databases and with Java, uh, as well as a number of different, other object oriented languages. How do you do it? How do you keep your skills up to date and learn so much new stuff so quickly?

Keith Atherton: Yeah, well, thanks for the kind words. Uh, you've, uh, yep, you've certainly done your research. Uh, that's a great question because I sometimes ask myself the same thing. You know, there's only so many hours in a day. I do like learning new things. So a big part of the passion is learning new things and being adaptable.

And I think working in in consultancy, you know, I'm sure you're exactly the same, Neil, and your team is, being adaptable. And sometimes, one week I'm using Azure, the next Power Platform, which is really built on Azure anyway. The next could be NET. The next could be MySQL hosted in a Linux VM.

So I think being able to just hop around things. Two weeks ago I was using the Azure OpenAI and that's a lot of fun to play with. But I'm aware many of these other things, let's say I've got two verticals. For me, it'd be Power Platform and then NET, there's a fair bit of Azure as well.

But I tell you, those are the two verticals for me. And I try and have a broad base. I do have all the fundamentals, the Microsoft fundamentals. Just when I consult or get asked a question, I know enough to be dangerous. I'm not winging it. I do know the basics. I'm able to take part in the conversations.

And then when I do need to dig deeper, again, I won't wig it. I'll go ahead and do the [00:20:00] research and then I'll need to, you know, delve into the parts that I need or work with the experts who do, do know those skills inside out. But for me, I do like learning new things and that's just part of my weekly routine.

I certainly make a lot of time for it and that, that is, a luxury that I do have that time to spend on learning new things, reading blogs, taking courses, and sometimes knowing enough to create my own course for it as well, like the LinkedIn courses.

Neil: A lot of people will say, Oh, I haven't just, I just haven't had time to learn that, that new technology. Whereas you're making time, you, you sounds like you carve it out in your calendar and dedicate some of your focus on it. So that's, that's a really admirable trait.

I wish I did more of that myself.

Keith Atherton: Thank you. Again, only so many hours that it is. It's tricky because sometimes I go through a phase where really, as you say, the time management is key. I can put lots of time in. Sometimes the balance isn't right, and I totally recognize as well that only more one way. And then when I was creating the most recent LinkedIn learning course, which was PL 400 certification prep, which is Power Platform developer.

Again, I've been lucky enough to leverage that Pro Code experience for a few, you know, for many years, as well as the recent years of Power Platform, and bring those two together. So I was, I was kind of quite well suited there, that landed quite right. But when I was creating that course with the help of LinkedIn and working on a few other things, taking other exams as well, I did realize that was a very busy time, and now I need a quiet time just to kind of restore that balance.

That's an ongoing quest. I'm still working on that.

Neil: So you go through seasons in your life, don't we? And there's, you know, kids are busy at school or things are crazy busy at work. And then it quietens down a little bit and you find yourself in a couple of months where you've just got the ability to pick up some of those training courses you've been to do or some of the books you wanted to read.

Exactly.

Keith Atherton: It's just, you know, getting that, that breathing space and kind of, yeah, trying to not take too much on, but, you know, when it's the right level, that's for sure.

Neil: Imagine somebody is listening to this podcast or they're watching us on YouTube and they say, right, I'm a, I'm a C# developer. I've heard about this Power Platform thing. [00:22:00] I want to find out more about it. What's, what's a good first resource, a training course, or a place that somebody can dive in and take those .NET skills and transfer them over onto the Power Platform.

Where would you recommend they start?

Keith Atherton: Yeah, that's a good one. I think often studying for the PL 900, uh, and there's no plug here. I've not created a course for that one yet.

Neil: Yet.

Keith Atherton: Yeah.

Yeah.

Neil: heard you.

Keith Atherton: Yeah, that's right. Watch this space. Um, yeah, I think, uh, yeah, the, the Power Platform Fundamentals, uh, is, is a really good place because it, it was good to give me a good, solid overview of what the capabilities were and what it was.

So when I was tasked with working on Power Apps for the first time, I didn't really know what they were. I didn't know that you would do development with Power Platform. I'm using an editor, but in the browser, I was like, okay, what do I install? What client app do I install? Yeah, I'm just so used to doing that.

So when I, when I took the PL 900 and just went through Microsoft Learn, great free resource, good for when you prepare for exams, it really gave me the overview of the main services of the platform. What they can do. And then it did touch upon very lightly the overview of here are some pro code options.

Here's how you can extend it. Here's why it's built on on Azure and you can tap into that Azure layer if you need to. And here's what you can do with it.

There was also a good resource on, I think it was Microsoft Learn again about architecture examples. Uh, ones there, there are many on there with, uh, for Azure examples, the way you can do load balancing or host web apps and so on, but ways that they can cross over with other platforms such as the Power Platform or such as other parts of the Microsoft ecosystem.

So sometimes that was eyeopening to say, well, you can have this Azure solution, but you can also have the charts but they're Power BI. Or you could have, uh, a Power App, but you can still use AppInsights if you want to look into some of those metrics and see how it's being used. So sometimes that gentle overlap can be ways, okay, I can start touching up on both and see how it works together.

So I think, yeah, [00:24:00] PL900 using Microsoft Learn is probably a good first port of call.

Neil: Awesome.

Imagine you had a magic wand and, um, let's say Microsoft, uh, folks in Redmond said, Keith, we're going to give you whatever feature you'd like next on the roadmap. What is it that professional developers are crying out for in the Power Platform they haven't got yet that you would love Microsoft to build for you?

Keith Atherton: Let's see if I was drunk on power and I could have any change. Let me see. You know, I can speak for myself. I don't know about other pro Developers. I do know some, but I, I dunno what they're, they're looking for. But I know for me, a a and this almost, it's almost, um, a bit of a paradox because we talked about Power Fx being a declarative language and quite macro like, or script like.

I really like things like C#, C++ and things that have the full power of OO. So it's counterintuitive, but if the Power Fx was able to use an OO language, like C Sharp, directly in the Power

App.

Neil: Wow.

Keith Atherton: Would give full power, but it does go against the low code mindset, but also there are so many factors involved because I know that it would really restrict options for, let's say, handing over a low code solution to a client where they want to run with it and maintain it and extend it going forward using low code skills because, you know, let's face it, a lot of the Low code citizen makers who are new to this, they bring a lot more skills than I do in terms of the business and domain knowledge that they have that I'd love to have.

But I do have the ProCode options, which are useful, in other ways as well. So I do realize that if you were to use C sharp directly, it could very well alienate many citizen makers. But again, if you could pick and choose the places it would be used, so you wouldn't always have to create some external PCF component that you need to import in there.

Something you could directly integrate when it's used well and used in the right place, that might be a nice option.

Neil: Yeah, that's a, that's a fascinating idea. So would you still [00:26:00] use the, the browser editor to, to write, C sharp or, or would you still, would you have Visual Studio somehow hook into, you know, the formula bar? I don't know how that would work. It'd be fascinating little project to mess around with.

Keith Atherton: That would be good actually. Yeah. Something like Visual Studio or Visual Studio Code. Again, I would imagine many pro coders where they have the background that would be more of a gateway into using it as well, because that's a familiar environment, a familiar IDE that they could use to use with it. But again, I'm kind of asking for the moon on a stick because I kind of want both here, you know, I want, I want the Power Fx for citizen makers, and also for my own use for, you know, for simple things for them, calling patch or I'm using collections.

I don't always want to go and use the full power of an OO language, but I do recognize there are times when, hey, wouldn't that be nice if I could just call this and not have to create some complete custom PCF or go to AppSource or go to somewhere to kind of get this third party one or, hey, there's this cool thing someone put on GitHub, I think, for months ago let me see if I can find it. I just want to spin it up myself right now.

Neil: Yeah. Very cool. Awesome. That's a nice little thought exercise to leave the audience with, Keith. Just before we go, is there a site or a blog or anything that people should check out if they want to get in touch and find out more about your work and what you've done. We'll make sure we've got links to your LinkedIn profile and things in the show notes, anywhere else you'd like to direct people so you can find out more about your work.

Keith Atherton: Yeah, thanks Neil. Yeah, I'm always happy to help if anyone has questions or want to get started. You know, so many great people help me too. I'm always happy to help others. But yeah, I think you mentioned LinkedIn and Twitter, or X now, really the two places I'm most active and yeah, I'm always happy to help.

Just feel free to connect with me on those.

Neil: Awesome. Keith, thanks so much. Great to speak to you.

Keith Atherton: My pleasure. Thanks so much, Neil.

Neil: Thanks for listening. I hope you enjoyed this Amazing Apps episode and find it useful. If you did, please consider leaving a review on Apple Podcasts or Spotify.

Reviews help other like minded apps [00:28:00] builders like you find this podcast and grow our community. Until next time, keep experimenting.