Pandangan baru pada pertanyaan kuno: haruskah aplikasi ditulis ulang dari awal atau apakah itu "kesalahan strategis terburuk yang dapat dilakukan oleh pengembang perangkat lunak"? Ternyata ketika bekerja dengan basis kode yang matang ada lebih dari dua pilihan jawaban.

"Kode sumber tampaknya berkarat !" - Joel Spolsky

Hampir dua dekade lalu, Joel Spolsky menggelar Netscape karena menulis ulang basis kode peramban dalam esainya yang terkenal "What You Can Never Do Do" . Dia sampai pada kesimpulan bahwa perangkat lunak yang berfungsi tidak boleh ditulis ulang dari awal . Dia punya dua argumen utama:

• Bagian basis kode yang tampak sampah sering kali mencakup pengetahuan yang diperoleh dengan susah payah tentang situasi perbatasan dan bug aneh.
  
• Perubahan total adalah perusahaan jangka panjang yang mengalihkan perhatian dari peningkatan produk yang ada, yang memberikan kartu truf kepada pesaing.

Bagi banyak orang, temuan Joel telah menjadi dogma; pada suatu waktu mereka memiliki pengaruh besar pada saya. Tetapi pada tahun-tahun berikutnya, saya menyadari bahwa dalam beberapa keadaan masih masuk akal untuk sepenuhnya mengulang produk. Sebagai contoh:

• Kadang-kadang basis kode yang sudah usang benar-benar tidak dapat dipulihkan, sehingga bahkan peningkatan sederhana memerlukan perubahan cascading di bagian lain dari kode.
  
• Solusi teknologi asli dapat mengganggu peningkatan yang diperlukan.
  
• Atau, teknologi asli mungkin sudah ketinggalan zaman, sehingga sulit (atau terlalu mahal) untuk mempekerjakan pengembang yang berkualitas.

Tentu saja, sebenarnya banyak tergantung keadaan. Ya, kadang-kadang masuk akal untuk secara bertahap refactor kode usang. Dan ya, terkadang masuk akal untuk membuang semuanya dan memulai dari awal.

Tapi ini bukan satu-satunya pilihan . Mari kita melihat enam cerita dan melihat pelajaran apa yang bisa dipelajari.

---

1. Netscape

Kode browser ditulis ulang tiga kali dari awal

Transisi bencana Netscape dari 5.0 ke 6.0 adalah kesempatan untuk artikel yang disebutkan sebelumnya oleh Joel Spolsky dan banyak yang yakin bahwa ini tidak boleh dilakukan.

Netscape Navigator dirilis pada tahun 1994, pada tahun-tahun awal Internet komersial. Dua tahun kemudian, perusahaan membuka era dot-com dengan IPO $ 3 miliar.

Pesaing utama Netscape yang pertama adalah Microsoft Internet Explorer, dirilis pada tahun 1996.

Pada awal 1998, Netscape masih merupakan browser terkemuka, tetapi dengan kesulitan besar. Netscape adalah program komersial yang dijual seharga $ 49, dan Microsoft membagikan IE secara gratis dan dikirimkan sebagai browser default di Windows.



Dengan rilis Netscape 4.0, perusahaan mengumumkan bahwa versi berikutnya akan gratis dan akan dikembangkan oleh komunitas open source, dibuat dan didanai oleh Mozilla. Untuk saat ini, ini pada dasarnya adalah langkah yang belum pernah terjadi sebelumnya, dan Netscape mendapatkan banyak pendukung untuk keputusan yang berani. Namun dalam kenyataannya, "komunitas" ini sebenarnya tidak terwujud. Jamie Zawinski, salah satu pengembang browser pertama, menjelaskan :

Yang benar adalah bahwa proyek Mozilla melibatkan sekitar seratus pengembang penuh waktu Netscape dan sekitar tiga puluh pengembang lepas, sehingga proyek itu masih sepenuhnya dimiliki oleh Netscape.

Tim sampai pada kesimpulan bahwa pengembang dari luar tidak tertarik pada proyek, termasuk karena kekacauan dalam basis kode:

Kode itu ternyata terlalu rumit dan membingungkan untuk diubah, jadi orang tidak berkontribusi ... Itu sebabnya kami beralih ke mesin baru. Basis kode yang lebih bersih dan segar yang lebih mudah dipahami dan bergabung dalam pengembangan.

Dari awal

Maka, setahun kemudian, grup ini memutuskan untuk meninggalkan 5.0 tanpa merilis rilis, dan mulai mengembangkan versi 6.0 dari awal.

Persiapan Netscape 6.0 memakan waktu dua tahun penuh; dan bahkan setelah semua ini, jelas bahwa peramban itu mentah. Menurut kolumnis New York Times, David Pog, browser berjalan selama satu menit penuh (!) Dan menghabiskan RAM. Itu tidak memiliki sejumlah fitur kegunaan sederhana yang ada di versi sebelumnya:

Fungsi pratinjau cetak telah hilang, serta kemampuan untuk menyeret ikon alamat situs langsung ke menu bookmark. Selain itu, Anda tidak dapat menyalin atau menempelkan alamat web ke bilah alamat dengan mengklik kanannya. Dan setiap kali di awal pekerjaan Anda harus mengubah ukuran jendela: Navigator tidak ingat keadaan sebelumnya. Tetapi kekurangan yang paling tidak menyenangkan adalah Anda tidak dapat memilih seluruh bilah alamat dengan satu klik.

Tapi itu hampir tidak relevan, karena dalam tiga tahun Netscape berdiri diam, Internet Explorer merebut pangsa pasar yang tersisa:


Ketika pemurnian peramban dimulai, Netscape dengan cepat kehilangan tanah ke Microsoft Internet Explorer. Browser baru keluar tiga tahun kemudian, itu buggy dan lambat; dan pangsa pasar Netscape, sementara itu, turun ke hampir nol (grafik diadaptasi dari Wikipedia )

Pada tahun 1999, ketika perancangan ulang browser berjalan lancar, AOL mengakuisisi Netscape sebesar $ 10 miliar. Hanya dua tahun setelah rilis Netscape 6.0, divisi AOL Netscape dilikuidasi.

Mozilla, komunitas open source yang dibuat oleh Netscape, akan terus ada dan meluncurkan browser Firefox pada tahun 2002, proyek clean-sheet lainnya. Firefox berhasil mengembalikan beberapa pengguna yang pergi ke Microsoft.

