Where can I listen to this podcast?

This podcast is available on 4 platforms including Apple Podcasts, Spotify, and more. You can also use the RSS feed directly.

Does this podcast accept guests?

No, this podcast does not typically feature guests.

Architect Tips

Claim This Podcast

by Jeffrey Palermo

5.0(1 reviews)

9 episodes

Updated Daily

Accepts GuestsHas SponsorsLocation 🇺🇸

Podcast Overview

Architect Tips by Clear Measure Created to help .NET development teams move fast, deliver quality, and run their systems with confidence. This series is led by Chief Architect Jeffrey Palermo as well as other Clear Measure team members, publishing short clips of helpful tips to empower you to achieve more! Visit www.clearmeasure.com to view other content and learn more.

Language

🇺🇲

Publishing Since

10/26/2020

Visit Website View on Apple Podcasts RSS Feed

1 verified contact email on file for Architect Tips

Pitch yourself as a guest, propose sponsorships, or reach out directly to the host.

See contact details

Recent Episodes

August 17, 2021

Architect Tip: What is Technical Debt?

<h1>Architect Tip: What is Technical Debt?</h1> Welcome to Architect Tips presented by Clear Measure, a software architecture company. Empowering .NET development teams to be self-sufficient, able to move fast, deliver quality, and run their software systems with confidence. Make sure to subscribe on YouTube or your video podcast feed. If you have a question for the show, send them to ArchitectTips@Clear-Measure.com and the next tip could be yours! What is Technical Debt? Now we all want to move fast and deliver consistent quality and run our software in production with confidence knowing that everything works and we won't be surprised by bugs getting through. And at this point, if you haven't been paying attention to the podcast, we sponsor the Azure DevOps podcast, then check that out and specifically, listen to Episode 150 with Capers Jones. I highly encourage you to do so. Capers is probably the most prolific publisher of research in the software industry, and his research shows quality precedes productivity. And if you want your team to go fast and you focus on that, then your quality is likely to suffer. You won't go fast at all. It's an interesting dynamic, in an attempt to move fast. You may skip some automated test cases or push something out without fully thinking through all the aspects of the design and then when a production bug happens, a developer stops working on a feature and spends time fixing the bug. And in this instance, we discovered new work. We've known about new work that had to instantly move to the top of the priority list pushing back, other prioritized feature work and it's very likely that the developer loses half a day or more fixing the bug. And then there's more pressure after that to finish the feature. And if that feature doesn't have a complete design or complete level of automated testing coverage, then a bug in it will surface at some point soon. Repeating the cycle and on aggregate, the discovery of bugs and the efforts to fix them can end up consuming a lot of development time. And from the outside of the team, it can appear that development doesn't move very fast. But in reality, the development of new features people are waiting on move pretty quickly. They can be pretty simple features. But because of the quality issues, the remaining development capacity left in the week to actually work on new features is not a full-time effort. It could be a fraction of the development week. The point at which all development time in a week is used to fix existing defects or we're not working on developing new features at all. We're just fixing things that broke that is complete development bankruptcy, where were sunk. Now, some people call this Dynamic Technical debt, and it's called this to invoke the metaphor of interest payments on a credit card. If my paycheck is $4,000 per month and I pay $100 per month to pay the interest that has accrued on a credit card on the amount that I've charged, then I can keep going and manage that because I have $3,900 per month left of available cash and pay other expenses, whatnot. But if I continue spending above my means and charging it to a credit card, then there will come a time when I'm paying all of my money that I have every month just to pay the interest on the rather large balance. And at this points its all over a cliff, my margin for adjusting my r recovery is gone. I can't pay it down. I just don't have the means. So technical debt in software is in complete design and sufficient automated test coverage. You could think that hey, I paid for a feature or your business partners or customers paid for a feature and development. We pay for a feature by working on it, spending time on it. If I pay for a feature, but if I only pay for some of it, then the rest is technical debt. And so the rest of it I put on the charge account to be paid in the future and in the future when a bug surfaces because of an incomplete design or insufficient test coverage. I’lll have to pay down that debt and likely when I have no automated test covering all the paths. I'm going to slip through and I'm going to have to pay down that debt at that point of payment. Of course, in this scenario, all in the form of time. And anyone who's been doing development for some time has experienced situations, where they have their week, all planned out nicely. Feature A we will chip on Tuesday, feature B well chip on Friday. And then in comes a bug surprise. Now, your schedule is hosed. You can try to explain why Feature A or B, didn't make it in time. But what will you say? Some gremlin got into the code and broke something. It's not my fault when it comes down to it. The only truthful thing to say is that either a previous design was incomplete or I didn't cover all the behavior paths with tests to prove them. Either way I told you, a feature was complete last week or a few weeks back and now we can see that the feature wasn't complete. And now I have to work more to finish the work that I had previously reported as finished. So that is what people talk about. When talking about technical debt, it's work that we should have done, but we put it on the charge account and it's going to come back to us at some point. So I hope this helps. Stay tuned for more tech tips and keep shipping. Thanks for watching Architect Tips. If you would like help improving your team speed, quality, or software stability, send us a note to <a href= "mailto:ArchitectTips@Clear-Measure.com">ArchitectTips@Clear-Measure.com</a>. On

