Future Systems, Code Longevity and Web Ghost Towns

In this one-on-one episode of the Versioning Show, Tim and David discuss how compatible today’s technologies will be with future systems, how long software should last, project organization and progressive enhancement, the curly question of whether a piece of software retains its identity even with an entirely new codebase, and web ghost towns (#webGhostTown).

Show Notes

• #webGhostTown hashtag on Twitter
• Tim’s project restaurantmenubuilder.com. (GitHub repo: RestaurantMenuGenerator)
• lean startup
• Gang of Four
• Apollo launch code on GitHub
• webpack
• RICG Responsive Images for WordPress
• Jacob’s Ladder
• Google Play Music
• Say hello on Twitter: @mdavidgreen | @tevko | @versioningshow | @sitepointdotcom

Conversation Highlights

I don’t want to create a web ghost town. I don’t want to create large swaths of projects and libraries and frameworks that worked super well for a short time, but then, as you’re thumbing through the web on your phone, you just come across broken thing after broken thing after broken thing that’s just not relevant, not maintained anymore

---

That has to do with creating an environment in which a single developer or a small team can be remarkably productive, and produce these intricate and complex pieces of software. That comes at the cost of the abstraction. We’re not really conversant with every detail of what’s going on in our code the way that the folks who wrote the Apollo mission certainly were.

---

I think that if you are going to start asking yourself, “How long should software last?”, you want to make sure of … organization — so that whenever you go back and look at this thing, you can actually know what you were doing at the time.

---

As a developer, you want to approach the software as “This is going to last maybe a year at most before I throw it all away and start over again.” As a user, you want it to be permanent. That is a very telling statement about the state of affairs.

---

It’s certainly more satisfying to write clean code — code that you can show to somebody without being embarrassed. And that somebody is going to be you in six months, so you’d better not be embarrassed.

---

Code is like the mutant DNA virus thing that is just constantly changing and looking different.

---

I typed that semicolon. I did, I did!

Transcript

Tim:

Hey, what’s up, everybody, this is Tim Evko …

David:

… and this is M. David Green …

Tim:

… and you’re listening to episode number nine of the Versioning Podcast.

David:

This is a place where we get together to discuss the industry of the web from development to design — with some of the people making it happen today, and planning where it’s headed in the next version.

Tim:

Today, it is just David and myself, and we’re going to be talking all about software. Specifically, when you’re building software, how long should that software last?

So, we’re going to dive into that. We’re going to bring up some interesting perspectives and points, and yeah, life cycles.

So let’s go ahead and get this version started.

David:

If we were going to ask a philosophical question at the beginning of this episode, we’d have to ask it of a piece of software, because the software itself would need to know what version it was.

Tim:

Yeah, and that’s a little bit tough to do.

David:

Instead, since we’re going to talk about this topic: Tim, you brought up this topic. I’m curious what brought this to mind for you.

Tim:

Yeah. So, of course, I have a full-time job. I work on a team building a specific piece of software. It’s an ecommerce platform. It’s a website, and you go and you buy products from it.

Then I also have open-source projects that I work on on my own. I built a small project to help restaurant owners build menus out of HTML, PDFs and stuff like that. I have side projects inside libraries and I contribute to open-source stuff, and I work on this big, long lasting product at work.

Often times, when working with others and just with working with myself, I tend to think, all right, I want to build this thing to last forever and to work on every device. And that’s a difficult pattern to get your head into — building for the future, to make things future proof. I often ask myself not only what is the right way to go about doing this, but is this even the right frame of mind to have for every specific thing that I’m working on?

If I’m working on a quick library for dragging and dropping orange divs on a screen, do I, or should I, intend on making that thing super progressively enhanced and working on every single device and able to last into 2100 when we have the internet directly in our brains.

David:

I think it’s going to be up to the folks in 2100 to figure out how to access all of this stuff. I was just listening to a podcast recently. They were talking about the situation that NASA got itself into when it sent all of the data back from the original lunar probes.

They were taking these huge photographs, and it was digital data, and it was sent back, and of course it was stored on the top-of-the-line, reel-to-reel tapes that they could possibly afford, and they made sure that it was as archived as it could be. But because the technology got completely out of date, they got themselves into a situation where there was only one copy on tape of this information apparently stored in whale oil, because that’s a thing.

Then the only way that they could play it back was fortuitously one employee had personally purchased reel-to-reel tape players that could play back this kind of tape, and stored it in a barn somewhere. And they had to dust it off and get these things working again.

The idea that anything is going to last forever starts to look a little bit iffy when we realize that some of the most sophisticated technology that we have put into place to try to store and retrieve data just from the last 20, 30 years is already impossible to retrieve.

Tim [3:48]:

That is both a very interesting story and an excellent point, because the technology 10, 20, 30 years from now — maybe even just 5 years from now — might look completely foreign to someone. Right now we write in JavaScript, and maybe that changes in 20 years. Maybe all these libraries and things that we’ve been building are just not going to be that in a certain amount of time.

So then, I guess my question becomes, what do you build for? Because I have this innate sense of I want things to last as long as they need to. If I’m building something, and ten other people suddenly decide we want to also work on this thing, what frame of mind am I supposed to be in from the get-go, from the beginning. Before I write my first line of code, what should my goal for the lifetime of this project be?

David:

It’s an interesting point. There’s the lean startup concept, where you basically build for the foreseeable current future and then adapt as you go. I think that you and I, as engineers, both have this desire to build something as beautifully as possible.

The beauty of the code that we write is an important thing to us. Part of that is the beauty of being able to step back into code that you wrote six months ago or six years ago, and understand it, and have it operate, and have it adapt properly to what’s going on.

I think it’s a challenge to come at it purely from an engineering perspective, because the issue that we’re talking about, it comes down to both a design issue and a business issue, I think. Because the use case is really a critical thing to consider. It depends on what you’re building and what the audience is supposed to be.

Tim:

That’s very true. So I’m thinking, let’s start off with, we have a project in mind. We have something that we want to build. What’s something that we can both agree on — regardless of the goal or the intended use of the thing — is important in terms of the lifetime of the project or the organization? I would say that important would be, all right, yeah, if for some reason I come across this code again in a year, at the very least, I want it to ascribe to a specific design pattern to ensure its readability and organization.

David:

That does make sense.

Tim:

Then I would say, because design patterns change, and so some people will say, “Oh, this decade it’s all about procedural code, and this decade it’s all about functional code.” At the very least, even if that does change, I can recognize a procedural versus object-oriented versus functional pattern when I see one.

So I can say, all right, if I stick to a specific pattern throughout the lifetime of this project, even if I go back ten years and say, What was I thinking? We totally don’t write code like this anymore. At the very least, I can recognize that, right, this code has a specific design pattern it ascribes to, and if I wanted to add or adjust, I can do that because it’s not all over the place.

David:

That’s funny. Just even the phrase design pattern starts to make my skin crawl. I start thinking back to the days when I was working in Java (and I’m never working in Java again, trust me), I think it was the Gang of Four who did those design patterns things, and I remember a lot of what I learned in my early days as an engineer did come from design pattern thinking.

Then in later years, what I’ve discovered is that one or two patterns will become popular or useful, and then they’ll become renamed and people will start using them in different contexts. I don’t know if people are going to be able to think in terms of design patterns for the long term, when looking back at what they’re doing.

What you’re talking about is the archaeology of code at this point, because you’re talking about ten years from now, somebody looking at code that was written today. How are they going to decipher what the intent of the embedded culture that’s in that code, where that comes from? Since design patterns are documented from, what, 20 years ago to now, that’s a good place to start. But I’m wondering: it feels to me like we’re evolving in so many different directions that maybe that’s not adequate.

Tim [8:08]:

You definitely have to go further than that. Let’s say, all right, so we have a specific type of way that we want to organize our code so, at the very least, it’s readable. This is just for the thought experiment of writing code that’s supposed to either last long or just be generally durable for as long as it needs to be.

Then it gets a little bit murky, because we have our code structured in a specific way, but then nobody writes code like just, all right, we start with machine code and then we write everything and we have everything we need just siloed here. People use libraries and frameworks and different tools. That means that it really does start to, right off the bat, depend on (at least to me) it starts to depend on the intent of the project. Because if I’m writing something that is — I don’t know — A UI for a utility company, I probably want that to last as long as possible.

But if I’m doing something that’s like a specific Oculus VR site for some product that maybe will only last for five years, then I don’t necessarily have the same goals.

Yeah, I’ve got my design pattern, or the way that I want to structure my code so it’s readable, but after that, when it starts to be, all right, now if I’m going to reach for this library, then I have to think about, is this going to be the thing that no longer makes sense or is usable in the next couple of years? Or if I’m using this specific build tool, if I have to go back to this thing a few months or a few years from now, am I going to have to dust off an old machine so I can run this version of Node that this thing only runs in?

Yeah, if you’re planning these things out, you pretty much have to start considering it right off the bat. I thought maybe we could list some of the things we’d agree upon. We could get set, right up until we had to decide what the intent of the project was. But it seems like almost immediately you have to do that.

David:

Especially the way that the libraries and frameworks, they change versions constantly, their dependencies change versions constantly. You need to lock in a particular stack, with exactly the set of dependencies, with exactly the set of versions. You get locked in that way, then you don’t have the opportunity to advance and take advantage of new technologies and new tools.

Then you also get locked out of changes in the browsers, the changes in the environment. If you’re developing for browsers, you and I doing front-end work, we would be thinking in terms of developing for browsers. It’s the same thing with server technology, and with any context: that that context can change right from under your feet.

Unless you are on the same machine with the same operating system in the same stack of software — the same versions of all of those pieces and nothing has been updated, and all of the users of your software are also in that same context — the long-term implications are just impossible to predict. There are only certain contexts in which you can really restrict that.

I’m thinking, for example, of the medical insurance industry, the government contracting, the banking industry, a lot of these areas. Microsoft had trouble getting these companies to upgrade past the old versions of their operating system, because they were locked in to those older versions. It ended up being a situation where, as I recall, everybody was screaming for Microsoft to finally end-of-life Internet Explorer 6. Microsoft couldn’t do it, because so many of their customers were locked into these versions of the software that they would have had to re-engineer their entire platforms in order to support a new operating system.

Tim:

That’s almost the scary thing for me to think about, because when I’m thinking about building software, or even just building something on the front end, how do you approach that for saying, all right, if this thing is important enough to need to last for a very long time, that means that I really have to take into consideration the types of tools and frameworks that I’m using. Because, again, if I need to update it, I could get into some trouble where I just might not be able to.

But, not to stray too far away from the original question, how long should software last? It seems like we’re getting into this area where, due to the pace of how quickly the web changes, it seems very difficult to write software that can truly last long.

David [12:21]:

Yet, the other thing that’s happening simultaneously is we’ve got the open source community. Because of the open source community, we’re in a situation where software can be released a decade ago, and because people are constantly updating it, and there’s a whole swarm of people crowd programming this, it can be maintained and kept up to date and adapted and forked to support all of these different environments — so that what is currently in existence, supporting whatever environments people want, may have very little relation to what was originally published as the beginning of an open-source project. Yet it’s still the same piece of software.

So when you talk about the lifespan of software, you have to realize that it’s morphing, and it’s evolving constantly, as long as it’s alive. And that’s the only way that it can stay alive.

Tim:

Yeah, it would have to be that way. I was looking at Apollo launch code that was on GitHub. I think it was this week it was released on GitHub. It was amazing. It was absolutely amazing, just to look at — this thing landed a thing on the moon. That’s amazing.

But code back then, I feel, was a little bit different from code today — at least in the space that I operate. Because now if it were just, all right, I’m writing a simple JavaScript program, I could totally see that. Now I’m writing my JavaScript, and then I’m having webpack transpile into ES6, and then I’m having those split up into different components. Then that’s going to be server rendered, and we have this framework doing this thing. That to me seems a little bit more difficult, because you can still save that code, but when it comes time to run it, you have to hope that all of these different intricacies still work.

David:

You introduce an interesting point there with the transpiling too, because, frankly, you could have the transpiler evolve, and the code itself stays exactly the same, but constantly have it transpiled to match whatever the current environment would need to be. In which case, it would just be about maintaining the semantics of your own code in a way that is consistent with the way that the transpiler expects it to be. Then rely on the transpilers to maintain the currency of the code.

Tim:

I think we’re discovering something very interesting here: that when you’re asking yourself, “How long should this software last?”, the answer is that it’s never going to last forever, of course. I think we’ve also realized that when you do ask yourself, “How long should this software last?”, it really depends on not just what the software provides, but what type of software it is. If we’re talking about something for the front end, that is going to have a different lifetime than an OS or a browser.

David:

Makes a good case for prototype engineering as well. One of the things I’ve resisted at some companies that I’ve worked at is the idea of bringing in a prototype engineer to do pre-development on things, because I know often what is the prototype will end up becoming the production code. It won’t be resilient enough, or it won’t be performant enough.

On the other hand, the point that you’re making, front-end code needs to adapt, needs to change so quickly, that it’s arguable that maybe there’s a place for the idea that with the code that you’re writing for the front end should be viewed as prototype code until you get a performance block. At which point, then you need to go in and make things more performant. Of course, that also negates the issues of security, because front-end code certainly opens up a lot of security holes. You can’t have prototype code doing that type of thing.

Tim [16:00]:

Yeah, especially in high-security industries like banking and insurance. That’s interesting. So, building software, asking ourselves how long it should last, I’m starting to think that two things, a) it’s never going to be very long, but b) if you want it to last very long, you do have to be concerned about dependencies and tooling.