Tetapi Netscape, sebagai sebuah bisnis, telah mati (Microsoft akan mengubur sisa-sisa kekayaan intelektual Netscape sebagai hasil dari kesepakatan 2012 dengan AOL).

Setelah memenangkan pertempuran ini, Microsoft menolak untuk berinvestasi dalam teknologi browser. Internet Explorer 6.0 dirilis pada tahun 2001 dan belum diperbarui selama lima tahun . Beberapa menganggap ini sebagai upaya yang disengaja untuk memblokir promosi Internet sebagai platform untuk aplikasi.

Kesimpulan

Beberapa percaya bahwa menulis ulang dari awal bukanlah bencana. Pada akhirnya, berkat ini, mesin Gecko dan browser Firefox akhirnya muncul.

Tetapi kita semua harus mengalami stagnasi bertahun-tahun dalam teknologi web di bawah monopoli IE6 yang tak berkesudahan , sementara kami menantikan browser baru yang menggerakkan kehidupan ke dalam industri. Dan akhir era IE6 tidak dimasukkan oleh Firefox, tetapi Google Chrome.

Bagaimanapun, ini bukan tentang bagaimana proyek mempengaruhi Internet. Ini tentang apa hasilnya bagi perusahaan. Kematian Netscape tidak dapat disalahkan atas alasan ini: pengadilan setuju bahwa Microsoft sengaja menyalahgunakan monopoli. Tetapi tentu saja, keputusan untuk menulis ulang semuanya dari nol adalah faktor penting dan mengarah pada hasil akhir: penghancuran sebuah perusahaan bernilai miliaran dolar dan ribuan PHK. Karena itu, saya setuju dengan Joel bahwa konsekuensi bersih dari keputusan ini adalah bencana .

---

2. Basecamp

Pada awal 2000-an, studio desain web yang berbasis di Chicago bernama 37signals menjadi terkenal karena blognya yang berpengaruh dan sering kontroversial, didirikan oleh pendiri Jason Fried dan DHH .

Ketika saya pertama kali mulai melakukan desain web, mereka menarik perhatian saya dengan serangkaian artikel dengan contoh-contoh desain yang salah dan opsi untuk bagaimana membuat kembali mereka untuk situs-situs seperti Google dan PayPal. Proyek itu disebut 37better .




Desain ulang formulir pengiriman 37 sinyal FedEx (di atas) masih lebih baik daripada desain sebenarnya , hampir dua dekade kemudian

Perusahaan memiliki sistem manajemen proyek untuk penggunaan internal , yang dirilis pada tahun 2004 sebagai layanan SaaS yang disebut Basecamp .

SaaS masih baru pada saat itu. Alat manajemen proyek dijual dalam kotak dengan label harga empat digit dan buku manual yang berat. Mereka semua bekerja pada konsep pemodelan jalur kritis dan menggambar grafik Gantt yang kompleks. Basecamp dijual seharga $ 50 sebulan dan menghirup udara segar dengan antarmuka yang sangat sederhana dan fokus pada komunikasi.

Maju cepat beberapa tahun, Basecamp memiliki setengah juta pengguna yang bahagia, pembayaran tiba setiap bulan, tetapi Jason dan David mulai khawatir.

Beberapa tahun yang lalu, David menceritakan kisah ini di konferensi Business of Software . Dia mengakui bahwa dia dipengaruhi oleh Joel Spolsky dan percaya bahwa menulis ulang perangkat lunak akan membunuh perusahaan. Selain itu, ada elemen tertentu dari rasa puas diri dan kebenaran diri sehubungan dengan popularitas gerakan Agile:

[Saya] benar-benar asyik dengan ide perangkat lunak transendental ... Kode yang sangat fleksibel. Warisan yang sangat berharga. Anda dapat mengubah apa pun, menulis ulang program apa pun, kode apa pun ... Jika perangkat lunak sulit diubah, itu adalah kesalahan Anda sendiri. Anda adalah programmer yang buruk, jadi Anda perlu meningkatkan.

Namun, setelah "tujuh tahun yang gemuk" perusahaan menemukan dirinya dalam kesulitan - dan masalahnya tidak ada hubungannya dengan utang teknis .

Borgol emas

Semuanya dimulai dengan fakta bahwa para pria memperhatikan kurangnya antusiasme. Tidak hanya tidak ada motivasi yang cukup untuk mengerjakan produk unggulan, tetapi mereka sendiri tidak secara khusus menggunakan program mereka.

Mereka memiliki banyak ide tentang bagaimana membuat produk secara fundamental lebih baik, tetapi setiap perubahan akan mengganggu alur kerja biasa dari ratusan ribu pengguna Basecamp. Masalahnya bukan pada basis kode yang kompleks, tetapi pada pengguna.

Karena keinginan untuk menyenangkan pelanggan yang sudah ada, produk berhenti dalam pengembangan, yang mencegah menarik pengguna baru. Ini tidak secara langsung mengancam bisnis, tetapi menimbulkan ancaman jangka panjang. DHH secara metaforis membandingkan situasi dengan ember bocor:

Anda dapat menyumbat semua lubang, memperbaiki semua kesalahan, memperbarui semua fungsi yang dikeluhkan pelanggan - tetapi sebagian air selalu mengalir keluar. Klien meninggalkan pekerjaan dan meninggalkan perangkat lunak, bahkan jika mereka [menyukainya]. Anda mungkin disesatkan: “Hei, ember lebih dari setengah penuh. Hanya ada lubang kecil, hanya kebocoran kecil, itu benar-benar alami. " Tapi, jika situasinya berlanjut, ember akan benar-benar kosong.

Sebagian dari masalahnya adalah Anda terus-menerus mendengarkan pelanggan saat ini, tetapi tidak mendengar yang berikutnya:

Orang-orang yang mengunjungi halaman Basecamp pada tahun 2011 dan menolak untuk membeli produk karena tidak lagi cocok untuk mereka: bagaimana menurut Anda, seberapa sering kita mendengarkan pendapat mereka? Tidak pernah. Kami hanya mendengarkan sejumlah besar pelanggan yang sudah ada yang benar-benar ingin kami terus menyumbat lubang kecil ini.

Pengembang mulai mempertimbangkan produk yang menguntungkan sebagai sepasang borgol emas:

Hal utama adalah memastikan bahwa semua pengguna saat ini puas. Uang datang setiap bulan, cek baru, cek baru, cek baru. Bagus Tetapi kemudian menjangkau dan mengakui: "Itu saja, saya tidak akan pernah mengubah perangkat lunak saya lagi."

