Apakah benar-benar tidak ada satu hal dalam 20 tahun terakhir yang memberikan keuntungan pengembangan perangkat lunak yang sangat besar? [Tutup]

Dalam No Silver Bullet , Fred Brooks membuat berbagai prediksi tentang masa depan rekayasa perangkat lunak, yang disimpulkan oleh:

Tidak ada pengembangan tunggal, baik dalam teknologi maupun teknik manajemen, yang dengan sendirinya menjanjikan bahkan satu peningkatan tingkat produktivitas, keandalan, dan kesederhanaan.

Argumennya sangat meyakinkan. Brooks menulis pada tahun 1986: apakah dia benar? Apakah pengembang pada tahun 2014 menghasilkan perangkat lunak dengan kecepatan kurang dari 10x lebih cepat daripada rekan-rekan mereka pada tahun 1986? Dengan metrik yang sesuai - seberapa besar sebenarnya perolehan dalam produktivitas?

Apakah pengembang pada tahun 2014 menghasilkan perangkat lunak dengan kecepatan kurang dari 10x lebih cepat daripada rekan-rekan mereka pada tahun 1986?

Saya akan membayangkan bahwa setidaknya ada urutan peningkatan dalam produktivitas sejak saat itu. Tetapi tidak dengan memanfaatkan satu pengembangan tunggal, baik dalam teknologi atau dalam teknik manajemen.

Peningkatan produktivitas terjadi karena kombinasi beberapa faktor. Catatan: Ini bukan daftar lengkap:

1. Kompiler yang lebih baik
2. Komputer yang jauh lebih kuat
3. Intellisense
4. Orientasi objek
5. Orientasi fungsional
6. Teknik manajemen memori yang lebih baik
7. Batas memeriksa
8. Analisis kode statis
9. Mengetik dengan kuat
10. Pengujian Unit
11. Desain bahasa pemrograman yang lebih baik
12. Pembuatan kode
13. Sistem kontrol kode sumber
14. Penggunaan kembali kode

Dan seterusnya. Semua teknik ini digabungkan untuk menghasilkan keuntungan produktivitas; tidak ada satu pun peluru perak yang pernah menghasilkan urutan peningkatan kecepatan.

Perhatikan bahwa beberapa teknik ini telah ada sejak tahun enam puluhan, tetapi hanya mengamati pengakuan luas dan adopsi baru-baru ini.

Jawaban Robert Harvey bagus, tetapi saya pikir dia mengabaikan apa yang mungkin menjadi alasan terbesar mengapa programmer lebih produktif daripada sebelumnya: ketersediaan luas perpustakaan perangkat lunak.

Ketika saya memulai karir saya tidak ada STL, .NET, QT, dll. Anda memiliki C atau C ++ yang baku, dan hanya itu saja.

Hal-hal yang dulunya memakan waktu berhari-hari atau berminggu-minggu atau bekerja (parsing XML, koneksi TCP / IP, komunikasi HTTP) sekarang dapat dilakukan dengan beberapa baris kode C #. Di sinilah kami mendapatkan pesanan yang lebih besar dalam hal produktivitas pengembang secara keseluruhan.

Produk kami saat ini menggunakan kerangka jendela docking yang kami beli dari vendor. Ini biarkan saya memiliki UI jendela docking yang berfungsi penuh dalam hitungan menit. Saya ngeri memikirkan apa yang diperlukan untuk melakukan itu pada hari-hari menggunakan win32 API.

Demi argumen, saya tidak setuju dengan pernyataan Fred Brooks .

Ada peningkatan dalam teknologi yang memungkinkan peningkatan tatanan produktivitas: internet , dan lebih tepatnya ketersediaan progresif koneksi internet di setiap rumah dalam dua dekade terakhir.

Mampu menemukan secara instan jawaban untuk hampir setiap masalah yang dapat Anda temui karena pengembang memungkinkan peningkatan besar dalam produktivitas. Tidak tahu cara memilih elemen ke-N di JQuery? Pencarian Google mengarah ke jawaban pertanyaan yang tepat di Stack Overflow . Tidak tahu cara menggunakan overflowCSS? MDN Mozilla ada di sini . Lupa apa virtualarti kata kunci dalam C #? Google membantu , lagi.

Ketika saya mulai pemrograman, saya tidak punya internet. Saya memiliki buku, juga beberapa dokumentasi format digital yang disimpan secara lokal, tetapi mencari melalui buku dan dokumentasi adalah proses yang lambat, dan tidak peduli berapa banyak buku yang saya miliki, ada banyak masalah yang tidak disebutkan di sana.