David:

Mh-hmm. We as engineers I think need to be prepared to answer those questions from an engineering perspective, but clearly there’s a whole set of related questions that need to come from the business side and from the design side of the company, to determine whether or not it’s even relevant to concern ourselves with the lifespan of the software.

We as engineers again need to be able to point out that there are costs and benefits and tradeoffs associated with making these decisions having to do with the lifespan of a piece of software, so that when somebody who’s funding a project has to make the decision about where those tradeoffs go, they’ll have adequate information, but there’s a lot to consider.

Tim:

It seems that today’s modern development environment is very much angled towards developer productivity and ease of use and quick prototyping. A lot of libraries and tools and frameworks have emerged to make that a reality.

On the opposite side of that, it seems to me like the existence of a whole bunch of new tools and libraries and frameworks, because there are so many, will shorten the life time, or the time that your software is relevant and usable for a large group of people. It seems like the existence of a lot of tools and libraries and frameworks will shorten that lifetime. Does that even matter? Is that something that developers should be concerned about?

David:

I’m going to say that I agree with you, because I do think that it does matter as to your second point. To your first point, what that makes me think about is the level of abstraction that we get from what is actually produced versus what we’re writing. You were mentioning transpiling before, and transpiling is just one piece of it, because not only are we transpiling, we’re pulling in libraries, we’re pulling in frameworks.

