I reference it again, because it is great and it makes a lot of good points.
One thing it says is that 'Code Doesn't Age'. Specifically, Joel says this:
The idea that new code is better than old is patently absurd.
This is true in many senses: code doesn't get rusty, code doesn't wear out after the millionth time it's used, and you can make a thousand copies and this does not effect the code's quality in any way. Also, as he says, old code has been tested, where new code has not.
However, code can age, and I want to talk a bit about that and what it means to you. How can this ageless thing age? Here's how:
Code Doesn't Stand Alone - unless you have a very, very simple program, it is connected to lots of libraries and (today) APIs. These things don't stay the same, nor are they supported forever. So, your code doesn't physically get old, but sometimes the things that it relies on break, or they get changed, or they are killed off. When this happens, your code just got old, very fast.
Code Runs on Something - it used to be hardware, and deep inside of a data center somewhere that is still true. But even when we're only talking about VMs, VMs have operating systems and supporting code and those things aren't supported forever either.
Code is Written by People - and people don't write COBOL anymore. Or at least most people don't. People also don't write VB or C++ as much as they used to. Sometimes perfectly good technologies fall out of favor and everyone learns something new making your product hard to support.
It used to be, most of what I'm describing happened over a long period of time. COBOL didn't go away overnight, that took decades. But with things being more and more interconnected via APIs, and with more changes coming quickly to platforms and other programs, the pace of change is increasing.
APIs change all the time, which is great (Hooray for new features and better performance!) and also challenging (I have to make the changes by when?).
Sometimes things come and go quickly or you make a bad choice. Silverlight anyone?
So, code doesn't physically age, but it is dependent on things around it. Those things can change or break. If that happens, the code has to be kept up or it has to be refactored or (sometimes) you need to rewrite an application entirely because the people who built the original are all retired.
The good news - you get to build something great with new technology that leverages all the awesome things your old project did, but is new and shiny and fun to code.
The bad news - all the things in that article are still true. So, you need to plan for them.
ID-GEM is a new product we've just rolled out Amadeus. It's joint effort between a few groups (sales, estimation, software, marketing) within the company. It encapsulates and expands on our business development and requirements gathering process that we've been refining over the years. I also wrote a blog post about it for work here.
The core of the product is that software projects almost always fall into one of five categories, and if you spend the time up front to think about which category you're in and how you want to achieve your goals, you can have a great framework for making crucial decisions down the road as your product or project moves through its life cycle. Here are the categories:
Capturing Market Share
Revenue (Increase/Create) B2C
Revenue (Increase/Create) B2B
Reduce Costs or Increase Efficiency
Improve Community or Well-Being of Users
We looked back over 20 years of consulting to determine these categories, as well as what we felt were the most telling, challenging, and crucial questions for projects to wrestle with at the beginning. This enables you to have the right answers in place when things get challenging down the road. The questions can be quite different depending on which of the categories you fall into.
If you are considering a software venture of some kind, you should take a look. It's free and easy to use.