Optimize for Maintenance


When you are building software, you can optimize for one of two things. You can reduce the time it takes to create or you can reduce the amount of effort you will put into maintenance. Old school RAD tools (and much of Microsoft’s demo-ware) optimize for quick construction. Tools like ORMs (especially Entity Framework) and Rails also make this choice. They all allow you to build solutions quick, and there is nothing wrong with that, if that is what you need.

Most software will live for many years, so you will spend much more time fixing it and adding features. This is where the whole RAD strategy falls apart. Most of the tooling that allows you to build fast (look Ma – no code!) does not hold up well to attempts to maintain it. It allows hidden complexity to creep in while you work around the tooling to fix a bug or add a feature. Before you know it the whole stack of software is hard to debug or add to so nobody wants to do it.

This is why developers fight against having to do maintenance – because they have made it hard on themselves. Developers would like their jobs better if they built for maintenance instead of trying to meet aggressive deadlines.


Out of the funk


I have not been feeling creative for a long time. I suppose this is something that happens from time to time for people. I can recall other times when it happened to me. This time was different. It lasted a long time. But enough with that.

One of the things that helped me get back on track was watching conference talk videos. I have been trying to exercise more for the last couple years with varying degrees of success. The one thing that consistently works for me is walking. The problem with walking is I live in Pittsburgh. Once September ends the sun becomes a rare thing until the following April.

So the solution is obvious. Go to the gym to walk or use the treadmill we bought eons ago. Even though my gym is very close to my house, it is amazing how easy it is to make excuses about not having enough time. The treadmill doesn’t take that excuse. The problem there is walking on a treadmill is SO BORING. Then a realization hit me. I have a tablet. It fits nicely on the magazine holder on the treadmill. And I had been collecting links to conference talks I never find time to watch.

In the past, the number of talks I wanted to watch would have probably only lasted me a week or two. Recently it seems that most of the major conferences (especially some that I would love to attend but are just too far away) have been posting videos of pretty much every talk. Now the solution to the treadmill problem was in focus: I would watch 30-60 minutes of video every morning while I walked on the treadmill.

I know a lot of you are asking why I didn’t do this sooner. I don’t have a good answer. But I wish I had. I started seeing inspiring talks about all sorts of subjects. And then just a few days ago I saw the one that launched me into action: MythBashers: Adventures in Overlooked Technologies by Avdi Grimm.

I have been trying to think up a meaningful side project to learn some new things and scratch a few itches. That word, meaningful, has been the killer. I build distributed systems to manage medications in my day job. If I want to do something meaningful, it should help me get better at that. I was trying to figure out ways to play with message queues and streaming systems and other crazy things. That would be meaningful.

But really what I needed was something I could work on that would be fun. If I managed to learn something along the way that was applicable to my day job, great. But I started programming as a hobby. I wasn’t doing it for the money or the fame. I was doing it because I enjoyed it.

I have been dabbling in “functional” languages because I find them intriguing. The reasons are the same as anybody else. I played with Erlang, tried (and hated) Scala, fell in love with Clojure. The learning curve on all of them is steeper for me than F#, though, since in my day job I use C#. So I decided to focus on F#. I’ll pick up Clojure again later and I’m sure I’ll check out Elixir. But for now I need to focus, so F# it is.

And so we come to the project. Back in college I ended up getting very poor grades one semester. I partly blame taking two 300-level econ classes at the same time. My parents blame beer. I know the real truth. It was MUDs. To those who weren’t alive in the early 90’s, a MUD is a Multi-User Domain (or Dungeon). Think World of Warcraft, but with nothing but text. I was obsessed. I spent a lot of time in the computer lab playing. And then it got worse – my roommate showed me how to connect from my dorm room. Yeah.

To this day I have resisted games like World of Warcraft because I know what will happen. But now it is time to put that misspent youth to use. I have started building a MUD in F#. I doubt it will ever be great. I may be the only person who ever plays it. That is not what matters. What matters is it is a real thing to build. A thing I can care about and enjoy. That is really what a hobby project should be. I may come up with a better idea someday, but in the meantime I should be using my hobby time to do something more useful than reading millions of words about software development. I should be writing software.

I plan to write about what I learn along the way. I actually have set up a micro-blog of sorts in the project where I am posting my “stories” and other notes along the way. I expect that as I start I will not be writing good F# code, but by writing the code I will learn more and eventually I will have written some good F# code. Probably just a couple methods across the project. 🙂

If you would like to follow along (and tell me what I am doing wrong – this is a learning experience, after all) you can find the project here.

The Wild Goose Chases of 2011


I spent a lot of time last year trying to learn a lot about everything I could in terms of the latest development fads (other than Agile – I think I’ve flogged that horse to pieces). I figured I needed to learn Ruby, Rails, JavaScript, Node, jQuery, Backbone,… Part of the department is rebuilding a PowerBuilder application that needs to stay a thick client using WPF, so I learned a bit about Caliburn Micro. I found a little time to dabble in CQRS, MicroORMs, RabbitMQ, and MassTransit as well, but I didn’t focus on them too much.

The net result, come the holidays in December, I was feeling quite burnt out. So much so that I pretty much ignored software for a bit. January started and I felt better, and then I went to CodeMash, and that helped a bit. But the thing that really snapped me out of my funk was the realization last week that while I should know the basics about everything I can, I can’t know everything in any real depth. I have to have something I specialize in.

I’ve always been a fan of the generalizing specialist theory espoused by Scott Ambler. The problem was, I was spending all of my time generalizing. Part of that was an occupational hazard – I am tasked with figuring out the general direction for the technology and architecture of our product suite going forward. In order to do that, I needed to evaluate the suitability of some of these things. But I certainly didn’t need to dive into all of the shiny tools and toys I did – some of it didn’t matter at all. Some of it could have been delegated to someone else.

So now, as I step away from the fire hose that I’ve spent the last year trying to drink from, I realize what I need to do. I need to focus on the things that I know well, that have gotten me to where I am today. Sure, I still need to occasionally play with other technologies. But that can’t be the focus of my software development life. By diluting myself across these things, I haven’t really helped anyone, especially myself.

Now that I have that sense of clarity, I think this year will go much better…