April 13, 2021

Architect Tip: How Often to Deploy to Production

How often should you be deploying your software to production? Welcome to Architect Tips, presented by Clear Measure, a software Architecture company, empowering .NET development teams to be self-sufficient, able to move fast, deliver quality and run their software systems with confidence. Make sure to subscribe on YouTube or your video podcast feed. If you have a question for the show, send them to architecttips@Clear-measure.com and the next tip could be yours. <pre> </pre> Welcome to Architect Tips. I'm Jeffrey Palermo and today we're going to talk about how often to deploy to production. And if you have a question for Architect Tips, send it to architecttips@clear-measure.com and from those submitted, we will pick a question. And if I can put it in to a short five-minute bite-size chunks, I'll do it. Otherwise, I’ll just send you an e-mail and answer it for you. So how often should you be deploying your custom .NET software applications to production no matter the size of the software or individual chunks? Let’s dig into that and you're going to answer the question for yourself, but it's going to depend on a number of factors. The first one and foremost is the pace of your business. And if your business needs to give new things to customers once every three months. Well, then deploying to production... The minimum to deploy to production is once every three months. If your business needs to roll out changes to customers every week or even every day, then that's the slam dunk answer. Now, let's suppose that your business doesn't really intentionally roll things out to customers, but every few months you are still making improvements to the software, you're increasing the quality of your telemetry. You're making it run faster, you're making it scale better on fewer server resources and so you'll still be doing production deployments even if you're not actually giving anything to the customers and so the answer is you need to deploy at least as fast as your business moves and faster for other scenarios. Now let's back up from that question and talk about the pace of your testing because if you are testing performance, improvements or stability improvements, well that's also going to determine the frequency at which you deploy. Even if you give, let's say, product management the button to press to production and say, hey look, build such and such as ready for production. As soon as you press that button, it's going to go. If you're ready, and they're never waiting on engineering, that's success. Product management should never be waiting on engineering, engineering should be waiting on product management. Whatever form that takes in your company, whether it's Joe next door or whether you are in a larger organization with more formalized product management. But the pace of your testing can determine how often you deploy to a pre-production testing environment because every DevOps environment has three categories of environments. The first is production, everybody has at least one of those. Next is a manual test environment. You need at least one of those, a lot of organizations have many of those, that's one category. The third category is automated test environments or test automation environments. I like to call those environments The TDD environment to invoke test-driven development so you have three categories of testing. Now the pace of your development is also going to impact how often you would deploy, not only to production but to test and your test automation environment and that the raw ability to deploy quickly comes back to how you do code branching, and if you are doing branches that live for days and weeks on end, you're not going to be able to do production deployments on any kind of frequency. So you need to have every individual change beyond its own short-lived branch. And when I say every change, if you're changing the way a button operates, that’s a branch. If you are adding a new screen, that's a branch. If you're adding a new field to an existing screen that also adds a corresponding column field to a database table, that's a branch and no branches should live more than two days. Every branch should be targeted to live one day. Something that I can get done in one day and oh two days, That's my fallback. Okay, maybe it does take me two days but if you have a branch open for three days and four days and five days; that means that either it was too much work or we didn't understand the design that we are going for, and I didn't really have a plan for implementing it or something else came up. Some new information I learned. And now I've learned it's more of an effort than I thought it was. So the size of the branch is going to make a difference. Now, here's another related question. How do we know if we're okay to deploy? Oh, we can hit the button and press to the point. Now I'm assuming you have automated deployments we can come back later but how do I know we’re okay to deploy when it comes back to quality in our pipeline. You know, invokes the metaphor of water...you want the water to be clean in the pipeline. You don't like to be dirty everywhere and then attempt to fill through at the end. So these are DevOps questions. Your pipeline should be able to answer for us. Is the change that I just made okay to share with my team? Well, that gets answered by the private build. That's the first tier in continuous integration. Does my change play well with other changes, other code changes elsewhere on my team? That's the integration build. The second tier of continuous integration and then third, does this release candidate, does this build that has been produced with all of our changes on the team, Does it still deploy? Does it still startup? Does it still generally function? Well, that is the answer of the third phase of continuous integration, which is that first deployment to the TDD environment or the test automation environment, where no humans really go. It's just to vet the release candidate. And then, as we get further down the line, if the TDD environment and in the acceptance test Suite, that runs their passes. Well, now we know, we're okay to share with stakeholders or product management testers. Whoever we give it, give that bill to beyond the engineering team and then finally, if they run it through its paces and they don't find any issues well now it's okay to share with the customers and so those are our answers as to whether it is okay to deploy to production. Whether we're okay to deploy to a test environment and whether okay to even share a branch with our team. So I hope that helps. And as always, if you need any architecture help, at Clear Measure we’re a software architecture company, we exist to help you move fast, deliver quality and run your systems with confidence. We want you to be able to do more internally so that you and your team can perform at another level and you're more than capable to deliver for your customers and to deliver her to your company, which is fantastic. Thanks for now. <pre> </pre> Thanks for watching Architect tips. If you would like help improving your team speed, quality, or software stability. Send us a note to architecttips@Clear-measure.com on behalf of everyone at Clear Measure. Thanks for watching and may God bless you.