We’re building on top of this huge house of cards of code and context that we really don’t know everything about what we’re doing. If we could possibly know everything that’s going into a typical codebase these days, we’d all be geniuses. We’d all have heads that are so huge that it wouldn’t be able to fit on our bodies, because there’s so much to keep track of.

Tim:

Yeah.

David:

That has to do with creating an environment in which a single developer or a small team can be remarkably productive, and produce these intricate and complex pieces of software. That comes at the cost of the abstraction. We’re not really conversant with every detail of what’s going on in our code the way that the folks who wrote the Apollo mission certainly were.

Tim:

I think that is the core of my question there, and that’s the core of the topic for this episode. I’m thinking to myself, I don’t want to create a web ghost town. I don’t want to create large swaths of projects and libraries and frameworks that worked super well for a short time, but then, as you’re thumbing through the web on your phone, you just come across broken thing after broken thing after broken thing that’s just not relevant, not maintained anymore — because we’ve built for ourselves this environment of rapid iteration, quick things because of all this abstraction, but again, at the cost of this is built to work now. Again, I’m not really sold on the does this super matter right now for us part? It’s a creeping suspicion that in a couple of years, we will get to this web ghost town state.

David [19:50]:

It’s definitely something people need to keep in mind. I think if I were architecting a new project for a large client right now, it would be one of the key critical questions that I would ask. Because you have to choose from the available technologies, and you have to be compatible with all of the available environments that are relevant for a particular project. In order to do that, you need to build on top of this huge infrastructure, and you need to know just how much control you have over that and how relevant that is to whatever company you’re working for.