Lebih penting lagi, hampir setiap masalah yang Anda temui sudah ditemui orang lain sebelumnya. Internet membantu menemukan orang yang memiliki kesalahan ini dan berhasil menyelesaikannya. Ini bukan jenis informasi yang Anda temukan di buku atau dokumentasi resmi seperti MSDN. Sebaliknya, informasi seperti itu biasanya ditemukan:

• Pada Stack Overflow, jelas. Misalnya, saya belum melihat buku apa pun yang menyebutkan masalah ini .

• Di blog Saya menemukan banyak bantuan di blog ketika saya memiliki masalah tertentu, apakah itu dengan konfigurasi WCF atau server proxy yang tidak memulai atau bug samar ketika menggunakan API tertentu pada mesin dengan budaya yang berbeda dari en-US.

• Dalam laporan bug tentang perangkat lunak sumber terbuka. Sebagai contoh, baru-baru ini sangat membantu ketika saya mencoba menggunakan MAAS Ubuntu dan ketika saya menggunakan PXE. Anda juga tidak menemukan informasi semacam ini di buku.

Pentingnya ketersediaan langsung jawaban untuk sebagian besar masalah yang bisa ditemui seseorang sangat terlihat jika kita memperhitungkan bahwa sebagian besar waktu yang dihabiskan tim untuk proyek dihabiskan untuk mempertahankannya .

• Internet tidak banyak membantu selama fase arsitektur dan desain (Programmer.SE mungkin membantu, tetapi akan jauh lebih berharga bagi seorang arsitek untuk membaca buku tentang arsitektur dan desain, untuk mempelajari pola desain, dll.).

• Itu mulai membantu selama langkah pengujian dan implementasi, ketika masalah aktual muncul.

• Tetapi sebagian besar masalah muncul selama pemeliharaan, ada di sana ketika bantuan dari orang lain melalui internet nampak penting . Contoh dasar: layanan WCF bekerja dengan sangat baik pada mesin saya , tetapi gagal tanpa terkecuali ketika digunakan dalam produksi, sementara itu berfungsi selama dua minggu terakhir. Ini terjadi pada saya, dan saya berterima kasih kepada penulis blog dan komunitas Stack Overflow karena membantu saya memecahkan masalah ini dalam hitungan jam, bukan minggu.

Apakah ini membenarkan peningkatan x10 dalam produktivitas? Sulit diceritakan.

• Di satu sisi, ada kasus di mana Anda menemukan jawaban segera, sementara Anda bisa menghabiskan waktu berhari-hari mencarinya sendiri (atau dipaksa untuk menulis ulang sebagian besar aplikasi).

• Di sisi lain, produktivitas keseluruhan meningkat berdasarkan berbagai faktor, seperti manajemen proyek yang lebih baik (Agile, TDD, dll.), Manajemen tim yang lebih baik ( Manajemen Radikal oleh Stephen Denning muncul di benak), alat yang lebih baik (debugger, profiler , IDE, dll.), Perangkat keras yang lebih baik (tidak, saya tidak akan sangat produktif jika dipaksa menulis di Assembler karena CPU lambat dan RAM sangat terbatas), dll.

Saya akan mengatakan internet adalah kandidat yang cukup bagus. StackOverflow dan Google adalah alat paling ampuh bagi pengembang modern. Berbagi pengetahuan instan secara global! Saat ini Anda tidak perlu tahu jawabannya, Anda hanya perlu tahu cara mengenal jawabannya - dan itu adalah pengganti yang cukup memadai yang memungkinkan pengembang menghabiskan lebih sedikit waktu membaca dan lebih banyak pengkodean waktu, dan dengan demikian menjadi produktif. Ini berarti bahwa setiap programmer di dunia memiliki akses ke semua jawaban, dan yang perlu mereka lakukan hanyalah tahu bagaimana mengajukan pertanyaan yang tepat.

Saya akan menyarankan bahwa tren menarik kita ke arah lain (yaitu menuju produktivitas yang lebih rendah) setidaknya sekuat tren yang Anda tanyakan. Pengalaman melakukan alat pengembangan klien / server seperti VB6 atau PowerBuilder cukup dekat dengan ideal "Pengembangan Aplikasi Cepat" (RAD). Anda harus menggambar formulir Anda, dan ada kait yang jelas untuk kode prosedural atau SQL Anda.

Pengembangan web, setidaknya pada awalnya, menghancurkan banyak teknik dan infrastruktur yang memungkinkan hal-hal ini, dan banyak pengembang klien / server berhenti menjadi pengembang, atau berpegang teguh pada, katakanlah, VB6.

Transisi ke pengembangan Web yang digerakkan oleh klien adalah pengalaman slash-and-burn; Microsoft kembali ke ideal RAD dengan WebForms, dan kemudian dengan cepat gagal. Sebaliknya pengembang diharapkan untuk menyalahgunakan infrastruktur (mis. XMLHttpRequest, yang jarang digunakan untuk XML) dan sebaliknya menggunakan abstraksi tingkat rendah dalam upaya membuat situs web mereka lebih interaktif