February 2, 2021

Architect Tip: Testing Polymorphic EFCore Mapping

Welcome to Architect Tips presented by Clear Measure, a software architecture company. Empowering .NET development teams to be self-sufficient, able to move fast, deliver quality, and run their software systems with confidence. Make sure to subscribe on YouTube or your video podcast feed. If you have a question for the show, send them to architecttips@Clear-measure.com and the next tip could be yours. Howdy! Welcome to Architect Tips. Today I want to talk about strategies for writing and maintaining automated tests for object-relational mapping whenever you have a hierarchy that you have mapped. And so on the screen, I have a sample just from a car auction, a car auction application, where we have an auction entry, but then we have three different types of entries. In an auction, things are typically called a lot. And if you're selling that, that sweet Chevrolet Corvette will be lot number such and such. And so you have competitive Lot, C of Consortium Lots, where multiple people can go in by organizations and you have an add-on only lot for donations, but they all derive from auction injury. So, in the code, you would see that a derived type lot would inherit from auction entering, okay? Well, what about your mapping? This is Entity framework and entity framework core or just entity framework and .NET 5 as well. And so, we're going to go to all auction injury map. We use this convention for every type of map, an aggregate root in domain design speak. We have an actual class so that the mappings don't get out of control and you want to be able to have a class per map. And if I go over to my data context, you can see that we have a method here that just kind of lists all of them and we can control the schema and in some cases, you want to put them in a different schema. That's just an aside but an auction entry, we've inherited, we've established it as table per hierarchy. So we've added a discriminator, okay, that's great. Just follow the documentation and in, in our code, we can find Consortium lot map and we can see that here, we have declared that our base type is auction injury. Although, even if you don't put that there, any framework, kind of figures it out. And this is our discriminator, it's only in the database, it's not in the object model and this derived type has an additional property in additional collection that are not on the base type. And so likewise we can go to another, the competitive lot. We can also go to the, I add normally lot allow the donation that basically stays the same. There's no differences just yet. Although, this will grow. But over in our test, that's where it gets interesting. So I'm actually going to go to auction entry mapping tester and control F12. Notice that I have six different tests and over in Consortium, lot mapping tester only have two tests. However, because Consortium lot is at entry that means that all of the different queries and all of the different persistence and rehydration scenarios that work on auction entry should work for Consortium lot. So I have to duplicate those tests, the answer is no and this is how. So in our auctions remapping tester, we all we do is we take all of the tests that create an auction entry and instead we factor that out. We extract that as a method that returns auction entry and we market virtual. That gives us the ability to add some polymorphism given that our mapping is polymorphic when they are tests to be polymorphic as well. So we're going to do here, Control Alt B, we're going to look at derive types, and you can see that I have a mapping tester class for each of the drive types. And so if I look at Consortium lot, mapping tester, it, in fact, does inherit it overrides create auction entry and the usages of this are not found in this file. They're used in the base file. And so then we only have to actually have two more tests. Now, if I run it, my shortcut key. Alt Up and I run it, control TR. Let's let this run. And look, I have 11 tests for Consortium. Lot, mapping tester. Why? Well, it's because I have the two tests that are here, too. Plus, I have the six tests that are here. That's eight. But, let's go and look down. And a few of these tests have extra test cases. Okay, that brings us up to 11. So make your test fixtures polymorphic, and then all of your derived types, it'll be really easy to make sure that you are keeping to the rules of object-oriented programming and making sure that a drive type is an instance of the base type and we're not accidentally breaking some functionality that worked with the base type because I'll just jump up to bite you when you're using the application. And then there's some weird bug, it's because you're using a derived type that was returned back from query. So I hope this helps and make sure to subscribe to Architect Tips and whatever podcast directory you found us, have a good day. Thanks for watching Architect Tips. If you would like, help improving your team speed quality or software stability. Send us a note to architecttips@Clear-measure.com. On behalf of everyone at Clear measure. Thanks for watching and may God bless you.