Spoiler: Basecamp ditulis ulang dari awal, dan ternyata hebat. Butuh waktu sekitar satu tahun, dan segera setelah rilis Basecamp 2, jumlah pendaftaran baru berlipat ganda.

Saya pikir mereka melakukan dua hal utama.

Pertama, mereka tidak mencoba membuat kembali produk lama - karena pertama-tama mereka ingin menerapkan ide-ide baru tentang cara mendekati solusi dari masalah yang diselesaikan oleh produk lama.

Apakah kita terlalu lancang untuk berpikir bahwa ide-ide tahun 2003 masih merupakan ide terbaik tahun 2011? Ya, saya dituduh sombong, tetapi semua keluar pada tahun 2008.

Dengan demikian, mereka memperkenalkan Basecamp 2 sebagai produk yang sepenuhnya baru, tanpa jaminan yang kompatibel dengan Basecamp Classic. Banyak hal baru muncul, sesuatu benar-benar hilang, dan banyak yang berubah sepenuhnya.

Keputusan ini memberikan tingkat kebebasan tertentu. Kebebasan memotivasi, dan orang yang termotivasi bekerja lebih baik.

Kurangnya kebutuhan untuk mendukung setiap opsi untuk menggunakan produk asli membantu. Misalnya, Basecamp asli memungkinkan Anda untuk meng-host dokumen di server FTP Anda sendiri. Pengembang menghapus ini dan fungsi serupa lainnya yang dulu masuk akal, tetapi sekarang terpinggirkan. Pengurangan dalam fungsi yang tidak perlu itu memungkinkan untuk membawa produk baru ke pasar dalam waktu yang wajar.

Matahari terbenam dianggap berbahaya

Tetapi bagaimana dengan ratusan ribu pengguna yang ada yang memiliki mainan favorit mereka diambil? Ini membawa kita pada hal menarik kedua yang dilakukan pengembang: mereka menyimpan produk lama .

David sangat menyukai istilah "perangkat lunak matahari terbenam":

Seseorang di suatu tempat muncul dengan eufemisme indah yang disebut "matahari terbenam" ... Sebut penghancuran perangkat lunak "matahari terbenam" ... Seperti, semua pengguna berada di pantai - dan mereka menyaksikan dengan emosi bagaimana informasi mereka menghilang. Ini bagus!

Satu-satunya orang yang percaya pada "matahari terbenam" adalah mereka yang menyebutnya begitu. Tidak ada satu pun pengguna yang pernah benar-benar melewati periode matahari terbenam kembali dan berkata, "Oh, itu indah." Mereka kembali dan berkata, “Sial! Saya menempatkan tahun kerja di sini! .. Dan sekarang Anda akan menggulung saya ?! ”

Dia mencatat bahwa memaksa orang untuk berkemas dan pindah adalah "kesalahan strategis terburuk" karena Anda memaksa semua pelanggan reguler untuk membuat keputusan, terus menggunakan perangkat lunak Anda, atau beralih ke yang lain.

Apakah Saya Sangat Membutuhkan Basecamp? Jika Anda masih harus mentransfer semua sampah, mungkin mentransfernya di tempat lain. Jika Anda perlu mengemas barang-barang ke dalam kotak dan memuatnya ke dalam truk, saya bisa mengirimkan truk ini ke kota. Bukan masalah besar. Masalah besar adalah mengepak semua manat. Dan ke mana harus pindah, lagi ke Basecamp atau ke tempat lain, ini adalah masalah sekunder.

David membandingkan Basecamp Classic dengan Leica M3: kamera belum diproduksi sejak 1967, tetapi Leica berjanji untuk memelihara dan memperbaikinya sampai akhir hari-harinya (foto: Dnalor 01 )

Sebaliknya, Basecamp berjanji untuk "menghormati warisannya" : mereka menyederhanakan upgrade ke versi baru, tetapi tidak menuntut untuk meninggalkan Basecamp Classic. Selain itu, mereka berjanji untuk mempertahankan Basecamp Classic selamanya.

Leluconnya adalah bahwa setelah empat tahun mereka melakukannya lagi: pada 2015, Basecamp 3 dirilis, lagi ditulis ulang dari awal, dengan beberapa fitur baru dan tanpa yang lama, dan sekali lagi banyak yang telah berubah. Seperti sebelumnya, pengguna versi lama dapat dengan mudah memutakhirkan. Tetapi jika mereka mau, mereka dapat terus menggunakan Basecamp Classic atau Basecamp 2 "hingga akhir Internet."

Basecamp 3 tidak akan menggulung apa pun. Bukan versi saat ini, bukan versi Basecamp klasik dan asli. Apakah semua ini bekerja dengan baik untuk Anda? Keren! Silakan terus menggunakannya sampai akhir Internet! Kami memastikan bahwa program tetap cepat, aman dan selalu dapat diakses.

Tetapi ada banyak "tetapi." Bukankah itu mahal? Apakah dukungan multi versi membutuhkan banyak usaha? Bagaimana dengan keamanan? Bagaimana dengan basis kode yang ketinggalan zaman? Apa yang bisa saya katakan. Kami hanya peduli dengan pelanggan, bahkan jika mereka tidak ingin diperbarui sesuai dengan jadwal kami.

Kesimpulan

Secara pribadi, model ini sepertinya sangat menginspirasi saya.

Setiap perubahan memungkinkan Basecamp untuk melihat ke belakang dan membuat kembali produk berdasarkan pengalaman. Untuk pengguna, ini adalah permainan win-win: konservatif menyimpan mainan mereka; dan inovator yang dihadapkan pada keterbatasan sistem mendapatkan aplikasi baru dan, saya harap, lebih bijaksana.

Tentu saja, mendukung banyak versi untuk waktu yang lama tanpa batas ada harganya; tetapi seperti yang dikatakan Daud:

Ini tidak gratis. Tentu saja tidak. Ini adalah produk yang berharga dan tentu saja, dukungan tidak gratis. Tapi itu sepadan.

---

3. Visual Studio & Kode VS

Catatan: Ikon Hipster

Microsoft membuat VS Code untuk menjangkau pengembang di platform lain.

