Jeff Makes Software

The software musings of Jeff Putz

  • You have a people problem, not a technology problem

    [This is a repost from my personal blog.]

    Stop me if you've heard this one before. Things are going poorly in your world of software development, and someone makes a suggestion.

    "If we just use [framework or technology here], everything will be awesome and we'll cure cancer!"

    I like new and shiny things, and I like to experiment with stuff. I really do. But every time I hear something like the above statement, it's like nails on a chalkboard. You know, most of the NoSQL arguments over the last few years sound like that. It's not that the technology isn't useful or doesn't have a place, but when I'm looking at it from a business standpoint, I have a perfectly good database system, that happens to be relational, that could do the same thing, is installed on my servers, will scale just fine for the use case, and I employ people who already know how to use it. Maybe I have something in production that uses it wrong, but that isn't a technology problem.

    I'm sure we're all guilty of this at various points in our career. We've all walked into situations where there is an existing code base, and we're eager to rewrite it all using the new hotness. It's true, there are often great new alternatives that you could use, but I find it very rare that the technologies in play are inadequate, they're just poorly used. That kind of thing happens because of inexperience, poor process, transient consultants or some combination of all of those things.

    The poor implementation is only a part of the people problem. There is a big layer of failure often caused by process, which is, you know, implemented by people. For example (this is real life, from a previous job), you've come up with this idea of processing events in almost-real-time by queuing them and then handing them off to various arbitrary pieces of code to process, a service bus of sorts. So you look at your toolbox and say, "Well, our servers all run Windows, so MSMQ will be adequate for the queue job." Shortly thereafter, your infrastructure people are like, "No, we can't install that, sorry." And then your release people are like, "Oh, this is a big change, we can't do this." You bang your head against the wall, because all of this kingdom building, throw-it-over-the-wall, lack of collaboration is 100% people problems, not technology. Suggesting some other technology doesn't solve the problem, because it will manifest itself again in some other way.

    What do you do about this? Change itself isn't that hard (if you really believe in the Agile Manifesto), but people changing is hard. If you have the authority, you remove the people who can't change. If you don't, then you have to endure a slower process of politicking to get your way. It's slow, but it works. You convince people, one at a time, to see things in a way that removes friction. Get enough people on board, and momentum carries you along so that everyone has to follow (or get off the boat). I knew a manager at Microsoft who was exceptionally good at this, and his career since has largely been to convince teams that there was a better way.

    At a more in-the-weeds level, you get people engaged beyond code. One of the weakest skills people in the software development profession have is connection with the underlying business. Mentor them so that they understand. Explain why the tool you use is adequate when used in the right context and will save the business time and money, compared to a different technology that has more cost associated with learning new skills, licenses or whatever. It's like the urge to buy a new phone every year to have the new hotness... It's fine when it's your money, but not so much when it comes at the cost of your employer.

    As technologists, yes, we want to solve problems with technology. Just don't let that desire obscure the fact that the biggest problems in our line of work are rarely technological in nature.


  • Suppressing FormsAuth redirect when using OWIN external logins

    This is probably the most specific post I’ve written in a long time, but given how long I let it fester, and how much debugging it took to figure out, I figure it’s worth saving someone the time. Last fall you might recall that I did a little bit of reverse engineering, and some cutting and pasting of source code, to use the OWIN-based external authentication stuff, decoupling it from ASP.NET Identity. This was a pretty exciting win for me because I was completely not interested in using yet another auth system in POP Forums, when the one I had was already pretty simple and embedded in some of my own projects.


  • The indie publisher moving to Azure, part 2: operation

    About a month ago, I wrote all about my experience migrating my sites off of dedicated hardware and into Azure. I figured I would wait awhile before writing about the daily operation of those sites, so I could gather enough experience to make a meaningful assessment. As I said in the previous post, this is a move that I was looking forward to make for a good three years or so, when I actually worked with Azure from within Microsoft. The pricing finally came down to a point where it made sense for an indie publisher, and here we are.


  • First impression: Xamarin 3

    Almost a year ago, I started to be a lot more interested in Xamarin, since I already was something of a Mac guy writing software for the Microsoft platform. I've been working in Windows VM's via Parallels for years. At work, the firm we were working with to build out our mobile apps was using Xamarin too. For me, it wasn't just about being able to use C# to write apps for iOS and Android, it was the idea that you could share a lot of code. That's pretty exciting.


  • The ugly evolution of running a background operation in the context of an ASP.NET app

    If you’re one of the two people who has followed my blog for many years, you know that I’ve been going at POP Forums now for over almost 15 years. Publishing it as an open source app has been a big help because it helps me understand how people want to use it, and having it translated to six languages is pretty sweet. Despite this warm and fuzzy group hug, there has been an ugly hack hiding in there for years.


  • The indie publisher moving to Azure, part 1: migration

    I've been a big fan of cloud-based infrastructure for a long time. I was fortunate enough to be on a small team of developers who built the reputation system for MSDN back in 2010, on Microsoft's Azure platform. Back then, there was a serious learning curve because Azure was barely a product. At the end of the day, we built something that easily could handle millions of transactions per month without sweating, and that was a sweet opportunity. Most people never get to build stuff to that scale.