Music - Supply & Demand

Karla and I were discussing the music industry and how it’s been affected by Apple Music, Spotify, and other similar services. The conversation started around an innocent box of CDs that Karla hangs on to for sentimental reasons despite the fact that she was almost every one of those songs available at the touch of a button online. There are formative albums, sentimental albums, gift albums, everyone else had it so I got also albums, et al. But all of these albums have one thing in common, they are owned. The endless supply of digital albums that we “add” to our libraries via digital music services isn’t quite the same.

Most would posit that an endless supply available on demand is a wonderful thing, and for the most part I would agree. Access and availability are great. The internet has fundamentally changed how the world functions. The cost of entry for exploring a new genre is minimal. You are now able to consume an entire album or artist’s music over a weekend, decide if you like it or not, and move from there. Add it to your library (i.e. purchase it) or forget about it (i.e. sell it to used CD purchaser).

The trouble with this is that music starts to become a commodity. The supply of music has gone way up given how easy it now is to produce it. It has leveled the playing field and made it easier to put your music out there whether you’re backed by a big label or not. SoundCloud, anyone? So, what happens to prices and value when supply goes up? Basic economics starts to take its deathly hold on the value of music and effectively decimates it for those that have access to this endless supply.

After reading an NPR article on active listening, I started to engage more actively instead of passively. I’ve been listening to a single artist over the course of a week instead of hours. I started to remember song titles, choruses, and verses again. While I’m not ready to part with the endless supply just yet, I want to be more proactive in giving a more valuable place in my life by treating it the way I did before these services existed. I want to look at the offerings available, “buy it”, then put it on repeat for at least a week to engage it and come to appreciate all the gems that the artist has hidden in it for my enjoyment. As a musician, I would want the same from the audience of my art as well.



Not much is happening on the work front. We continue to forge ahead on the large integration project. We took some time in mid December to transition our code base to Git and TFS 2017. We had just released a large branch that contained about six months of work, so the end of the year was the optimal time to do that. We had some hiccups in getting build definitions working again, Octopus Deploy pointing to all the right places, etc. but by and large it was a success. Now, the work continues to integrate and process funding both up and down to our new vendor. We continue to refine our development pattern, and it’s so refreshing to step away from the text book and evaluate what we really need and not create fourteen layers until we absolutely have to. When you have a small team, all of the layers are just unnecessary complexity that make code less readable.



We moved. Actually, we bought a house. We weren’t planning on it. We weren’t saving for it. It was basically handed to us on a silver platter. Back in April or May we were discussing our current living arrangements. We were in an amazing apartment with no upstairs neighbors. The upstairs neighbors had moved out in April. They were quite noisy with an even noisier large dog that was afraid of being alone…

Since we’ve rented for quite a long time, that was our first idea. Let’s move out of the apartment and find a rental house to move into. We were getting frustrated with high rental prices, and the thought popped into my head one Saturday morning to see if there were any zero down financing options. Purchasing can be so much cheaper month to month, so we decided to step out in faith, ask the Lord to shut it down if it wasn’t what we were supposed to do, apply for a loan, and just wait to see what would happen. Lo and behold we were pre-approved! Let’s start shopping!

We got plugged in with a realtor that was mediocre. We weren’t crazy about him. The morning after we met him we went out on our own and checked out a place in Aubrey that was for sale by a company called Open Door. They have a pretty slick mobile app that can take your location and give you a door code for a private tour of nearby homes. OpenDoor purchases the homes so they are vacant when you tour. No working around homeowner schedules or dashing around trying to coordinate with a realtor. You can bring a realtor if you like, but it’s not necessary. Perfect.

We walked in and loved every bit of the layout, price, and location. OpenDoor called us later that day to discuss the process. It took maybe ten minutes. We made an offer the next day. It was accepted the day after. Talk about quick! Our house had been on the market for just over a month and we were the first and only offer which is just crazy in the DFW market. We went through inspection, contract, foundation inspection, etc. and at closing we were actually walking away with money. 😲

We paid our earnest money, inspection, and other fees, but we still came out with no money down and zero paid at closing because OpenDoor basically covered all of it. Unheard of.

So we moved. We moved out of our apartment into a home in Aubrey. It has all of the space that we need. It has all of the things that we wanted. It was such a gift from The Lord. It couldn’t have worked out better.


Dynamics & Inherited Interfaces

A coworker and I made an interesting discovery today. I was getting a SQL error back indicating that a method–one that was clearly available to my object–wasn’t being found. We’d run into this issue before and found a work around, but it wasn’t until today that we dug in figured out why it was happening.

We’re using Dapper as our ORM. We use these statements all the time.

_db.Execute(“SELECT TOP 1 FROM dbo.MyTable”);
_db.Query("UPDATE dbo.MyTable SET MyField = 'new value'");

Many times we pass in data as such:

_db.Execute(“SELECT TOP 1 FROM dbo.MyTable WHERE Id = @id”, new {id = 5});

In this case, 5 would be some strongly typed object or variable. Dapper does great with these. We created a wrapper for Dapper that gives us some extra functionality:

public interface ICoolDb : IDapperDatabase
  void WithTransaction(Action action);

The above is just an example of something you could do for wrapping up a bunch of SQL statements in a transaction. No biggie, right? This is also where the issue lies. I only have one method available here. If I try to pass in a dynamic object to Execute or Query, the compiler doesn’t evaluate the available methods until runtime. When it does evaluate, it doesn’t pick up the inherited interface methods of Execute or Query from IDapperDatabase, so it throws an error. For some reason, the compiler doesn’t know to work up the inheritance tree to find those methods. #fail

_db.Execute(“SELECT TOP 1 FROM dbo.MyTable WHERE Id = @id”, new {id = 5});

This works because id is strongly typed as int. The fix that we came up with awhile back was this:

_coolDb.Execute(sql, account as object);

This casts our dynamic account object as object which makes everyone happy. I’m not sure if this same quirk applies to later versions of .NET, but we’re running 4.5 and it’s there. It’s annoying to add that as object bit in there each time I’m passing a dynamic, but I guess it’s the best we can do.


Scale Or Optimize

I migrated my whole online ecosystem to AWS over the weekend. It was a fun project. I shared this with a co-worker at lunch today which naturally launched into a conversation about our own environment in the healthcare industry. Because of HIPPA compliance and such, it’s probably not a worthwhile endeavor (for now at least). Our conversation led to scale in general. Does every app really need to scale to the level that AWS allows? Probably not. We own our servers, and, as far as I know, we have maybe three boxes…not even enough to fill a rack. Maybe there’s more, but we support tons of stuff on those three boxes. AWS is way overkill for my measly WordPress site, but it was fun to build and get some experience in nonetheless.

So, should we plan for scaling? Or should we optimize our existing code base to be as performant as possible while minimizing our additional overhead in load-balancers and other such fun magic? We chose to simplify. Less code to maintain means we get to do more fun projects in the future because we have far less cognitive load in keeping up an increasingly complex code base that has more room for bugs. Fewer lines and less complicated architecture keeps smells from creeping in because there’s no place for it to hide.