OSS vs. DIY

Fact:  Open source  software has absolutely exploded both in development and utilization this past decade, and it doesn’t seem to be slowing down.

For the subject of this post, “Open Source” means the dot net ecosystem of Nuget packages, as you would primarily find on Github.  Everyone already knows about the posterchild example of Linux (it runs an overwhelming majority of the world’s supercomputers), so if the Open Source revolution is news to you, welcome to the early 2000’s.

Back to Nuget.

Previously I’ve worked with some “old-school” folks who fear the fact that some mish mosh of DLL’s can be imported into your project, and all of a sudden, you’re liable for the code failing.  From old school developers who aren’t familiar with this world, I hear things like:

Why should we import this package?

What is the benefit?

Who is going to support it?

Why can’t we do it ourself?

All of these questions are rooted in the fact that the questioner has not delved into the code of the major packages out there.

By major, I mean any package within the top 20th percentile of commits and/or downloads.  These show extraordinary health, resilience, quality, and durability.

If a brilliant engineer at Google walked into your office, offered to show your dev team some of the best development tricks and secrets, leave you with code samples, and charge nothing, would you honestly say no?  If the SQL mastermind behind StackOverflow offered to visit to show you how their backend works with incredible performance and ease of coding, and charge nothing, would you honestly turn them away in the name of wanting your own custom ADO.Net code?

If you would honestly do it yourself rather take in the code of experts in your field – then your software is prone to bugs, poor performance, and will create massive waste in time and resources due to being rigid, and difficult to change and manage.

So, your status quo has been to “Code It Yourself”.  Bringing the logic in house is the way to go, right?  We write it, we own it, we maintain it.

Couple of logical flaws, here.  Let’s take a look.

Take a package such as RESTSharp.  Now being the type of developer who likes to stick fairly close to my own HTTP wrapping backend, I typically would recommend against taking a dependency on something like RESTSharp in enterprise projects – so there’s no bias here.   Take a look at their unit test suite:

restsharp

Now, if you think that developer hours are better spent “rolling your own solution”, instead of identifying potential open source libraries for a particular problem, I have some provocative questions for you.

Does this single package library have more unit tests than an entire application your team has developed?

Have you hired a Microsoft MVP to give your team code samples?

Do you believe that your development team is superior to the collective wisdom of thousands of developers across the world?

Are you building out and sharing native DLL’s (either internally or externally) for 12+ platforms?  How easy is it to integrate with your system? (SSIS doesn’t count – we’re talking business logic here).  How easily can you share code with your mobile developers for something like C# extensions?

Based on my conversations with folks that keep Github at a distance and their own monolithic codebase close to their chest, they fall short in each of these areas.  Microsoft MVP’s are required to contribute to the community by definition.  I didn’t link to Microsoft’s site because their CSS was screwed up at the time of writing and the MVP page was broken (lol).

Counterarguments to OSS come from a place of comfort and familiarity.  The sort of thing that drives “we’ve always done it this way”.

And I understand – continuous integration terrifies you.  Pushing to production terrifies you.  With good reason.  Every time you change the code something breaks.  Don’t you wish you could remove that fear?

Fact:  The fewer lines of code that exist in your application, the less opportunity there is for bugs, breaks, and showstopping errors.  When’s the last time a Hello World app broke? Finding open source packages which have a narrow, specific purpose, removes lines of code from your app and outsources common functionality into a peer-reviewed, proven and reliable codebase.  Less lines of code means less maintenance, and cleaner readability. (in the vast majority of cases)

But I don’t want to train developers on new language semantics for all these packages!

Another fallacy.  We used to parse like this:

 


public static T XmlDeserializeFromString<T>(this string objectData)
{
return (T)XmlDeserializeFromString(objectData, typeof(T));
}

public static object XmlDeserializeFromString(this string objectData, Type type)
{
var serializer = new XmlSerializer(type);
object result;

using (TextReader reader = new StringReader(objectData))
{
result = serializer.Deserialize(reader);
}

return result;

Now we parse like this:


JsonConvert.Deserialize<MyType>(input);

To prove my point about less lines of code – say you wrote that custom XML code. Your junior developers now have to:

  1. Remember to close the stream, or understand what the compiler does with using { } statements.
  2.  Pass in a Type as a parameter to a method, which is rarely used and is considered bad practice (the industry heavily uses generics)
  3. Address exceptions thrown if other XML conditions are not met (namespaces, prefixes,etc).
  4. Get in the habit of seeing a (T) hard type cast, another bad practice.

Developers import nuget packages to make their lives easier, and this means lessening the coding they have to do.  Open source packages seek out elegant code API’s which occur by capturing the natural language intent of the logic directly into the code.  This is a concept known as Literate Programming.  LINQ is the perfect example of this, but another open source example would be Shouldly.  If the Shouldly package doesn’t make sense to you right way, then shame on you for not unit testing!

1-7j-rape1td6t3ckazwbnyg

Jokes aside, less for loops and null checks mean clearer logical intent and higher code quality!

Now I’m sure a creative developer can find a way to break the call to JSON.Net, but I imagine it would be rather difficult, and you would most likely get a neat, descriptive little exception message telling you what’s wrong, versus some ambiguous TypeCast Exception.

Technology moves, people.  If your development team isn’t moving at a pace comparable to the technology curve as a whole, you will get left behind and create excessive waste in time and resources when the software breaks.  It’s remarkably hard to measure waste in these areas, but a big one is production support.  Having people up at all hours troubleshooting 4 nested for loops because one of your 15 variables happened to be null, is not only a total waste of time and talent, but steadily drops morale and kills the potential of your developers to do what you hired them to do:

Solve problems and innovate solutions for the business.

Let’s stop reinventing the wheel, and start adding more value.


I discovered a great new song by Calexico, a group that does a hybrid of Americana/Mexican music.  Check out Coyoacán.

Leave a Reply

Your email address will not be published. Required fields are marked *