Anda harus ingat bahwa untuk waktu yang lama, Microsoft telah menawarkan "semua atau tidak sama sekali." Jika Anda menggunakan Visual Studio, maka Anda harus bekerja di .NET, dan sebaliknya. Ini membagi komunitas perangkat lunak menjadi dua kubu besar, sebagian besar saling eksklusif - yang merugikan semua orang.

Banding ke cowok keren

Situasi mulai berubah kembali di tahun-tahun Steve Ballmer: ingat betapa keras keputusan pengembang ASP.NET untuk tidak menciptakan jQuery menjadi!

Salah satu tugas utama CEO Satya Nadella adalah menghubungi pengembang di luar "taman berpagar" nya.

Tapi ada masalah. Inilah yang dikatakan Julia Lewson, wakil presiden Visual Studio dalam edisi podcast The Changelog :

Kami tidak dapat menawarkan seluruh kelas pengembang: modern, berorientasi web, yang bekerja dengan Node dan JavaScript - kami tidak memiliki apa pun untuk dibicarakan dengan mereka. Kami tidak bisa menarik pengembang ini.

Jadi Kode VS diciptakan untuk memecahkan penghalang itu dan berkata, “Benar-benar tahu apa, teman-teman? Kami masih memiliki sesuatu yang berguna untuk Anda. "

Visual Studio adalah produk kelas berat dalam segala hal: hanya pemasangan yang bisa memakan waktu lebih dari setengah jam. Ini mendukung berbagai kasus penggunaan kompleks yang diandalkan oleh pelanggan korporat. Dengan demikian, tidak ada gunanya mengambil Visual Studio sebagai titik awal dan menambahkan fitur dalam proyek baru di platform lain. Dan jelas, gagasan merilis Visual Studio untuk Mac atau Linux tidak terlalu didukung.

Oleh karena itu, Microsoft memulai dari awal, tanpa jaminan kompatibilitas ke belakang.

Sebenarnya, tidak dari awal: Microsoft sudah memiliki beberapa bagian penting, seperti editor Monaco di browser. Dan karena VS Code adalah aplikasi Node.js (ditulis dalam Scriptres dan diluncurkan dalam Elektron), mereka mengambil keuntungan dari sumber daya yang kaya dari ekosistem JavaScript.

Open Source VS Code, ringan, cepat, dapat dikembangkan - secara mengejutkan untuk produk Microsoft - telah menjadi alat pemrograman yang trendi untuk generasi muda lanjut.


VS Code menjadi editor utama untuk JS-hipsters (diagram dari laporan State of JavaScript Survey, 2018 )

Kedua produk masih dalam pengembangan aktif, dan tidak ada indikasi bahwa Microsoft bermaksud untuk menutup Visual Studio.

Kesimpulan

Tidak seperti Netscape, Microsoft benar-benar berhasil membuat komunitas open source aktif di sekitar VS Code. Ini telah meningkatkan upaya pengembang untuk meningkatkan produk.


Dari semua proyek open source, Visual Studio Code berada di peringkat ke-13 dalam hal jumlah bintang di GitHub - secara kebetulan, tepat di bawah Linux!

Tentu saja, tidak setiap perusahaan dapat membiarkan produk utamanya tersedia secara bebas. Tetapi jika open source adalah bagian dari strategi pengembangan Anda, masuk akal untuk membandingkan kisah Microsoft dan Netscape - dan mencari tahu apa yang dilakukan Microsoft secara berbeda sehingga komunitasnya berkembang.

Faktor penting lainnya: Microsoft telah menyediakan VS Code dengan model ekstensibilitas berkualitas tinggi , sebagai akibatnya komunitas telah menulis sekitar 10.000 ekstensi.

Salah satu kesimpulan terakhir dari sejarah VS Code adalah bahwa selama beberapa tahun terakhir, semuanya telah berubah secara dramatis: saat ini lebih mudah dari sebelumnya untuk membuat prototipe dan perangkat lunak .

Terlepas dari keluhan tentang kerumitan alat modern , ekosistem JavaScript selama beberapa tahun terakhir telah berevolusi menjadi surga sejati modul sumber terbuka. Dalam hal ini, sekarang adalah waktu yang secara historis belum pernah terjadi sebelumnya.

---

4. Gmail dan Kotak Masuk

Catatan: Ikon

Inbox for Gmail sunset awalnya diperkenalkan sebagai alternatif minimalis UX untuk Gmail, "dengan fokus pada apa yang sebenarnya penting." Dia tidak pernah mencoba mencocokkan fungsionalitas Gmail asli, dan memperkenalkan fitur-fitur baru: grup tematik (bundel), pin yang disematkan, dan pesan yang tertunda.

Beberapa pengguna, termasuk saya, menerima Inbox dengan antusias. Saya selalu berpikir bahwa Kotak Masuk adalah demo tentang bagaimana nantinya Gmail akan menjadi, jadi saya tahan dengan sedikit nuansa Gmail, berharap mereka akhirnya sampai ke Kotak Masuk.

Dua antarmuka, satu layanan

Kotak masuk dan Gmail berfungsi pada backend yang sama. Bahkan, ini hanya antarmuka pengguna yang berbeda untuk layanan yang sama, dan Anda dapat beralih bolak-balik sesuai keinginan. Ini memiliki kelebihan dan kekurangannya: jika Kotak Masuk tidak memiliki fungsi (katakanlah, mesin penjawab untuk liburan), Anda selalu dapat kembali ke Gmail dan mengonfigurasi apa yang Anda butuhkan, meskipun beralih bolak-balik sepertinya aneh.

Namun, setelah beberapa saat, Inbox berhenti membaik - menjadi jelas bahwa Google tidak lagi menginvestasikan sumber daya di dalamnya. Secara alami, empat tahun setelah diluncurkan, Google mengumumkan sunset Inbox .



Seperti orang lain, pada awalnya saya marah dengan keputusan seperti itu. Tetapi setelah menghabiskan sedikit waktu dengan versi terbaru Gmail, saya menemukan bahwa banyak fitur Kotak Masuk favorit saya telah diangkut ke produk asli : jawaban yang cerdas, tindakan yang melayang-layang, lampiran bawaan dan gambar. Beberapa kotak surat Gmail cukup baik menggantikan grup tema Kotak Masuk.

Tetapi tidak semua dari Kotak Masuk ditransfer ke Gmail: misalnya, orang-orang begitu terbiasa dengan "mode jeda" (tunda) sehingga tanpa itu mereka benar-benar menderita secara fisik.

Kesimpulan