I suppose in that sense, it’s fortunate that for most commercial applications, the lifespan — you shouldn’t be thinking more than a year or two out, because the context is going to change so much in a year or two. Whereas in certain industries where security or the infrastructure is very critical, they freeze that. In that case, the variables we’re talking about go away because that’s all been frozen for the users, and they’re forced to use IE 6 until 2011 or whatever, because it’s mandatory for them to be able to control every element.

Tim:

Yeah, very good points. I do definitely hope that, while it feels like the Wild West right now in terms of technologies and capabilities and what people build to provide those abstractions, that we don’t get the opposite of that, which is like web ghost towns. I’m just going to coin that phrase now, so everybody start using it, web ghost town. That’s a thing.

David:

Hashtag!

Tim:

Yeah, I think one way to help this from not becoming a problem, again, if you’re listening and you don’t feel like this will ever be a problem, that we’re just going to continue to iterate on technologies and nothing’s ever going to fall by the wayside, that’s cool.

But, if that even were a possibility, I do feel like the idea of progressive enhancement helps a lot. Because if I’m building something to cater to the device with the least capabilities right now, that means that I’m not going to be relying on a specific foundational thing working exactly as it needs to right now. Instead I’m relying on just the general grain of the web to do what it does best, and that’s what really powers the thing that I’m building. Then everything else on top of that is just another layer of convenience.