9 total episodes available

Deep-dive analytics for Architect Tips

Frequently asked questions

Have a different question and can't find the answer you're looking for? Reach out to our support team by sending us an email and we'll get back to you as soon as we can.

What is Architect Tips?: Architect Tips by Clear Measure Created to help .NET development teams move fast, deliver quality, and run their systems with confidence. This series is led by Chief Architect Jeffrey Palermo as well as other Clear Measure team members, publishing short clips of helpful tips to empower you to achieve more! Visit www.clearmeasure.com to view other content and learn more.
How often does this podcast release new episodes?: This podcast updates daily.
Where can I listen to this podcast?: This podcast is available on 4 platforms including Apple Podcasts, Spotify, and more. You can also use the RSS feed directly.
Does this podcast accept guests?: No, this podcast does not typically feature guests.

Legal Disclaimer

Pod Engine is not affiliated with, endorsed by, or officially connected with any of the podcasts displayed on this platform. We operate independently as a podcast discovery and analytics service.

All podcast artwork, thumbnails, and content displayed on this page are the property of their respective owners and are protected by applicable copyright laws. This includes, but is not limited to, podcast cover art, episode artwork, show descriptions, episode titles, transcripts, audio snippets, and any other content originating from the podcast creators or their licensors.

We display this content under fair use principles and/or implied license for the purpose of podcast discovery, information, and commentary. We make no claim of ownership over any podcast content, artwork, or related materials shown on this platform. All trademarks, service marks, and trade names are the property of their respective owners.

While we strive to ensure all content usage is properly authorized, if you are a rights holder and believe your content is being used inappropriately or without proper authorization, please contact us immediately at hey@podengine.ai for prompt review and appropriate action, which may include content removal or proper attribution.

By accessing and using this platform, you acknowledge and agree to respect all applicable copyright laws and intellectual property rights of content owners. Any unauthorized reproduction, distribution, or commercial use of the content displayed on this platform is strictly prohibited.