I disagree with the author. Backwards compatibility is one of the great things about Microsoft's stuff, not a bad thing. In 6+ years at Loopt, an upgrade (to get new shiny features) never meant we had to stop using older code.<p>SQL 2012 is nearly completely[1] compatible with SQL 2005, and largely compatible with SQL 2000. IIS 7.5 will still run ASP code in VB from the early 2000s, and that code can live alongside ASP.net 1.1-4, or ASP.net MVC 1-3. In many cases, you can even have hybrid ASP/ASP.net/MVC combined applications.<p>There are often benefits that make revisiting your old code worthwhile, but rarely are you forced to. And we kept getting security updates back-ported the whole time.<p><pre><code> [1] http://technet.microsoft.com/en-us/library/ms143179(v=sql.110).aspx
[2] http://learn.iis.net/page.aspx/727/classic-asp-applications-on-iis-overview/</code></pre>
The financial people recognize that in most cases the value of an investment degrades over the time. If you pay $1M for new machinery, it will be worth lot less after five years.<p>In software we should have similar mentality and we should somehow turn this into numbers. If you don't touch your environment, the value keeps on going down - until it reaches zero. In order to keep the value, you need to constantly work on the environment. Patch operating, upgrade libraries, upgrade frameworks.<p>Each time you do a quick'n'dirty thing, you essentially increase your liabilities. Refactoring equals to decreasing those liabilities. If you would put numbers for these, you could actually create a balance sheet every year for your software.
> Although this backwards incompatible policy causes short term pain for developers on their platform, Apple made this conscious decision because in the long-term it leads to an overall healthier ecosystem.<p>From all evidence I've seen it's more likely they 1) don't care because people are willing to put up with it and 2) don't have the proper type of process/system/codebase/culture to allow such a move (and would rather spend that effort on something else).<p>One of Microsoft's top 3 selling points in the enterprise is backwards compatibility... They go as far as implementing run-time patches for 20 year old 3rd party DOS binaries that they don't have the source code to when they get crash reports in and it crosses a certain threshold.<p>> We only have to look at Microsoft's third-party ecosystem to see the alternative.<p>A developer that targets Windows breaks compatibility with a previous version of his software, then...? What does that have to do with Windows/Microsoft?
When you do a server side upgrade you are essentially doing an upgrade on behalf of every person who uses your product and it's sometimes difficult to roll-back. This is a really good reason to treat server side upgrades differently.<p>Once you are bit by a bad update you will be very shy about doing it again without a good cause. As an example, we updated to Recent Version - 1 of critical server software and had the thing crashing constantly thereafter. So then we upgraded to Recent Version and had a new bug that was introduced that was causing equal troubles. But now we were stuck and had to wait for next version to fix the bug. Made a really good case for not changing what works.
Ok, I had to laugh at 'spend 20% of your time on upgrading and refactoring'. That will never happen, especially in a small company where engineers are focused on innovation above all costs. At the end of the day, we're so busy pushing out new features that our clients couldn't care less what version of Python we're running on our servers.
As a former .NET guy, I have to take issue with the Microsoft devs chiming in about how great the .NET stack is for upgradeability.<p>Upgrading an ASP.NET web forms app to ASP.NET MVC is painful, and in many cases requires a full scale rewrite due to the high coupling of front and backend code in WebForms apps.<p>While Microsoft hasn't abandoned Web Forms, it's clearly behind the times in terms of modern web development and Microsoft isn't making much of an effort to bring it up to speed.<p>Comparing the upgrade of a Rails 2.3 app to 3.0 is a much better story IMO, and a far more realistic upgrade for even the largest apps.
Best practice is to keep 100% current on security patches (which are often delivered as backports to older/stable versions, e.g. by Debian).<p>Anything beyond that, and there are multiple schools of thought. One is to keep upgrading bleeding-edge in near realtime -- this keeps you ahead of a lot of known vulnerabilities, gets you access to features, etc., but imposes a cost in constantly fixing bugs.<p>Another is to do big batch upgrades periodically -- e.g. always updating to Ubuntu Stable within a month or two of release. This breaks more stuff all at once, and has periods of less current software being in production, but is a reasonable compromise.<p>Another is to deploy things once, get them working, and then leave them in place (with as few upgrades as possible) for as long as possible, then do what is basically a forklift upgrade as required. It has the lowest ongoing cost for maintenance. For something with extensive safety or security critical code which can only be audited and certified at great expense, this is commonly done -- but leads to nice tasty 0-day exploits working well against the most critical systems. It also leads to losing the organizational knowledge, resources, etc. to upgrade.
This would be a problem a couple of years ago, but I think it isn't anymore. Any startup can lease it's own webserver(s) (be it VPS, cloud or dedicated) for prices that were unimaginable even 5 years ago.<p>And best of all, most providers that are appealing to startups (Rackspace, Amazon EC2, Linode...) offer some kind of pay-what-you-use plans, so you can keep costs low at the beginning.
Amen. I'm writing a python script that'll install a demo version of our software on a Redhat system, and dealing with an outdated version of python makes things... unpleasant.
Updating server software is not rocket science. There are enough good webhosts out there that are doing a great job of keeping their servers up to date. Mind you, they are not the cheapest.<p>I also like to mention Parallels and their product Plesk that gets updated automatically without any problems; at least on our server.
I disagree. If it works once, it works. We're running on Rails 2.3, have been for two years, and have no plans to upgrade. I can't imagine any extra feature we'd need from the framework; if so, we build it ourselves. We've hacked Rails up to fit our needs, and I think that's the way it should be.