David:

That’ll help as long as you’re not writing for the Commodore Amiga.

Tim:

I think that if you are going to start asking yourself, “How long should software last?”, you want to make sure of two things. Thing number one, organization — so that whenever you go back and look at this thing, you can actually know what you were doing at the time. I’ll be the first person to say, if I looked at code I wrote even three years ago, I would probably — I don’t know — pass out or something, because we all look at code that we wrote a long time ago and just hate ourselves for it.

David:

Absolutely.

Tim:

We do our best with what we have. Now, if I’m starting a new project, I’m going to focus intently on organization and progressive enhancement. I’m hoping that will allow the software that I’m writing to last as long as it needs to.

David:

And as long as it needs to is the second point, because that’s the question that lives both inside and outside of engineering. Engineering needs to be able to give people a clear answer as to what context they need to prepare for as things are changing in the environment. But ultimately, whoever is commissioning a piece of software is the one who knows how long it needs to last and what audience needs to be served by it.

It’s appropriate for us to develop software with the idea in mind that it’s going to live a certain length of time. And if it needs to be adopted by a new project, or it needs to become the backbone of something that’s going to develop next, it’s important to structure code in a clean way so that we can understand it in the future.

Tim [23:39]:

It’s interesting, too, because it’s often the business goal to determine how long this thing needs to last. What I found a lot in an engineering team is when an executive or a stakeholder says, “We need this thing,” it’s also your job to say, “Listen, they could come back tomorrow or six months from now and say, we also need this extra thing. We want this thing to do two extra things that we didn’t say in the beginning.”