Ada alasan bagus di balik semua transisi ini, dan tidak adil untuk membandingkan proses yang menghasilkan .EXE asli (memerlukan instalasi dan manajemen pada klien individu) dengan pengembangan Web, juga tidak sepenuhnya adil untuk membandingkan suatu proses yang sangat bergantung pada postback dengan yang menghasilkan pengalaman yang lebih mulus. Tetapi saya akan mengatakan bahwa praktik-praktik yang sedang populer saat ini menghasilkan beberapa proses berpikir tingkat rendah yang mengejutkan di antara orang-orang yang melewatkan klien / server, RAD, dan sejenisnya. Tombol klien / server baru saja bekerja, dan orang tentu tidak perlu khawatir tentang saluran data yang mendasari yang mendapatkan data ke penangan acara yang membuat ini terjadi.

Sebaliknya, lebih banyak pengembang kontemporer cenderung berpikir bahwa kita yang melakukan pengembangan klien / server (atau bahkan pengembangan Web berbasis postback) memiliki kecenderungan untuk mengambil jalan pintas (dan artinya dengan cara yang buruk). Itu bisa dimengerti, tetapi saya masih berpikir bahwa cara pembangunan kontemporer dilakukan ternyata sangat rendah, dan hari-hari mencari "peluru perak" tampaknya telah memberi jalan kepada era mengejek kita yang mempertanyakan kebijaksanaan pertambangan dan peleburan timah kita sendiri.

Teknologi telah berkembang sangat pesat dan sekarang kita memiliki semua hal yang Robert Harvey sebutkan dalam jawabannya, tetapi:

• Masalahnya tampaknya persyaratan berubah . Klien tahu bahwa tidak akan ada pemborosan bahan saat mengubah persyaratan proyek perangkat lunak, begitu mereka lakukan. Perubahan persyaratan semacam itu hampir tidak pernah terjadi begitu proyek dunia fisik seperti bangunan, setengah selesai.

• Aspek penting lainnya adalah pemrograman terus menjadi pekerjaan tangan yang tinggi . Jarang jika pernah, kode yang dihasilkan RAD masuk ke produksi tanpa dimodifikasi terlebih dahulu.

• Kode terus menjadi sangat kompleks , dan kompleksitas itu tampaknya tidak berkurang dengan teknologi baru.

• Tingkat tenggat waktu yang tidak terpenuhi atau anggaran yang dilampaui terus menjadi lebih besar daripada mereka yang berada di disiplin lain, dan sering kali utang teknis timbul untuk memenuhi mereka, menghasilkan biaya tersembunyi.

• Sesuatu yang, tanpa diragukan, telah terjadi adalah kompartementalisasi telah terjadi. Jumlah teknologi yang harus diketahui adalah bahwa para programmer harus mengkhususkan sejumlah kecil teknologi agar menjadi sangat baik dalam hal itu, yang membutuhkan berbagai jenis pakar untuk menyelesaikan proyek besar.

• Satu hal yang berbicara tentang kompleksitas perangkat lunak adalah bahwa walaupun ada ratusan pembuat mobil di dunia, daftar perusahaan yang mampu menciptakan dan memelihara sistem operasi , (desktop, mobile, tertanam atau lainnya), dapat dihitung dengan jari. dari tanganmu.

• Semua hal di atas telah menciptakan situasi di mana tidak ada cukup banyak orang yang belajar untuk menjadi programmer , sehingga pemerintah telah membuat kampanye untuk memotivasi lebih banyak siswa untuk mengambil jalur karier itu.

• Satu rasa dari jatuh tempo industri perangkat lunak adalah bahwa lisensi perangkat lunak terus menyatakan "<perusahaanX> tidak membuat pernyataan tentang kesesuaian perangkat lunak ini untuk tujuan tertentu. Ini diberikan" sebagaimana adanya "tanpa jaminan tersurat atau tersirat." Bayangkan pembuat perangkat keras menyatakan bahwa produk mereka tidak cocok untuk tujuan tertentu. Itulah keadaan seni sekarang.

Sementara orang mungkin berdebat dengan metrik tertentu (yaitu, apakah ada yang membaik dengan faktor 9,98?), Saya (berbicara sebagai sesuatu dari zaman dulu) harus setuju dengan sentimen umum dari komentar Brooks.

Pertama, ada sangat sedikit teknologi baru yang ditemukan sejak mungkin tahun 1970. Ya, sirkuit terintegrasi menjadi lebih panjang, lebih rendah, lebih luas, dan serat kaca telah meningkatkan kecepatan komunikasi, tetapi untuk setiap langkah maju ada satu kembali.