Kotak masuk memungkinkan pengembang Gmail untuk bereksperimen dengan fitur tanpa mengganggu alur kerja sebagian besar pengguna.

Namun, dengan melayani kedua versi di backend yang sama , Gmail telah memberikan batasan keras pada inovasi .

Sekali lagi, Google telah banyak dikritik karena menutup layanan populer. Tentu saja, Google secara permanen menutup nya proyek , sehingga tidak ada yang tak terduga.

Namun dalam hal ini, sikap awal Google terhadap Kotak Masuk membuat kami percaya bahwa kami memiliki demo tentang masa depan Gmail. Seperti yang akan dikatakan DHH, matahari terbenam tampak buruk: banyak orang merasa tidak nyaman untuk kembali ke produk lama dan kehilangan alur kerja inovatif Inbox.

Saya pikir bagi banyak orang, transisi akan jauh lebih mudah jika, sebelum menutup Kotak Masuk, semua fungsinya terintegrasi ke dalam Gmail.

---

5. FogBugz & Trello

Catatan: Lencana

FogBugz dan lencana "uang, uang, uang" adalah kasus yang sangat menarik, karena ini adalah produk dari Joel Spolsky sendiri: itu memberikan gagasan tentang bagaimana prinsip "tidak pernah menulis ulang" dihadapkan dengan kehidupan nyata.

Sebelum munculnya Masalah Jira dan GitHub, ada sistem pelacakan tiket berbasis web yang disebut FogBugz. Dirilis pada tahun 2000, sistem ini adalah produk pertama dari perusahaan Fog Creek Software yang baru, yang didirikan Joel dengan Michael Prior. Dan selama lebih dari satu dekade, FogBugz tetap menjadi produk andalan mereka. Awalnya, itu hanya dijual sebagai versi kotak untuk instalasi di server sendiri, tetapi kemudian opsi SaaS dengan pembayaran berlangganan dirilis.

FogBugz telah menjadi sangat populer, terutama di kalangan pengembang yang, dalam contoh saya, membaca blog Joel dan menerima nasihatnya dengan sepenuh hati. Perusahaan saya menggunakan sistem ini selama bertahun-tahun, itu adalah produk yang hebat pada masanya.

FogBugz awalnya ditulis di ASP klasik, yang bekerja pada server Windows. Ketika ASP.NET keluar, Joel menjelaskan mengapa ia tidak terburu-buru untuk memperbarui .

Untuk menginstal FogBugz di server Linux, intern perusahaan menulis kompiler Thistle untuk mengkonversi ASP klasik ke PHP. Pada 2006, Thistle telah tumbuh menjadi bahasa pemrograman berpemilik yang disebut Wasabi, yang dikompilasi menjadi ASP, PHP, dan JavaScript sisi klien.

Kisah aneh Wasabi

Saat ini, mengembangkan bahasa pemrograman dan kompiler milik Anda sendiri, katakanlah, merupakan pilihan yang eksentrik. Jadi menarik untuk melihat bagaimana semua itu terjadi.

Pada satu titik, Joel menyebut Wasabi di salah satu posting blognya. Beberapa orang mengira itu adalah lelucon, jadi dia menjelaskan bahwa itu bukan lelucon . Jeff Atwood, seorang sesama blogger, meniup kepalanya dari berita ini:

Menulis dalam bahasa Anda sendiri benar-benar di luar batas. Ini adalah solusi beracun yang sangat bertentangan dengan kiat pengembangan perangkat lunak Joel yang sangat baik dan kuat sebelumnya sehingga orang benar-benar berpikir ia sedang bercanda.

Joel bersikeras bahwa keputusan itu masuk akal dari perspektif bisnis. Tentu saja, secara teoritis tidak ada gunanya menemukan bahasa Anda sendiri, tetapi jika Anda mengevaluasi setiap langkah kecil menuju keputusan seperti itu, mengingat konteks teknologi dan basis kode, maka semuanya tampak logis.

Berkaca pada Wasabi dalam esai substansial berjudul "Hutang Teknis dan Pencarian Angin," mantan insinyur Fog Creek Ted Unangst membandingkan proses untuk bepergian tanpa peta:

Bayangkan Anda berada di Savannah, Georgia, dan Anda ingin pergi ke London, Inggris. Anda tidak memiliki peta, hanya rasa arah yang samar-samar ... Anda tidak pergi dalam garis lurus karena Anda tidak memiliki perahu, tetapi lautan di depan Anda. Namun di sisi lain, pantai yang menyenangkan mengarah ke timur laut, dan ini kira-kira ke arah yang benar. Anda berjalan di sepanjang pantai, berjalan dan berjalan. Waktu berlalu. Anda melihat dan melihat bahwa dengan setiap langkah semakin dekat ke tujuan, meskipun Anda tidak bergerak ke arah itu secara langsung.

Di suatu tempat di Boston, atau di Nova Scotia, Anda akhirnya berhenti dan memikirkan pilihan Anda. Mungkin jalan ini tidak mengarah ke London? Jauh dari galeri Anda bisa mendengar tawa: “Ha ha ha, lihatlah orang-orang bodoh ini. Mereka tidak melihat perbedaan antara Inggris dan New England. Berikan orang-orang bodoh ini peta. ” Tapi ini justru masalahnya: Anda tidak punya kartu. Peta dibuat oleh orang-orang yang hampir secara definisi tidak tahu ke mana mereka pergi.

Dalam kasus apa pun, jelas Jacob Krall, mantan pengembang Fog Creek lainnya, solusinya mengorbankan pemeliharaan besok untuk kecepatan pengembangan saat ini. Dan pada 2010, akun utang ini mulai berdatangan.

Kami tidak memasukkan [Wasabi] ke sumber terbuka, jadi kami mengeluarkan biaya sendiri, karena produk-produk utama kami yang menguntungkan ... Itu adalah ketergantungan besar yang membutuhkan pengembang permanen untuk produk ini saja: tidak murah untuk perusahaan seukuran kami. Terkadang kompiler mengutuk sepotong kode yang terlihat cukup masuk akal untuk seseorang. Dia perlahan menyusun. Visual Studio tidak dapat dengan mudah mengedit atau menghubungkan debugger ke FogBugz ... Semua karyawan baru pertama kali dilatih oleh Wasabi, terlepas dari pengalaman mereka sebelumnya ... Selain itu, kami tidak hidup dalam ruang hampa. Bahasa pemrograman, tentu saja, telah meningkat di luar Fog Creek ... Para pengembang mulai merasa bahwa ide-ide cemerlang mereka dihadapkan pada keterbatasan alam semesta Wasabi kecil kami.