So this thing needs to last as long as it needs to, as long as it fulfills the goals that we set for it. But it also needs to last maybe longer than that. Maybe we need to build in a specific way that if a stakeholder comes by and says, “We also want it to take pictures of your face when you press this button,” then we’re going to need to add that in.

How do you account for that? How do you account for the changing landscape of the lifetime of a product?

David:

I’m going to say that that’s a different question.

Tim:

That’s fair.

David:

Because we’re talking about how long the software should last overall, and it will adapt and change over time. How flexible a piece of software should be? I can see actually it’s a corollary question, because it relates to how the code will adapt over time, and whether or not software ever goes away in that context. Until a company goes out of business and the software just completely end-of-lifes, at that point, you no longer need to worry about adapting that software to do something else.

Anywhere along the way, you can completely turn around and change what the functionality of a piece of software is and still call it the same software for whatever business reasons. At that point, from an engineering perspective, is it even the same piece of software?

Tim:

It’s like a band whose original members have all moved on.

David:

That’s very true, but they still play those same songs.

Tim:

Yeah, I do think that at the end of the day, software should last as long as it needs to, and to accommodate for that, we build for progressive enhancement and we build the absolute most organized way we can. I think that’s really the only thing that we can do in that sense.

David:

As engineers, I think we want to write in that way. It’s certainly more satisfying to write clean code — code that you can show to somebody without being embarrassed. And that somebody is going to be you in six months, so you’d better not be embarrassed.

Tim:

Yeah. I bring this up because the more experience I get in engineering and with development, the more I find myself asking, “All right, what are the intentions for this thing that I’m building? Is this going to exist six months from now?” It seems like most of the cases, it does end up existing for a while, and my intentions might remain the same. They might change, but overall there are those core principles that need to be applied to those things that you’ve built just in case you want to go a little further.

David:

I have frequently learned from building something one way, completely torn it down and rebuilt it a completely different way. It’s still the same piece of software. I might have used like a different language. I might have used a different framework to do the exact same thing, and each one builds iteratively on the previous one.

It’s an interesting question, because on the one hand, you’re talking about the lifespan of the software itself. On the other hand, you’re talking about the code that goes into the software and how long that code will last. I think if we break down the question into how long will this code survive versus how long will the software survive, then I think we’ve got something more specific.

Tim:

That’s very good, because as far as I’ve noticed, code never survives. Code is like the mutant DNA virus thing that is just constantly changing and looking different. When I helped to write responsive images into WordPress, I wrote the original first — I don’t know — three versions of that from when it was just an idea in a PHP file in Sublime Text, to Chris Coyier and I working on it, to forking WordPress with the our RICG repo to actually getting something like in the WordPress repository.

And then, we started to say, “All right, let’s work on a plugin. 50% of my code left.” Then we’re like, “All right, plugin is now approved to be a feature of WordPress in the next 4.0 release.” Then there is 25% of my code. And just before we actually hit the publish button and WordPress was out with our feature in it, there is maybe 1% or half of 1% of my code left in that thing!

David [28:06]:

I typed that semicolon. I did, I did!

[Laughter]

Tim:

Yeah, that’s pretty much where it’s at now. It’s like, “You see that comment? I wrote that comment.”

[Laughter]

Yeah, you should never really expect code to last that long, but it’s like a Jacob’s Ladder effect. Your code is the next step. What you certainly don’t want is to write a broken step into the software.

David:

Absolutely. I think distinguishing between how long the code lives and how long the software lives is useful for thinking about this.

Tim:

Definitely.

David:

How long the code lives. As you said, the code does not live. The code is very temporary. Code that is more than — it’s different for different contexts — but if it’s more than a year old on the web, it’s probably out of date.

Tim:

Easy, easy, yeah. Because even now, when you look at code a year ago, and it’s like, “Well, I used a bunch of var statements, and I could have used constants.” Constants didn’t exist back then, so there you go.

