All Code Is Fleeting, Don’t Act Like It’s ForeverFebruary 04, 2016
Of all the things I have written in my 34 years of being a programmer, the code I have written that I know is still in use is very limited. Prior to my previous job the only app I know still exists is Deltagraph, which for some reason is still being sold 27 years after I started its main.c, and much of the original code I imagine is still in there as the app hasn’t changed dramatically since we stopped working on it in 1994 or so.
Everything else is gone, replaced, out of business, shut down, superseded or archived for no apparent reason (as if some future archeologist might inquire). I bet most of yours is gone as well. The people who wrote all those banking and insurance systems in the 60’s can say the code has outlived them, if they could. Not all code is malloc() today, free()ed tomorrow of course.
These days I work on iOS apps, and their lifespan is fairly short. At my current job the bean counters hear “mobile” and always respond “expense, you’re just going to rewrite it anyway.”
When I worked at the now gone travel company (sadly just a brand of the other guys) we built a brand new app for iOS 7 launch day in Objective-C of course, with NSURLConnection networking since I wrote that code a bit earlier. If we were still in business today I’d be rewriting in Swift and using NSURLSession just two years later. iOS changes so fast and everyone updates right away so it makes sense to take advantage of new stuff quickly. Android is stuck with all those old devices running ancient versions of Android so it’s not as big a deal.
One advantage of being around so long is seeing the pace of change … change. In the past decade or so things appear faster and faster and almost anything you pick seems out of date immediately. When I started in the early 80’s things changed but at a much more glacial pace. No internet, no open source (at least easy distribution) plus you had little idea of what anyone else was doing so learning new stuff couldn’t happen fast. Even development took longer, and in my case shipped on floppies and ads had a 4-5 month lead time. I picked C for my first Mac startup in 1985 and didn’t change for almost a decade; there weren’t many choices.
Today I see a new programming language appear several times a week.
So what do we do? We could pick something and refuse to change, but that’s like nailing your feet to the ground during a marathon; you don’t get very far. A better and of course much more scary choice is to find ways to change the pace of development, so even if we do make a choice, writing it again isn’t a big deal. Of course that’s hard!
All my life I’ve specialized in writing even complex apps (mostly client facing) quickly. It’s not easy to do unless you can control the process, the people, the decision making and have support from whoever is in charge so it’s not always possible. People love to complicate development with too much process, too much perfection, too many approvals and make everything take so long that no one wants to do it again so the code lives far too long until it becomes concrete.
Not everything is code you can rewrite every two years, but when the underlying technology is changing at an ever increasing rate, spending too much time on any one thing can put you seriously behind everyone else. In hyper competitive markets you need to be able to keep up or wind up being shut down. I’ve always been a big fan of Good Code Fast—deliver what the customer needs at the level of quality and design they expect but get it done quickly. If you can somehow deliver it fast, you have the ability to change and take advantage of those new things before someone else does.
The premise of Agile is to be able to move fast anyway, responding not only to changes in functionality but even in the development itself, and that’s hard for a lot of organizations to stomach. I know at my current job moving glacially and spending a fortune doing it is the norm. My current project will take 4-6 months but if I was writing it from scratch (it’s built on some complex older code I can’t do anything about) and skipping our heavyweight process it would be likely take 4-6 weeks. I am not going to have much fun.
Yet the pace of development will be getting faster still. Trying to make everything perfect and reusable and think of the code as a capital expense might result in you never shipping anything. Of course changing technologies every week might result in shipping nothing either! You have to find the right balance in every aspect of programming including process and management and team so you don’t drag stuff out too long but still find a way to deliver the right product and quality.
Today I see a lot of people want to slow down development and trying to build it perfect just once and sticking with it for a long term. After writing so much code in my life I am of the opposite opinion—if it makes sense, treat everything you write as short term and expect it will be replaced soon. This way you leave room for doing it better, doing it differently, doing it faster than your competition and even leave room for iterating on the whole project. It’s more scary but it’s also more fun. I’ve worked at companies of all sizes and there is no size where slow and cautious is more common than quick and risky. You can make good arguments for both but by my experience, quick is generally better as you have more flexibility and agility, as long as you have the team to make it work. But you can’t be nimble if your process is a black hole, your developers outsourced and your management needy for controlling everything.
The speed of change is getting crazy and it’s not going to stop because we are fearful. Best to find a way to deal with it. I may have been programming for 34 years (making me the old guy all the time now) but you’ll find me out front. It’s the only place you can see the future coming right at you without all those darn people in the way!