Titik belok

Pada saat itu, FogBugz sudah berusia sepuluh tahun: itu adalah produk yang matang dan stabil. Sebagai proyek sampingan, Joel meluncurkan Stack Overflow bersama-sama dengan Jeff Atwood (jelas, kepala Jeff yang tertiup angin berhasil sembuh pada saat itu).

FogBugz secara bertahap menua. Meskipun pasar pelacak bug tetap terfragmentasi, Jira milik Atlassian, yang muncul beberapa tahun setelah FogBugz, muncul ke permukaan. Ini telah menjadi pilihan default, terutama bagi pengguna perusahaan besar.

Sangat menarik untuk melihat titik perubahan khusus ini dalam sejarah FogBugz. Seperti Basecamp, mereka memiliki produk yang menguntungkan dan matang. Ya, tidak lagi modis dan mungkin tidak terlalu menarik untuk dikerjakan. Baik atau buruk, itu menggabungkan perubahan teknologi bertahun-tahun dan ide-ide baru tentang bagaimana menyelesaikan satu masalah spesifik: melacak bug.

Tentu saja, ada opsi Basecamp: dengan mempertimbangkan semua pengalaman, ambil dan tulis ulang FogBugz dari awal. Saya kira ide ini tidak berjalan terlalu jauh, karena kita ingat: "apa yang tidak pernah bisa dilakukan", "kesalahan strategis terburuk" dan seterusnya dan seterusnya.

Saya baru-baru ini menarik perhatian artikel 2009 yang ditulis Joel untuk Inc. Majalah Kolom penulisnya berjudul "Apakah pertumbuhan lambat berarti kematian lambat?" nadanya benar-benar tidak seperti kemegahan percaya diri yang biasa: nadanya terdengar introspektif, tidak pasti, penuh dengan keraguan. Joel khawatir tentang pertumbuhan Atlassian yang cepat, membahas apakah ada ruang untuk beberapa pemain di pasar.

Saya harus berpikir. Kami memiliki pesaing besar yang tumbuh jauh lebih cepat daripada kami. Perusahaan menutup kesepakatan besar dengan klien korporat besar ... Sementara itu, produk kami jauh lebih baik dan kami adalah perusahaan yang dikelola dengan baik, tetapi itu tampaknya tidak masalah. Mengapa

Dia memutuskan untuk melakukan dua hal. Pertama, tambahkan semua fitur ke FogBugz :

Tugas tim pengembangan untuk tahun 2010 adalah menghilangkan alasan yang memungkinkan mengapa pelanggan dapat membeli sampah dari pesaing kita hanya karena ada beberapa fungsi kecil yang mereka anggap benar-benar tidak dapat hidup tanpanya. Sejujurnya, saya tidak berpikir itu akan sangat sulit.

Kedua, buat tim penjualan korporat . Joel mengakui bahwa dia tidak kuat di sini, dan merasa tugas ini tidak menyenangkan.

Saya tidak tahu cara kerja langkah-langkah ini. Joel terakhir menyebut FogBugz di blognya pada Mei 2010 , secara singkat mengumumkan versi baru.

Harapan baru

Dan inilah yang terjadi:

Di bidang peringatan kesepuluh Fog Creek Software, saya mulai berpikir: untuk menjaga agar karyawan kami termotivasi selama sepuluh tahun lagi, kita perlu mulai mengerjakan sesuatu yang baru.

Oleh karena itu, mereka dibagi menjadi dua tim, yang masing-masing membuat prototipe produk baru. Gagasan yang menang dibuat dalam semangat papan kanban - papan offline nyata yang sering digunakan dalam proyek pengembangan perangkat lunak: biasanya terlihat seperti catatan yang disusun dalam kolom di papan.

Joel memperkenalkan program ini sebagai alat manajemen di tingkat yang lebih tinggi daripada FogBugz:

Jujur, dengan semua perangkat lunak mewah untuk "manajemen proyek" ini, saya tidak pernah bisa melacak dengan benar siapa yang mengerjakan apa ... Sebagai pendiri dua perusahaan, saya berjalan di sepanjang koridor dan melihat lusinan orang yang dibayar untuk duduk di depan komputer ... dan saya tidak tahu apakah mereka melakukan pekerjaan mereka dengan benar atau apakah mereka menganggap penting apa yang sebenarnya tidak penting.

Saat membuat Trello, pengembang Fog Creek mendapat kesempatan untuk menggunakan teknologi modern:

Kami menggunakan teknologi canggih, jadi bukan tanpa pengorbanan. Luka pengembang kami tersebar di seluruh MongoDB, WebSockets, CoffeeScript, dan Node. Tapi sekarang mereka tertarik. Di pasar tenaga kerja yang sibuk saat ini, programmer yang berbakat banyak memutuskan tentang apa yang ingin mereka kerjakan. Jika Anda memberi mereka produk yang menarik ... mereka akan menyukainya dan mereka akan menyukai perusahaan mereka.

Trello mendukung plugin sejak awal, sehingga pengembang pihak ketiga mulai membantu:

Plugin dan API memiliki prioritas tertinggi ... Jangan pernah membuat produk sendiri jika Anda dapat memberikan API dasar, dan pengguna yang berharga ... akan membuatnya untuk Anda. Ada aturan untuk tim Trello bahwa jika ada fungsi yang dapat diimplementasikan melalui plug-in, maka itu harus diimplementasikan dengan cara ini.

Pemrogram, tentu saja, segera memahami manfaat Trello, tetapi tidak ada yang spesifik dalam alat untuk pengembangan perangkat lunak tertentu. Joel menggambarkan Trello sebagai alat yang berguna untuk "segala sesuatu di mana Anda ingin berbagi daftar dengan orang lain." Segera Trello mulai terbiasa mengatur segalanya secara berurutan: dari makan malam mingguan hingga pernikahan dan tempat penampungan anjing .

Sementara FogBugz adalah produk vertikal yang berorientasi pada ceruk pasar tertentu - Trello adalah produk horizontal yang cocok untuk apa pun. Joel menganggap "gerakan horizontal" Fog Creek benar pada saat itu:

Hampir mustahil untuk membuat produk horizontal besar, berguna di semua bidang. Itu tidak bisa mahal, karena Anda bersaing dengan produk horisontal lainnya yang dapat menyerap biaya pengembangan Anda untuk sejumlah besar pengguna. Ini adalah risiko tinggi dan hadiah tinggi: jalur ini tidak cocok untuk startup muda, tetapi ide yang bagus untuk produk kedua atau ketiga dari perusahaan yang matang dan stabil seperti Fog Creek.

Untuk dengan cepat skala ke sejumlah besar pengguna, Trello awalnya ditawarkan secara gratis. Kemudian memperkenalkan rencana bisnis .

Pada 2014, Trello dipilih sebagai perusahaan independen. Tiga tahun kemudian, itu terjual lebih dari $ 425 juta dengan lebih dari 17 juta pengguna. Ironisnya, pembelinya adalah Atlassian, musuh lama Fog Creek.

Sementara itu, kami akan kembali ke rumah ...

Fog Creek terus mengembangkan produk baru lainnya, lingkungan pemrograman kolaboratif yang disebut HyperDev , yang kemudian berganti nama menjadi GoMix dan kemudian Glitch .

Pada saat yang sama, sistem FogBugz membeku dalam ketidakjelasan. Pada tahun 2017, seseorang memutuskan bahwa FogBugz adalah nama yang konyol, dan upaya rekayasa berubah menjadi rebranding produk sebagai Manuskrip . Setahun kemudian - hanya beberapa bulan yang lalu - Fog Creek menjual produk ke perusahaan kecil DevFactory , yang segera mengembalikan nama FogBugz .

Di bawah kepemimpinan CEO Anil Dash, Fog Creek menjadi perusahaan produk tunggal dan mengubah namanya menjadi Glitch .

Kesimpulan

Saya punya banyak pemikiran tentang ini.

Kunci untuk memahami sejarah adalah bahwa Fog Creek selalu tidak terlalu peduli tentang pelacakan bug seperti halnya memberdayakan programmer - dimulai dengan sendiri:

Tugas utama: untuk menciptakan kondisi kerja yang nyaman. Kami membuat akun pribadi untuk karyawan, mereka hanya terbang kelas satu, bekerja 40 jam seminggu, menerima makan siang gratis, kursi Aeron, dan komputer terbaik. Kami membagikan formula cerdik kami kepada dunia: kondisi kerja yang sangat baik → programmer yang sangat baik → perangkat lunak yang sangat baik → keuntungan!

Berdasarkan "formula" ini, kesimpulan logis dan menggembirakan dapat dibuat: Fog Creek membangun bisnis di sekitar kebahagiaan pengembang. Ini memengaruhi produk perusahaan dan "sistem operasi" internalnya. Produk pertama, pelacak bug, berfungsi sebagai dasar untuk peluncuran produk baru yang memecahkan masalah serupa dengan cara yang lebih abstrak.

Menurut Joel, tampaknya kisah Trello bukanlah pencarian bisnis baru melainkan peluang untuk mendukung motivasi dan keterlibatan pengembang Fog Creek . Produk senilai setengah miliar dolar hanyalah efek samping yang menyenangkan.

Namun, sedikit sedih bagaimana semuanya berakhir untuk FogBugz. Saya tidak berpikir bahwa pengembang Fog Creek sangat senang di hari-hari terakhir sebelum penjualan.

Jelas bahwa ada proyek yang lebih penting dan lebih besar: Stack Overflow, Trello dan Glitch - masing-masing secara individual jauh lebih berguna dan lebih berharga daripada FogBugz; dan tidak mungkin bagi satu orang untuk melacak semuanya. Karena itu, saya tidak dapat menyalahkan siapa pun, khususnya, atas hilangnya minat pada FogBugz dengan basis kode 20 tahun dan persaingan yang kuat di pasar. Tetapi pengguna setia setidaknya menemukan rumah yang bagus dan tidak menerima obat matahari terbenam!

Namun, bagian sentimental dari saya lebih suka “menghormati warisan” semua orang yang terlibat dalam penciptaan dan penggunaan produk ini selama beberapa tahun terakhir.

---

6. FreshBooks dan BillSpring

Catatan: ikon operasi rahasia

Artikel ini telah berkembang lebih dari yang saya harapkan, tetapi saya tidak dapat mengabaikan cerita ini. Tunggu sebentar, akan ada belokan tak terduga.

Hentikan saya jika Anda pernah mendengarnya sebelumnya

Pada awal 2000-an, Mike McDerment punya firma desain kecil. Dia memutuskan bahwa perangkat lunak akuntansi terlalu rumit, jadi dia menggunakan Word dan Excel untuk penagihan.

Semuanya bekerja dengan baik sampai satu kasing :

Momen kritis datang ketika hanya kasing yang menyimpan faktur pelanggan penting - Saya baru saja mengklik tombol yang diinginkan. Saya tahu bahwa harus ada cara yang lebih baik, jadi saya menghabiskan dua minggu ke depan pemrograman prototipe yang akan menjadi dasar dari FreshBooks hari ini.

Mike adalah seorang desainer, bukan seorang programmer, tetapi ia dan kedua co-founder tersebut berhasil mengumpulkan sebuah alat yang cukup baik bagi beberapa orang untuk membayar $ 10 per bulan untuk menggunakannya. Butuh hampir empat tahun bagi bisnis untuk meninggalkan ruang bawah tanah rumah orang tua.

Menjelang ulang tahun ke 10 program (apakah itu terdengar asing?) Freshbooks telah menjadi perusahaan yang menguntungkan dengan lebih dari 10 juta pengguna dan 300 karyawan.

Tapi ada satu masalah. Pada saat perusahaan berhasil merekrut programmer "nyata", mereka memiliki sejuta baris "kode pendiri". Seorang analis eksternal meninjau basis kode dan menyimpulkan:

“Berita baiknya adalah Anda telah menyelesaikan tugas yang paling sulit. Anda tahu cara membangun bisnis, dan Anda memiliki produk yang disukai orang. Berita buruknya adalah kalian kurang berpengalaman dalam teknologi . ”

Lebih penting lagi, mustahil menerapkan ide-ide yang ada dalam produk yang sudah ada:

Kami mendirikan perusahaan lebih dari sepuluh tahun yang lalu, dunia berubah, dan kami belajar banyak tentang pengembangan program dan kebutuhan pengusaha individu, yang semakin lama semakin berkembang di masyarakat ... kami tahu bahwa beberapa upaya perlu dilakukan untuk menjaga agar FreshBooks tetap mutakhir dalam lima tahun.