Yeah, I definitely think that’s an excellent distinction to make is, how long should the code last? And then of course, even with JavaScript, all of your XMLHttpRequests are going to turn into Fetch requests, and AppCache is going to turn into Service Worker, and so on and so forth. If we write code with the idea of this is just a step in the ladder, it might not exist ten days from now, but it gets us a little bit forward, it helps improve the health of the software.

David:

“To everything — turn, turn, turn.”

Tim:

Yeah, exactly. As long as you do that, you will improve the life of your software. Yeah, it’s important to see the code that you write as just another step, I think.

David:

It’s an interesting topic, and it’s controversial. And I’m really curious what the listeners are going to think about this because they’re they’re out there, they have different perspectives. I know some of them are coming from the business perspective, some of them are coming from the engineering perspective. Some of them might be coming just from a user’s perspective, about how long they expect their software to last when they get a piece of software or when they get onto a site. How long do they expect that site to be there and remain in a form that is recognizable?

Tim:

That’s interesting, because here we are, claiming to build stuff for the web, and I never even thought of asking that question. I certainly know that when I was using Rdio to listen to all of my music and Rdio went under, that was like a life-changing thing for me. It was like, “No, my music, what’s happening?”

I had to make yet another fake 80s playlist, and then I move on to Google Play Music, and I’m thinking to myself, I really hope this lasts forever. I’ve invested into this software. This is where I get my music from. When I go to the gym in the morning, I have this thing that I just know how it works. I don’t have to think about it.

I think, as a user, I want my software to continue getting better, but I don’t want to go away.

David:

Getting better is also a challenging question for a user, because, as developers, when we make something better, it doesn’t always appeal to the way that the user expects it to behave.

Tim:

Yeah, definitely. That’s true with redesigns. For example, we’ve all known products that have redesigned themselves into a dark cave, where you know products who have changed up their business strategy and split themselves in two and then quickly died.

Aside from the products going under because of money or what have you, I want it to last forever because at this point it’s a part of my life, and that sounds corny to say for a music app. But it’s like a routine, and I’m comfortable with it. I certainly — if I were to actually think about it — I don’t want the engineers there doing anything bad with this thing that I really like. I want it to last.

David [31:48]:

I think music apps are the perfect example of something like that, because what’s more intimate than the sound that is coming in these tiny little things inside your ear when you close your eyes and it’s in the middle. It’s in your head. It’s one of the things that attracted me to podcasting in the first place, was the level of intimacy that comes with an audio medium like this.

With music, you’ve got the rhythm and it’s getting into the songs that you remember from your childhood and the things that you work out to, the things that are part of your life. You certainly don’t want some developer somewhere making some change that’s going to change that aspect of your life permanently.

Tim:

Yeah. I’m just thinking of the graveyard of musical things that I’ve used. The first was LimeWire, and then it was Pandora, but Pandora doesn’t let you pick different songs, and I eventually got tired of that. I moved from that willingly. I did lose a whole bunch of stations that I paid, because it was more of a business model thing than an engineering thing, but there were hang ups with bugs in Pandora, but I decided to move from that.

Then it was Grooveshark. I paid for Grooveshark actually. I was a paying member of Grooveshark, and I could listen to all my songs, and I had a million playlists. They were all excellent. Then one day, like that, Grooveshark was gone. They’re like, “Sorry, our lawsuits finally caught up to us.” That was it, it was over. All my music was gone, nothing was backed up.

Then I moved right over to Spotify — which I promptly got immediately out of, because I couldn’t stand the fact that they tied everything to your Facebook account. You pretty much had to go app-only, because their web interface was just a dumpster fire. (If you work at Spotify, I apologize sincerely. It might be the best thing in the world now, but at the time, it just wasn’t my thing.)

I moved from that very quickly over to Google Play Music, and now I’ve settled down. I’m paying for that, and I love it, and at this point, I’m just so invested in it that I want it to last forever. That’s how I feel about the software that I use as a user.