Teknologi kompiler telah memungkinkan peningkatan 10x dalam "produktivitas" programmer vs 1970, ketika fungsi satu angka yang dihasilkan dibagi dengan waktu pengkodean yang sebenarnya, tetapi perkembangan bahasa dan lingkungan pemrograman yang baru atau "direvisi" berarti bahwa rata-rata programmer menghabiskan lebih banyak dan lebih banyak lagi waktu dalam mode "menyusul", dan kurang dalam aktivitas produktif. Apple, Google, dan Microsoft semuanya memuntahkan "pemutakhiran" baru dan secara substansial tidak sesuai dengan lingkungan mereka pada tingkat yang tepat di bawah yang akan memicu pemberontakan di antara para pegawai mereka ..., para pelanggan pemrograman. Demikian pula, HTML / CSS / Javascript / apa pun terus menjadi lebih kompleks.

Pada suatu saat tingkat di mana dokumentasi dapat diproduksi dan diperbanyak akan membatasi dan memperbaiki semua "inovasi" ini, tetapi, berkat Internet, dokumentasi yang ketat tidak lagi benar-benar diperlukan - hanya memuntahkan fungsi dan mengandalkan blogger untuk mencari tahu detailnya dan membuatnya tersedia.

Ditambahkan: Saya sudah memikirkan hal ini sejak kemarin, dan secara khusus memikirkan proyek yang saya kerjakan dari sekitar tahun 1978 hingga 2008. Proyek ini (Sistem IBM / 38 dan penggantinya) agak unik karena sejak awal upaya adalah dibuat untuk mengendalikan kerumitannya (yang merupakan pembagian perangkat lunak menjadi dua bagian yang kira-kira sama, dengan antarmuka "mesin" di antara mereka). Di area khusus tempat saya bekerja, beberapa rekan kerja saya juga didedikasikan untuk mengendalikan kerumitan (meskipun kami tidak banyak menggunakan istilah itu pada saat itu). Hasilnya adalah sebuah produk yang (pada awalnya) cukup kuat dan "hit" dengan pelanggan dari git-go. Dan itu menyenangkan untuk dikerjakan - seperti bermain di orkestra yang terlatih.

Tentu saja, selama bertahun-tahun kompleksitas merayap masuk, biasanya atas perintah perencana dan manajer pasar yang tidak memiliki penghargaan untuk mengendalikan kompleksitas (yang entah bagaimana berbeda dari sekadar mempertahankan kesederhanaan). Saya tidak memiliki perasaan bahwa ini tidak bisa dihindari, tetapi tidak mungkin untuk mencegah dalam kasus ini tanpa manajer (seperti yang awalnya dilakukan Glenn Henry) mendorong kembali kekuatan kebingungan.

Banyak hal yang telah kita pelajari dalam praktik rekayasa perangkat lunak dalam 30+ tahun terakhir adalah dalam bentuk "teknologi X dapat mempercepat pengembangan awal perangkat lunak baru, tetapi jika Anda tidak menghabiskan banyak waktu atau lebih untuk memikirkan bagaimana dan kapan menggunakannya saat Anda menabung dengan menggunakannya, dalam jangka panjang itu akan mengubah aplikasi Anda menjadi rawa penghisap utang teknis, membuat Anda memesan lebih banyak waktu dan upaya pemeliharaan. "

Teknologi yang termasuk dalam pisau cukur ini meliputi: bahasa rakitan kode tangan, kompiler, juru bahasa, pustaka prosedur, pemrograman imperatif, pemrograman fungsional, pemrograman berorientasi objek, alokasi memori manual, pengumpulan sampah, tipe statis, tipe dinamis, ruang lingkup leksikal, ruang lingkup dinamis , pointer "aman", pointer "tidak aman", tidak adanya pointer sebagai konsep bahasa, format file biner, format file markup terstruktur, makro, templat, penghindaran makro dan templat, memori bersama, passing pesan, utas, coroutine, loop peristiwa asinkron, layanan jarak jauh terpusat, layanan terdistribusi, perangkat lunak yang diinstal secara lokal, array, daftar tertaut, tabel hash, dan pohon.

Fakta bahwa banyak item dalam daftar di atas datang dalam kelompok yang bersama-sama menghabiskan ruang solusi yang diketahui sangat disengaja, dan harus dengan sendirinya memberi tahu Anda sesuatu. Orang dapat berargumentasi bahwa satu - satunya perbaikan pranata yang tidak ambigu, yang kami miliki sejak mereka pertama kali mengaktifkan Z3 adalah pemrograman terstruktur-blok (sebagai lawan dari kode spageti) dan perlindungan memori (wah, saya tidak pernah ketinggalan hari-hari ketika kesalahan ketik bisa mencatat seluruh komputer saya).