MacDerment terbiasa dengan kebijakan konvensional yang tidak dapat Anda tulis ulang dari awal:

Menulis ulang kode dari awal adalah risiko terbesar bagi perusahaan perangkat lunak. Kemungkinan besar, Anda bahkan tidak akan menyelesaikan proyek. Ini akan membutuhkan lebih banyak waktu dari yang direncanakan, dan akan lebih mahal. Hasil akhirnya mungkin tidak menarik bagi pelanggan. Dan tidak ada jaminan bahwa platform baru akan benar-benar lebih baik dari yang sebelumnya. Aturan nomor satu dalam perangkat lunak bukan untuk menulis ulang perangkat lunak Anda.

Dengan demikian, mereka melakukan beberapa upaya untuk menghapus kekacauan tanpa menulis ulang sistem dari awal; tetapi "mengganti ban saat bepergian" tidak mungkin.

Apa yang terjadi selanjutnya mungkin mengejutkan Anda

McDermint dikunjungi oleh gagasan diam-diam menciptakan "pesaing" FreshBooks.

Dia mendirikan perusahaan yang sama sekali baru di Delaware bernama BillSpring. Dia memiliki situs web, merek, dan logo sendiri. Mencoba untuk tidak menghubungkan kedua perusahaan, ia menginstruksikan pengacara eksternal untuk mengembangkan dokumen baru untuknya.

Tim pengembangan telah menerapkan praktik pengembangan tangkas berdasarkan buku oleh Jeff Gottelf dan Josh Seiden "Lean UX: Merancang Produk Hebat dengan Tim Fleksibel" : tim scrum dan iterasi mingguan dengan umpan balik dari pelanggan nyata. MacDerment meminta mereka untuk bertindak seperti startup, dan membawanya sebagai investor ventura:

“Kamu punya empat setengah bulan. Jika Anda memasuki pasar, dapatkan lebih banyak uang. Kalau tidak, akhirnya. "

Tim berhasil merilis MVP beberapa hari sebelum batas waktu. Mereka membeli kata kunci AdWords untuk mengarahkan lalu lintas, dan menawarkan pengguna akun gratis untuk tahun pertama. Segera, pelanggan muncul - dan siklus iterasi cepat dari produk nyata dimulai.

Pada akhir tahun pertama, BillSpring mulai mengisi daya. Pada titik tertentu, produk baru menerima penilaian kualitas yang tidak terduga :

"Satu orang dipanggil untuk berhenti berlangganan dari FreshBooks dan pergi ke perusahaan baru kami," kata McDermint. "Itu adalah hari yang menyenangkan."

Segera mereka mengangkat tabir kerahasiaan dan memberi tahu pelanggan BillSpring bahwa itu adalah produk FreshBooks, dan mereka juga memberi tahu pelanggan FreshBooks yang ada bahwa versi baru akan segera hadir.

Secara bertahap, pelanggan FreshBooks "klasik" dimasukkan ke versi baru, tetapi mereka selalu dapat kembali ke versi lama jika mereka mau.

Kesimpulan

Proyek FreshBooks rahasia itu tidak murah: menurut McDermint, mereka menghabiskan $ 7 juta untuk itu. Namun, setelah lebih dari satu dekade pertumbuhan menggunakan sumber daya mereka sendiri, mereka mengumpulkan $ 30 juta dalam modal ventura, jadi ada uang. Tidak semua orang mampu membelinya.

Forbes memperkirakan pendapatan FreshBooks pada 2013 sebesar $ 20 juta. Setelah pembaruan selesai pada 2017, mereka memperoleh $ 50 juta. Tidak diketahui berapa banyak yang datang dari produk baru, tetapi menulis sistem dari awal jelas tidak memperlambat pertumbuhan perusahaan.

MacDerment mengatakan proses pengembangan dan penerapan fitur baru menjadi lebih cepat dan mudah. Lebih penting lagi, mereka sekarang memiliki produk di tangan mereka yang mengimplementasikan ide-ide terbaik. Dengan yang satu ini tidak takut melihat ke masa depan.

Selain itu, pengalaman yang diperoleh telah mengubah budaya perusahaan - dengan cara yang baik. Ketika mereka berpura-pura menjadi startup, mereka belajar cara bekerja sebagai startup. Praktik lean UX telah menyebar ke seluruh tim pengembangan. Pelanggan secara aktif terlibat dalam pengembangan fitur baru.

FreshBooks mengambil langkah luar biasa untuk melindungi diri dari masalah potensial: dengan memperkenalkan inovasi di bawah merek palsu, pengembang dapat sepenuhnya memikirkan kembali program dan mengambil risiko besar. Bahkan dalam kasus terburuk, mereka tidak akan merusak merek yang ada.

Semuanya tampak agak ekstrem. Mungkin tindakan seperti itu tidak perlu. Tapi ini mengingatkan betapa seriusnya taruhannya.

---

Beberapa pemikiran

Secara umum diterima bahwa lebih baik untuk menghindari penulisan ulang suatu program dari awal , dan untuk membuat perbaikan bertahap jika memungkinkan. Sebagian besar, saya setuju dengan itu.

Tetapi saran menyarankan bahwa pada akhirnya kami mendapatkan produk asli ditambah serangkaian fitur baru.

Tetapi bagaimana jika Anda ingin menghapus fungsionalitas? Atau mengimplementasikan beberapa opsi yang sama sekali berbeda ? Bagaimana jika pengalaman muncul dengan ide-ide pendekatan yang secara fundamental baru?

Kesimpulan saya dari cerita-cerita ini adalah ini: segera setelah Anda memahami bahwa versi saat ini sangat berbeda dari cita-cita imajiner , versi baru tidak boleh dirilis sebagai pengganti, tetapi secara paralel dengan yang saat ini .

Ketika ada pemikiran untuk menulis ulang semuanya dari awal, mungkin Anda harus mengajukan pertanyaan lain. Mungkin membuat pesaing Anda sendiri? Jika produk saya adalah FogBugz, lalu apa yang akan menjadi Trello saya? Jika ini Visual Studio, seperti apa VS Code saya nantinya?

Jika kita membandingkan artikel Spolsky tentang Netscape dan posting DHH tentang Basecamp, mereka menyetujui satu hal: Legacy memiliki nilai.

Berita baiknya adalah Anda tidak perlu membuang nilai ini untuk berinovasi.