Build Vs Buy: The Age-Old Dev Debate - Dev Leader Weekly 51

TL; DR:

• The Dev Leader Podcast is now LIVE !
• Dometrain course summer sale!
• Your goals for learning are different than business decisions
• Catch the stream for this article and Reddit post reviews July 8th 9:00 PM PDT

Discounted DotNet Courses!

Head on over to Dometrain and get discounted DotNet and C# courses ! There are many other amazing authors — not just courses from me!

Exclusive Article: Build vs Buy With a Twist!

- - - - History Lesson - - - -

A long time ago in a galaxy far, far away… Software developers have been faced with the decision of build vs buy since the dawn of software engineering. It’s a great example of the “engineering” aspect of software engineering because this kind of decision:

• Has constraints
• Requires some analysis
• Involves weighing the pros and cons

When we’re working for companies and shipping products and services to customers, the constraints and the weight that we assign in our analysis will look a certain way. Often this will be heavily focused on how to get more value to customers and minimize the costs that the business might incur.

But even from business team to team, org to org, and company to company… this won’t look exactly the same. A big company might have the capital to pay for something they have no desire to build themselves because it’s not their core business. However, they might decide that they need such heavy customization to existing offerings that it does make sense to create their own.

Conversely, small companies might not have the capital to pay for the best solutions available. They might still find it more economical to pay for something off-the-shelf because it wouldn’t be feasible to stretch the team to build something in-house. But the context will drive those decisions.

But I promised a twist on all of this.

- - - - The Twist - - - -

What happens if we compare what businesses want to do with what we should focus on when we’re learning? Do we have the same goals when we’re learning as a company would have?

I’d argue very strongly: no.

At least, most of the time. And that’s because when we’re learning a programming language, tech stack, library, design pattern, or architecture, we’re deprioritizing selling to customers. That might be a longer-term goal of yours, but especially for newer developers or individuals just hoping to skill up on the side outside of work: turn your attention to learning over selling a service.

I’ve collected a list of some things that I spent time building over the last 21+ years of my programming career. I’ll explain what I was learning and how the build vs buy decision may look different at work.

- - - - JSON (De)Serialization - - - -

One of the earlier things I worked on for my side projects was building logic that could serialize and deserialize objects to JSON. And actually, it started with XML — but JSON has mostly won the sexiness race so I’ll just shift the focus.

There are TONS of libraries for working with JSON. In C#, we historically had the amazing Newtonsoft JSON package to work with but the built-in JSON serialization has caught up. When I started writing my own serialization logic, it was because I was building a 2D role playing game. I needed a way that I could save and load data that was represented in a hierarchical form.

I’d love to say that I went off to build my own stuff because I had a critical use case and I weighed my other options — but I’d be lying. I just dove into writing my own because I was doing this with most things at the time. I attribute a lot of my learning to it.

Things I learned:

• Reflection! More advanced versions let me “dynamically” serialize and deserialize objects without knowing all of the types ahead of time.
• Basics of parsing
• Working with Strings, Bytes, and Streams in C#

With some planning, things you could learn that I didn’t:

• Performance and benchmarking — bust out BenchmarkDotNet and get right into it !
• Low-allocation or allocation-free code!
• Source generation and Roslyn — if types are known ahead of time, can you get super fancy?

Now, does it make sense for a company to go build its own JSON serialization?

Probably not.

This would probably be a bad move for a company with respect to cost and resources because there are plenty of free open-source JSON serialization libraries (regardless of what language you use). Unless your use case was hyper-specific, I can’t see why as a business you’d need to reinvent the wheel here.

- - - - Network Messaging - - - -

Like any kid trying to learn to program by making games, multi-player was on my mind. After all, once I could show my friends that I could make silly games they’d definitely want to play them, right? …. right?!

Early on in my programming journey, I got started working with sockets. I played around with UDP a bit but for my needs often found that streaming with TCP is what I was after. I made a lot of P2P and client-server style architectures for very basic games and chat functionality.

Things I learned:

• The basics about networking (how can we see each other’s machines?!)
• Building on that serialization topic from before: how to send objects across the wire
• Some basic architectural patterns for P2P, client-server, and state management in these types of systems

With some planning, here are several things you could learn that I didn’t focus on:

• Pick existing tech stacks to compare and contrast
• How to get network connectivity in more complex network topologies
• … dive deeper into understanding networks instead of my surface-level view
• Compare things like streaming data to RPC to more advanced tech stacks like leveraging queues

Most companies REALLY don’t need to invent their own network messaging libraries. We have so many things available today that the bigger question is likely which type of messaging tech is most suitable for the system being built.

I suspect unless your company is trying to revolutionize how network communication is done with a new pattern — it’s probably best to take something off the shelf:

• REST
• gRPC / Protobuf
• Message Queues
• … you name it.

- - - - User Interface Framework - - - -

Many people may not have known this until some of the recent videos I’ve been publishing, but the majority of my programming career was making desktop applications in WinForms and WPF. And that’s in personal projects and professional projects.

I made my very own user interface framework in a technology called XNA — which is essentially a precursor to Unity3D that we have today. It was a C# game engine that provided a lot of the basics, but the user interface support was quite lacking. Because I already had a bunch of experience in WinForms and building desktop apps, I started making my own from the ground up in XNA.

It was awful.

But I learned a lot:

• Actually, I DIDN’T learn just how awful deep inheritance hierarchies were. The shame!
• A deeper understanding of how things like WinForms work
• Lots of focus on geometry and writing code to support 2D geometry, coordinate mapping, etc…

What you could do better:

• Learn how you might serialize and deserialize an entire user interface
• Could you build your own markup language?
• … Could you use a reduced set of an existing markup language (HTML, XAML) and transform that into user interfaces?
• Compare UI frameworks like Avalonia, WinForms, WPF, Maui, etc… so that you understand their strengths and weaknesses

I don’t see a big need for companies to do their own user interface frameworks. An exception might be if you’re working with game engines and want to build a completely custom UI framework for your games — you might want all of the control you can get along with being able to optimize as necessary.

- - - - When Do Companies Roll Their Own? - - - -

You probably noticed the theme across all of these was that most businesses don’t need to roll their own versions of those things. They’re not great candidates.

Here’s a list of some things I’ve seen first-hand companies make their own versions of:

• Software licensing tools. In order to cut down on the initial effort to shop around and integrate something, there was a quicker way to just make it in-house. Long term, this moved to something off-the-shelf because the maintenance costs internally were too great.
• WYSIWYG editor for user interfaces. This is because the system that needed user interfaces built was very domain-specific and the customers needed to make their own screens.
• Markup and annotation tools. This situation required drawing over a custom highly-secure rendering of PDF documents. We also needed to serialize our data in the format we defined.
• Remote agent for managing files and remote diagnostics. The domain for this was extremely specific so using anything off the shelf would be very limiting for customization. Every little detail needed to be controlled.
• Report creation. This is a common one where I’ve seen companies shop around for some options. Sometimes the options are “good enough” and other times there’s so much to be desired that companies bite the bullet and make their own.

- - - - Takeaways - - - -

At the end of the day, businesses must make decisions given the current scenario that they’re in. There a lot of variables to factor in and those will affect the constraints that a company has to make. Is it a short-term solution to let us keep moving? Do we need to maintain this thing forever? Do we have a migration strategy for later?

Tons of things to factor in.

However, for you as the individual trying to learn… I highly recommend you spend some time re-inventing the wheel. You’ll have such a better appreciation of the libraries you use AND you’ll learn a tremendous amount.

• Join me and other software engineers in the private Discord community !
• All of my weekly vlogs are now on YouTube which are accessible via membership !
• Remember to check out my courses , including this awesome discounted bundle for C# developers :

Weekly Recap

WPF Value Converter Basics With BooleanToVisibilityConverter

WPF user interfaces are built using XAML with a sprinkling of bindings. We bind control state to and from the state that we have in our view models.

But… What do we do when the types don’t match up perfectly?

One of the most common situations this happens is with boolean state and visibility in WPF. And that’s because visibility is NOT binary state!

… it’s tri-state!

Let’s check out how we can use value converters in WPF using the BooleanToVisibilityConverter as one of our basic building blocks!

Retros & Post Commentary – Principal Software Engineering Manager AMA

This was an AMA live stream where I focused on:

• My newsletter points on the value of retrospectives
• Jumping into articles/posts from LinkedIn & Reddit
• Answering YOUR questions

Live Coding C# & WPF – Principal Software Engineering Manager at Microsoft

In this live stream, I demonstrated one of my favorite patterns: The facade pattern ! Check out how I build a facade that allows us C# developers to combine any UI elements with a seamless API! You can mix and match WinForms and WPF with ease using this approach!

Build Your Own Custom Value Converter For WPF Binding

What happens when the built-in value converters in WPF just aren’t cutting it for you anymore?

That’s right. You need to take matters into your own hands.

In this video tutorial, I’ll show you how to make your own custom value converters using IValueConverter. Create more flexible bindings! Now you can map between different types of data on your control and your view model.

The Secret To Deploy on Fridays – Interview With Vasilii Oleinic

You fear Friday Deployments. We live for them.

We are not the same.

I had the pleasure of sitting down to talk with Vasilii Oleinic about his career journey, his focus on software architecture, and how he approaches testing.

He had many interesting perspectives that I really enjoyed hearing about, including how to frame up a proof-of-concept vs software systems that need to be robust. Of course, Vasilii also explained his testing philosophies and how his career has helped shape them.

Stay tuned and learn how you can deploy on Fridays! Thanks for the talk, Vasilii!

AVOID This Anti-Pattern… But Here’s How It Can Help in WPF

Here’s an anti-pattern you’ve been told to avoid — and for good reason.

Except… I’m going to show you how it can SAVE YOUR BUTT in WPF.

You’re going to have to understand WHY it’s not great so you can later try to solve this problem in a better way.

In my opinion, WPF doesn’t do a great job with dependency injection. In fact, many of the patterns in WPF make it feel like a battle against DI frameworks.

In this video, I’ll show you how we can use the Service Locator anti-pattern to work around this when building value converters. I’ll explain why I don’t like it, how it will help, and then follow up with what we can do better.

Live Coding in C# – WPF Splash Screen! – Principal Software Engineering Manager at Microsoft

Y’all wanted more live coding! In this live stream, I built a splash screen that supports background loading, cancellation, and other fun stuff! Big thanks to the chat for pair-programming alongside me and helping me along the way!

What do you want to see live-streamed?

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

Nick “Dev Leader” Cosentino

[email protected]

Socials:

– Blog

– Dev Leader YouTube

– Follow on LinkedIn

– Dev Leader Instagram