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.
We're currently having some discussion about what to call this process (Rewrite? Rebuild? Re-engineer?) On the new Exadel website. I'm partial to Rebuild, but I think that Re-engineer is likely to win.
In my relentless pursuit of information on this topic, I'm compiling a list of articles related to it.
In spite of being out of fashion, many of us are asked (often for very good business reasons) to provide them.
Right or wrong, there are situations where you should not provide an estimate. I learned these the hard way, here are the ones I know:
R&D work
Highly complicated things you've never done before (even if you're 99% sure you can do them).
Things you can't break down into small pieces
System integrations where you don't control the flow of development (A vendor needs you to attend 10 meetings and then they want to certify your 1 line of code.)
System integrations where the system is still being developed or tested (Here's a great question I've learned to ask over the years: 'How many other people have used this API before?').
Collaborative Development - two teams working together, especially for the first time.
Co-development - sometimes this manifests itself as #5, but it can be other things, like working with an outside vendor in a novel way on the same codebase.
Pretty much everything else is feature work and you can estimate that. It might be a little scary or intimidating, but you can.
I don't mean to suggest there is anything wrong with the things the 7 categories above. Those things can be very important work that needs to get done, and those things might be very fun work (if you can get it).
But, fun as it may be, you really shouldn't estimate it.
Here's what to do with those 7 items above - don't estimate them. Break them out into separate subsystems or budgets or categories. Whatever you use to segregate work, put them in their own place and create visibility to how the work is progressing.
Some clients/bosses won't like it, but they also won't like budget/timeline overruns with no explanation either.
Make it clear up front. Use your estimate (or non-estimate in this case) to communicate and set expectations. Then use it to reset them later if you need to.
Many bosses/clients will appreciate the effort you put into managing the simpler parts. And they'll appreciate that you understand how to separate more complex things from the typical or mundane.
It's definitely something you should consider when considering your approach to an application rebuild. It has a high value for risk mitigation.
I will definitely put this in the bag of tricks for approach on rebuild projects. I can see a lot of situations where it would be valuable.
I can also see a lot of clients who won't go for it, but that doesn't mean it isn't useful.
Even ruling it out as an approach will have value to many projects. Offering it allows you to say it was there, but removed from consideration. This will help make it clear that the large, monolithic project approach (and related challenges) was explicitly selected.
When building your city you should not view the city-design part as a way to solve your plumbing problems. Not if you want someone to live there, anyway.
Nor should you build a city for which plumbing cannot be designed.
But rather, in your dream, in your vision of what a city should be, consider that you will still need plumbing and it shouldn't cost a million dollars to fix a leaky faucet.
Beyond that, the plumbing shouldn't be much of a consideration, unless you are building a city for plumbers.
Jonathan Fries on .