David:

So it’s a completely different perspective than you think of it as a developer. As a developer, you want to approach the software as “This is going to last maybe a year at most before I throw it all away and start over again.” As a user, you want it to be permanent. That is a very telling statement about the state of affairs.

Tim:

I also don’t want annoying bugs to drive me away from loving the product. For example, when I think specifically about Google Play Music, if I were changing a song and the browser refreshed and it just forgot what was going on, and that continued to happen, I’d be furious. I’d be really upset with that.

Of course, that’s a code issue. If you trace the pipeline all the way down to a bad framework or a library being used, or a bad pattern, or someone putting an if statement in the wrong place, or a while loop that never exits, that sucks. That could drive me away from a product, definitely.

From a user’s perspective, it’s all about business decisions. Keep making the right decision so that I can continue to use this product, but then it’s also if this thing gets buggy, if we start to get errors or weird usability concerns, or even from a design perspective, if you do a really bad redesign, as a user I have a stake in that. But I don’t actually think about that, because I just want the thing that I’m using to continue to be working well.

That could stop working well from either business concerns, design concerns or development concerns. If your software is thought of well, and you write your code like a ladder, and each thing is a next step and you write your code well, but you don’t demand that it stays in there forever, clouding up the goodness of your thing, just making sure that your code is good and well designed and quick and iterative, then that is one of the three — business, design, code — one of the three things that’s taken care of.

I think as developers, we do want our software to be good, and last as long as it needs to.

David [35:33]:

Well, loosely coupled, modular developments certainly with progressive enhancement: from a development perspective, that’s what we want to build. It’s a separate question though whether that is going to satisfy the business needs of the company as it moves forward and as it has its lawsuits. Or if it’s going to satisfy the developers who created the operating system that’s on your phone that can’t be upgraded and that therefore won’t support the features that were in the previous version that need to be there in order for the software to continue working.

It’s difficult to say, “You can’t make something that’s going to be that solid unless you’re constantly adapting it and constantly adapting it.”

Tim:

Very true. Progressive enhancement does solve some of those things, but it doesn’t solve all of those things.

David:

No, particularly from a business model perspective, because if the business needs something that is going to be added through one of those progressive enhancements in order to satisfy the needs of the investors or the designers, then that just doesn’t get addressed by a progressive enhancement solution.

Tim:

Very true. I think we’ve come full circle into saying when you ask yourself how long software code should last, really what you want to do is realize loosely coupled, modular, clean, well-organized code; that seems like that’s pretty much it.

David:

From an engineering perspective, perhaps, but I want to hear from our listeners. I want people to give us some feedback about this, because I don’t think it’s a question we’re going to be able to answer in one session. I think that the terms are broad enough that they’re open to a lot of interpretation, and I’m curious if there’s a perspective on this that — we’ve come at it from a number of different angles, but obviously, we couldn’t possibly come at it from every angle. I’m curious if there are angles that people out there would have liked to have heard us focus on a little bit more that we might have missed.

Tim:

Yeah. Please shoot us an email, fire off a tweet, send smoke signals, whatever you do. We will most definitely respond, and we’re looking forward to what you all come up with.

David:

What was that hashtag again?

Tim:

#webGhostTown.

David:

Web Ghost Town. All right. Tweet us at Versioning Show or use the hashtag #webGhostTown, and we’re going to be looking for those.

Tim:

Oh yeah. I’m going to save that in Twitter, and I’m going to look every single day. Don’t let me down. Please just one of you use it!

David:

Cool.

---

Thank you so much for listening, everybody. We always enjoy getting to talk technology with all of you.

Tim:

We’d also like to thank SitePoint.com, and our producers, Adam Roberts and Ophelie Lechat. Please feel free to send us your comments on Twitter — @versioningshow — and give us a rating on iTunes to let us know how we’re doing.

David:

We’ll see you next time, and we hope you enjoyed this version.