Щоб складна програма мала шанси проіснувати довго, в неї спочатку мають бути закладені можливості для майбутнього розвитку.
Однією з головних умов здатності системи до розвитку є добре продумана модульна структура, в якій чітко визначені функції кожного модуля і його взаємозв'язку з іншими модулями. При цьому створюється можливість вдосконалення окремих модулів з мінімальним ризиком викликати небажані наслідки для інших частин системи.
Важливою вимогою до розвитку ОС є сумісність версій знизу вгору, що означає можливість безболісного переходу від старої версії до нової, без втрати раніше напрацьованих прикладних програм і без необхідності різкої зміни всіх навичок користувача. Зворотна сумісність - зверху вниз - як правило, не гарантується, оскільки в ході розвитку система здобуває нові можливості, не реалізовані в старих версіях. Програма з Windows 3.1 буде нормально працювати і в Windows XP; навпаки - навряд чи.
Фірми-виробники ОС докладають максимум зусиль для забезпечення сумісності знизу вгору, щоб не відлякати користувачів. Але при цьому фірми намагаються в кожну нову версію закласти якусь нову цукерку, яка спонукала б користувачів якнайскоріше купити її.
Сумісність версій - благо для користувача, однак на практиці вона часто призводить до консервації давно віджили свій вік особливостей або ж просто невдалих рішень, прийнятих в ранній версії системи. У документації подібні архаїзми позначаються як «застарілі» (obsolete), але повної відмови від них, як правило, не відбувається (а раптом десь ще працює прикладна програма, написана двадцять років тому з використанням саме цих коштів?).
Як правило, найбільш консервативної стороною будь-якої ОС є не алгоритми, а структури системних даних, тому далекоглядні розробники заздалегідь будують структури «на виріст»: закладають в них резервні поля, використовують змінні замість деяких констант, встановлюють кількісні обмеження з великим запасом і т.п .