Mengapa industri TI tidak dapat menghasilkan proyek besar yang sempurna dengan cepat seperti di industri lain?

Setelah menonton seri MegaStructures National Geographic , saya terkejut betapa cepatnya proyek-proyek besar selesai. Setelah pekerjaan pendahuluan (desain, spesifikasi, dll.) Dilakukan di atas kertas, realisasi dari proyek-proyek besar hanya memakan waktu beberapa tahun atau kadang-kadang beberapa bulan .

Sebagai contoh, Airbus A380 "secara resmi diluncurkan pada 19 Desember 2000", dan "pada awal Maret 2005" , pesawat sudah diuji. Hal yang sama berlaku untuk tanker minyak besar, gedung pencakar langit, dll.

Membandingkan ini dengan keterlambatan dalam industri perangkat lunak, saya tidak dapat tidak bertanya-tanya mengapa sebagian besar proyek TI sangat lambat, atau lebih tepatnya, mengapa mereka tidak bisa secepat dan tanpa cacat, pada skala yang sama, diberikan cukup banyak orang?

Proyek-proyek seperti Airbus A380 menghadirkan keduanya:

• Risiko besar yang tidak terduga: sementara ini bukan pesawat pertama yang dibangun, masih mendorong batasan teknologi dan hal-hal yang bekerja dengan baik untuk pesawat yang lebih kecil mungkin tidak bekerja untuk yang lebih besar karena kendala fisik; dengan cara yang sama, teknologi baru digunakan yang belum digunakan, karena misalnya mereka tidak tersedia pada tahun 1969 ketika Boeing 747 dilakukan.

• Risiko yang terkait dengan sumber daya manusia dan manajemen secara umum: orang-orang berhenti di tengah proyek, ketidakmampuan menjangkau seseorang karena dia sedang berlibur, kesalahan manusia biasa, dll.

Dengan risiko-risiko itu, orang-orang masih mencapai proyek-proyek seperti pesawat-pesawat besar dalam waktu yang sangat singkat , dan meskipun pengiriman tertunda, proyek-proyek tersebut masih sangat sukses dan berkualitas tinggi.

Dalam hal pengembangan perangkat lunak, proyek-proyek tersebut tidak sebesar dan serumit pesawat terbang (baik secara teknis maupun dalam hal manajemen), dan memiliki risiko yang sedikit lebih kecil dari dunia nyata.

Namun, sebagian besar proyek TI lambat dan terlambat , dan menambahkan lebih banyak pengembang ke proyek tersebut bukanlah solusi (beralih dari tim yang terdiri dari sepuluh pengembang ke dua ribu kadang-kadang akan memungkinkan untuk mengirimkan proyek lebih cepat, kadang tidak, dan kadang-kadang hanya akan membahayakan proyek). memproyeksikan dan meningkatkan risiko tidak menyelesaikannya sama sekali).

Yang masih dikirimkan mungkin sering mengandung banyak bug, membutuhkan paket layanan berturut-turut dan pembaruan rutin (bayangkan "menginstal pembaruan" pada setiap Airbus A380 dua kali per minggu untuk menambal bug dalam produk asli dan mencegah pesawat menabrak).

Bagaimana perbedaan tersebut dapat dijelaskan? Apakah ini semata-mata disebabkan oleh fakta bahwa industri pengembangan perangkat lunak terlalu muda untuk dapat mengelola ribuan orang dalam satu proyek tunggal untuk menghasilkan produk berskala besar, hampir sempurna dengan sangat cepat?

Ed Yourdon's Death March menyentuh sejumlah pertanyaan tipe meta ini.

Secara umum, industri perangkat lunak tidak memiliki banyak hal berikut, yang menghalangi proyek-proyek besar.

• Standarisasi dan rincian item kerja.

  • Ini tentu saja menjadi lebih baik, tetapi konstruksi desain masih belum ada untuk memecahkan sistem besar. Dalam beberapa hal, perangkat lunak bahkan tidak dapat menyetujui apa yang diperlukan untuk proyek tertentu, apalagi bisa memecah hal-hal menjadi komponen.
  • Dirgantara, konstruksi bangunan, mobil, dll. Semua memiliki arsitektur yang digerakkan oleh komponen dengan antarmuka yang cukup ketat untuk memungkinkan pengembangan paralel sepenuhnya. Perangkat lunak masih memungkinkan terlalu banyak pendarahan di area terkait.

• Badan besar yang sukses, proyek serupa. A380 bukan pesawat besar pertama yang dibangun Airbus . Ada banyak aplikasi perangkat lunak besar di luar sana, tetapi banyak dari mereka telah menderita secara dramatis dalam beberapa aspek atau yang lain dan tidak akan mendekati disebut "sukses."

• Sejumlah besar desainer dan pembangun yang telah mengerjakan sejumlah proyek serupa dan sukses. Terkait dengan masalah proyek yang sukses, tidak memiliki bakat manusia yang telah ada di sana, melakukan hal itu membuat hal-hal menjadi sangat sulit dari sudut pandang pengulangan.

• "Tidak pernah" membangun hal yang sama dua kali. Dalam banyak hal, pesawat terbang seperti pesawat terbang lainnya. Itu punya sayap, mesin, kursi, dll. Proyek perangkat lunak besar jarang terulang. Setiap kernel OS sangat berbeda. Lihatlah perbedaan dalam sistem file. Dan dalam hal ini, ada berapa OS yang benar-benar unik? Yang besar menjadi klon item dasar di beberapa titik. AIX , Solaris , HP-UX , ... pemberita kembali ke AT & T System V . Windows telah memiliki jumlah drag yang luar biasa melalui setiap iterasi. Varian Linux umumnya semua kembali ke inti yang sama dengan yang Linus mulai. Saya mengemukakannya, karena varian cenderung menyebar lebih cepat daripada OS berpemilik yang benar-benar unik.

• Estimasi proyek sangat buruk. Karena faktor pengulangan sangat rendah, sulit untuk memproyeksikan seberapa besar akhirnya dan berapa lama untuk membangun. Mengingat bahwa manajer proyek dan Manajemen tidak dapat menggunakan kode dan benar-benar melihat apa yang sedang dilakukan, harapan yang tidak realistis mengenai jadwal dapat dihasilkan.

• QA / QC tidak ditekankan sebanyak mungkin untuk proyek yang lebih besar. Ini kembali ke memiliki antarmuka yang lebih longgar antara komponen, dan tidak memiliki spesifikasi yang kaku untuk bagaimana komponen harus bekerja. Kelonggaran itu memungkinkan konsekuensi yang tidak diinginkan dan bug masuk.

• Kualifikasi yang dapat diukur secara konsisten. Secara umum, orang berbicara tentang jumlah tahun mereka bekerja dalam bahasa X atau dalam pemrograman. Waktu dalam digunakan sebagai pengganti kaliber atau kualitas keterampilan. Seperti yang telah disebutkan berkali-kali sebelumnya, mewawancarai dan menemukan bakat pemrograman yang baik adalah sulit. Sebagian masalahnya adalah bahwa definisi "baik" tetap sangat subyektif.

Saya tidak bermaksud untuk semuanya negatif, dan saya pikir industri perangkat lunak telah membuat langkah signifikan dari tempat kami berada. Forum seperti ini dan yang lainnya sangat membantu mempromosikan percakapan dan diskusi tentang prinsip-prinsip desain. Ada organisasi yang bekerja untuk menstandarisasi pengetahuan "dasar" untuk insinyur perangkat lunak. Memang ada ruang untuk perbaikan, tetapi saya pikir industri ini telah berjalan jauh dalam periode waktu yang cukup singkat.

Jawabannya sangat sederhana: mereka 'industri lain' memang memiliki tingkat kegagalan yang tinggi. Kami hanya membandingkan hal-hal yang salah. Perangkat lunak penulisan sering disebut 'build', dan kami membandingkannya dengan fase pembuatan atau konstruksi di industri lain. Tetapi jika Anda melihatnya, itu bukan konstruksi sama sekali: itu desain . Desain perangkat lunak ditulis dalam kode, dan pembangunan dilakukan oleh komputer, baik dengan menyusun perangkat lunak atau langsung menafsirkannya dengan cepat.

Banyak desain di industri lain membutuhkan waktu lebih lama dari perkiraan semula, lebih mahal, atau tidak pernah selesai. Terdengar akrab?

Jadi, apa yang kita lakukan ketika kita merencanakan perangkat lunak? Yah, kami masih merancang, tetapi pada tahap sebelumnya.

Dalam perangkat lunak, tidak ada garis pembuatan catatan. Membangun komponen akhir (komparatif) murah, dan replikasi produk akhir itu sempurna dan efektif secara gratis - Anda menyalin artefak pembuatan.

Untuk menunjukkan beberapa angka:

1. Perubahan persyaratan setelah implementasi dimulai ; misalnya ketika Airbus A380 pertama mulai dibuat di pabrik saya tidak percaya bahwa jika seseorang menginginkan 200 kursi lagi, itu akan diletakkan di sana; tetapi dalam proyek perangkat lunak besar bahkan setelah programmer memulai pengembangan 5 lebih banyak jenis pengguna dapat ditambahkan.
2. Kompleksitas - proyek perangkat lunak besar sangat kompleks; mungkin proyek paling kompleks yang dirancang dan dikembangkan oleh manusia;
3. Tidak cukup sumber daya yang dihabiskan dalam fase arsitektur dan desain ;
4. Ketidakdewasaan lapangan - rekayasa perangkat lunak relatif disiplin muda dibandingkan dengan saudara teknik lainnya; ini memiliki dua implikasi: a) Tidak banyak heuristik dan praktik yang baik; b) Tidak banyak spesialis yang sangat berpengalaman;
5. Kurangnya bukti matematis - dalam sebagian besar kasus, metode formal matematis tidak digunakan untuk membuktikan bahwa perangkat lunak berfungsi sebagaimana diperlukan; alih-alih pengujian digunakan. Ini memang berlaku di bidang teknik lain yang lebih mengandalkan matematika; alasannya adalah sebagai kompleksitas;
6. Terburu - buru - banyak manajer memiliki tenggat waktu yang tidak dapat dicapai; jadi kualitas kode ditempatkan kedua, karena tenggat waktu.

Menjawab pertanyaan itu dengan ketat - Saya cenderung percaya bahwa orang lain memiliki harapan yang sangat tinggi (terutama dalam waktu pengiriman) dari pemrogram dan tidak mengerti persis bagaimana sulitnya pemrograman perangkat lunak besar.

Premis dari pertanyaan ini agak cacat. Baik A380 dan Boeing 787 dikirim terlambat beberapa tahun.

Dalam kasus A380 banyak penundaan disebabkan oleh unit Airbus Prancis dan Jerman menggunakan versi yang berbeda dan sedikit tidak kompatibel dari perangkat lunak desain CATIA . Ini tidak sesuai memanifestasikan dirinya sebagai memanfaatkan kabel yang tidak cukup cocok dengan pesawat.

Tidak ada yang salah dengan CATIA, yang merupakan perangkat lunak desain pesawat yang paling banyak digunakan, tetapi seseorang di suatu tempat menjatuhkan bola konfigurasi perangkat lunak.

Boeing 787 juga mengalami keterlambatan terkait perangkat lunak, tetapi sebagian besar masalahnya adalah masalah pesawat baru yang lebih tradisional seperti pengendalian berat badan dan pengiriman suku cadang di bawah standar oleh pemasok.

Baik A380 dan B787 harus memodifikasi desain sayap mereka setelah pesawat awal memiliki masalah struktural.

Proyek kompleks besar sulit bagi manusia di semua bidang.

Pria pencakar langit di sini. Tidak yakin apakah saya dapat menjawab pertanyaan Anda, tetapi saya pasti dapat menjelaskan beberapa hal di utas. Bangunan memang terjadi sangat cepat. Kendala utama adalah lokal (peraturan). Namun secara umum dibutuhkan 3 hingga 10 tahun untuk bangunan tinggi dari awal hingga selesai.

Saya pikir membandingkan gedung baru dengan proyek perangkat lunak baru tidak terlalu akurat. Bangunan baru lebih dekat dengan versi baru dari kernel atau OS. Dalam hal ini pengembangan perangkat lunak jauh lebih cepat. Kami tidak pernah membangun dari nol karena ini akan menjadi tugas berisiko tinggi yang klien tidak akan pernah mendaftar. Sebagian besar desain dan pengembangan bangunan merupakan turunan dari proyek yang telah terbukti dan diselesaikan.

Dari pengalaman pribadi, hanya satu dari sepuluh proyek yang dapat dibangun. Prosesnya lebih berorientasi pada pengembangan daripada berbasis desain, jadi saat sesuatu seperti harga baja naik, seluruh proyek keluar dari jendela, atau dirancang, karena desain adalah komponen murah dari proses tersebut.

Desain membutuhkan satu bulan untuk konsep untuk skematis, dua hingga enam bulan untuk merancang pengembangan, enam bulan lagi untuk rincian dan dokumen konstruksi oleh tim arsitek, konsultan perencanaan, insinyur struktural, insinyur angin, insinyur layanan, konsultan kuantitas dan biaya, surveyor, insinyur aksesibilitas dan daftar berjalan ...

Argumen virtual versus fisik tidak terlalu akurat. Kami juga bekerja terutama dengan alat-alat virtual, dan terlebih lagi kami berdua terpisah dari produk akhir kami. Dalam kebanyakan kasus, kami bahkan tidak dapat menguji aspek bangunan dalam skala mockup dan kami menggunakan simulasi untuk mencoba memprediksi apa yang mungkin terjadi.

Dari segi kompleksitas ada perbedaan, tetapi secara keseluruhan mungkin hampir sama. Kami tidak hanya memiliki unit yang saling terkait dan beberapa tingkat abstraksi dan antarmuka berjenjang, tetapi juga orang yang sangat terspesialisasi dalam bagian kecil dari proses yang membuat komunikasi sangat sulit.

Adapun argumen desain versus pengembangan, saya pikir kedua proses dibangun oleh desain. Kedengarannya bagus secara akademis untuk memisahkan ini tetapi tidak mungkin untuk merancang jika Anda tidak tahu cara kerjanya. Anda hanya meningkatkan risiko kegagalan.

Secara keseluruhan, perkiraan saya (yang berpotensi salah) sesuai dengan pertanyaan OP adalah bahwa pemrograman lebih merupakan seni daripada rekayasa. Mengapa orang senang dan bahkan melakukannya secara gratis, menemukan ekspresi dan keanggunan di dalamnya? Ilmu komputer juga (seperti pada timah) lebih dari ilmu daripada teknik. Mengapa Anda mencoba membuktikan algoritma alih-alih hanya menambal bagian yang ada bersama-sama dan bekerja untuk membuat semuanya berfungsi? Tidak yakin apakah ini masuk akal; Saya bukan orang perangkat lunak.

Salah satu aspek yang mengejutkan saya dengan desain dan pengembangan perangkat lunak adalah tentang medium itu sendiri. Komputer membuat pekerjaan manusia-sentris sangat tidak wajar. Semuanya sangat eksplisit dan ada sedikit toleransi. Sulit untuk secara mental mengatasi hal ini, dan beberapa lolos dengan membuang kompleksitas di dalamnya. Jika tidak ada yang lain, ini mungkin ada hubungannya dengan itu?

Lalu berapa lama desainnya? Tahun? Dua? Sepuluh tahun? Desainnya adalah bagian paling kompleks dari membangun sesuatu, konstruksinya sendiri mudah.

Berdasarkan artikel ini , perlahan-lahan dipahami, bahwa pengembangan perangkat lunak sebagian besar proses desain di mana dokumen desain adalah kode sumber itu sendiri. Dan proses desain sama sekali berbeda dari proses produksi. Ini membutuhkan orang-orang yang berpengalaman dan tidak mungkin untuk merencanakan, karena bahkan perubahan persyaratan kecil dapat mengakibatkan perubahan besar dalam keseluruhan arsitektur proyek. Pemahaman ini adalah dasar untuk metodologi tangkas yang fokus pada peningkatan kualitas kode sebagai dokumen desain akhir dan mengambil pengujian dan debugging sebagai bagian dari proses desain, sama seperti mereka menguji model pesawat di terowongan angin.

Konstruksi itu sendiri ditangani secara otomatis oleh kompiler. Dan berkat itu, kami dapat membangun seluruh produk dalam hitungan menit.

Alasan mengapa proyek perangkat lunak selesai dengan penundaan besar dan biaya meningkat adalah karena manajer masih berpikir mereka dapat memperkirakan, memprediksi dan merencanakan proses desain seperti itu. Bumerang ini lebih sering terjadi daripada yang sebenarnya valid. Mereka masih berpikir bahwa dengan mengikat orang ke dalam proses konstruksi yang kaku mereka entah bagaimana dapat meningkatkan kualitas meskipun hasil akhirnya sebagian besar berlawanan dengan peningkatan biaya dan tenggat waktu yang terlewati.

Bayangkan, di tengah-tengah desain Airbus A380, seseorang memasang pipa dalam sebuah pertemuan dan berkata, "Heh, bisakah membangunnya sebagai triplane?" Yang lain bergabung dengan berkata, "Ya, ya. Triplane. Lebih banyak sayap lebih baik." Tahun-tahun berikutnya dihabiskan mengubah desain A380 menjadi triplane. Pada pertemuan lain, seseorang berkata, "Triplane? Itu sudah tua. Kami ingin biplan. Lepaskan salah satu sayapnya."

Atau bayangkan, di tengah proyek pembangunan jembatan, seseorang berkata, "Heh, kami baru saja membuat kesepakatan dengan perusahaan perkapalan. Mereka membutuhkan jembatan yang tingginya 40 kaki lebih tinggi, karena kapal mereka jauh lebih tinggi. Perbaiki. Terima kasih. Terima kasih. . "

Ini hanyalah beberapa alasan mengapa proyek perangkat lunak, besar dan kecil, berakhir dengan kegagalan pada tingkat yang mengkhawatirkan.

Sebagai seseorang dengan latar belakang teknik mesin yang bekerja di TI, saya sering bertanya-tanya tentang alasan rendahnya tingkat keberhasilan dalam TI.

Seperti orang lain di utas ini, saya juga sering mengaitkan kegagalan dengan ketidakdewasaan IT, kurangnya standar detail (ya saya serius, apakah Anda pernah memeriksa lembar standar baut sederhana?) Dan kurangnya standar komponen dan modul.

Industri lain, seperti konstruksi bangunan atau pembangunan kapal juga memiliki lebih banyak "jalur tak jalan": pengetahuan dan pengalaman prototipe solusi tertentu, yang - dalam bentuk khusus - digunakan kembali berulang kali. Pernah bertanya-tanya mengapa bangunan, kapal atau pesawat terbang dengan ukuran dan tujuan yang berbeda terlihat sangat mirip? (ada pengecualian pada aturan tentu saja ...)

Itu karena prototipe tersebut diteliti dengan baik, dipahami dengan baik, umumnya digunakan dan memiliki rekam jejak yang terbukti. Bukan karena itu tidak bisa dilakukan dengan cara lain. Dalam standardisasi IT jarang terjadi: proyek (besar) cenderung menemukan kembali komponen, melakukan penelitian dan pengiriman pada saat yang sama dan dengan orang yang sama!

Hal ini tak terhindarkan mengarah pada produk sekali pakai, yang mahal untuk dikembangkan dan diservis, rawan kesalahan dan gagal dengan cara yang tidak dapat diprediksi dalam kondisi yang tidak pasti. Dan karena ini, tentu saja, produk-produk ini jauh lebih cepat usang, ditulis dan diganti dengan biaya yang sama besar dengan hanya yang sedikit lebih baik. Yang dibutuhkan TI adalah setara dengan revolusi industri, yang mengubah pengrajin usia menengah menjadi pabrik yang efisien.

Yang mengatakan, ada beberapa faktor yang membuat IT benar-benar unik. Berbeda dengan industri-industri lain yang disebutkan, TI benar-benar ada di mana-mana: digunakan dalam setiap aspek kehidupan modern kita. Jadi itu adalah keajaiban kecil. TI telah mencapai banyak kemajuan ini dan mampu memberikan hasil yang dilakukannya.

Saya khawatir saya tidak setuju dengan pernyataan Anda.

Airbus dan Boeing adalah dua contoh perusahaan yang membangun pesawat. Ada berapa perusahaan yang membangun pesawat? Sangat sedikit, jika Anda membandingkannya dengan berapa banyak perusahaan yang membangun perangkat lunak.

Sama mudahnya untuk mengacaukan proyek pesawat terbang dengan mengacaukan proyek perangkat lunak. Jika saja penghalang masuknya sangat rendah di industri pembuatan pesawat seperti di industri perangkat lunak, Anda pasti akan melihat banyak proyek pesawat yang gagal.

Lihatlah mobil; Ada produsen berkualitas tinggi yang membangun mobil yang sangat tahan lama dan sangat canggih (pikirkan Land Rover, Mercedes) dan ada yang membuat mobil yang tidak akan bertahan setahun tanpa harus memperbaikinya (pikirkan Kia atau Cherry). Ini adalah contoh sempurna dari industri dengan penghalang masuk yang sedikit lebih rendah, jika Anda mulai memiliki pemain yang lebih lemah.

Perangkat lunak tidak berbeda. Anda memiliki banyak produk kereta, di sisi lain, Windows, Office, Linux, Chrome, atau Google Search adalah proyek yang sangat berkualitas tinggi yang dikirimkan tepat waktu dan memiliki tingkat kualitas yang sama dengan pesawat terbang.

Poin lain yang banyak dilewatkan orang adalah seberapa banyak perawatan yang diperlukan untuk memelihara mobil, kapal tanker, atau pesawat terbang yang baru saja kita ambil sebagai fakta kehidupan. Setiap pesawat harus menjalani pemeriksaan teknis sebelum setiap lepas landas. Anda harus memeriksa mobil Anda setiap beberapa mil dan melakukan hal-hal biasa seperti ganti oli, ganti ban.

Kebutuhan perangkat lunak juga. Jika hanya orang yang menghabiskan banyak waktu untuk diagnosa, pencegahan, atau mengaudit keadaan dan kualitas perangkat lunak seperti yang mereka lakukan dengan produk mekanik / fisik, saya akan mengharapkan pernyataan yang jauh lebih sedikit seperti ini. Apakah Anda membaca log aplikasi Anda setiap kali sebelum meluncurkannya? Nah .. jika itu pesawat terbang, Anda harus ;-)

Blok bangunan digital bisa 1 atau 0. Tidak ada peralihan.

Desain mekanis memiliki tingkat tol. Saya dapat menempatkan satu paku keling yang kurang sempurna ke dalam sebuah jembatan dan kemungkinan besar tidak akan jatuh, namun, dalam kode bahkan hanya sekali contoh menempatkan 0 di mana 1 harus bisa gagal seluruh program.

Karena sifat komputasi yang logis dan interatif, perubahan apa pun, bahkan yang sangat kecil, dapat menyebabkan kegagalan yang drastis.

Saya sering bertanya-tanya hal yang sama. Ini tentu terasa (kadang-kadang) seperti kami sekelompok amatir yang tidak tahu apa yang kita lakukan. Saya tidak suka penjelasan yang menyalahkan manajer atau faktor eksternal lainnya - kami para pengembang harus bertanggung jawab atas apa yang kami buat.

Saya pikir kita berada dalam bisnis di mana kesalahan itu murah . Perangkat lunak tambalan itu murah, dibandingkan dengan membangun kembali gedung pencakar langit, atau menarik kembali setiap ponsel yang dijual.

Ini telah menciptakan budaya di mana bug adalah bagian dari kehidupan sehari-hari . Mereka diterima dengan mengangkat bahu. Sementara beberapa bug mungkin tidak dapat dihindari, apakah mereka mendominasi pekerjaan kita sehari-hari ? Saya sepenuhnya memahami manajer yang merasa QA tidak sepadan dengan masalahnya, justru karena mereka mengharapkan bug. Saya tidak mengerti programmer yang tidak berusaha membuat kode bebas kesalahan, karena mengoreksi bug sangat membosankan.

Intinya saya percaya itu adalah masalah budaya, dan saya harap itu akan berubah.

Standar dan praktik teknik sangat berbeda di bidang TI (sebagai industri independen) daripada di aerospace . Ini mungkin paling mudah dipahami dengan mempertimbangkan bagaimana profesional TI bereaksi ketika menemukan dokumen standar untuk TI di ruang angkasa . Sebagai contoh, Joint Strike Fighter C ++ Standards yang telah membuat jalan mereka di Internet dalam beberapa kali.

Banyak yang mengekspresikan kegelisahan atau pengunduran diri yang menyedihkan (berharap kita bisa melakukan hal itu); dan banyak yang menanggapi dengan ejekan, mengklaim tidak ada cara praktis untuk mengirimkan produk konsumen dengan cara ini. Ini bahkan mungkin benar, mengingat harapan, bukan dari konsumen, tetapi dari manajemen. Ada banyak ketidakpercayaan untuk coders yang hanya kode dan kode selama beberapa minggu, tidak melakukan demo apa pun. Tuhan membantu pembuat kode yang hanya mendesain sesuatu selama dua minggu. Tidak demikian halnya dengan pesawat terbang.

Dalam perangkat lunak, orang benar-benar berharap untuk memiliki sesuatu sekarang. Tentu, alasannya masuk, akan butuh sedikit waktu untuk membuatnya benar-benar solid; tetapi tidak bisakah kita memiliki beberapa hal rumit yang dijelaskan secara sederhana dalam seminggu? Orang juga belajar bahwa hal-hal rumit yang diuraikan dalam istilah yang jujur ​​dan rumit jarang membangkitkan imajinasi; dan dengan demikian banyak insinyur yang akhirnya terlibat dalam dunia imajiner hal-hal sederhana yang disatukan dengan cara-cara kreatif (berbeda dengan dunia hal-hal sulit yang dilakukan dengan sangat baik).

Beberapa hal dari saya:

1- Standar dan bagian: Mereka adalah produsen pesawat , bukan pengembang. Saya tidak sepenuhnya yakin, tetapi dugaan saya adalah bahwa banyak bagian di-outsourcing-kan. Mereka tidak membangun elektronik / instrumen mereka sendiri, mereka mendapatkan kursi dari beberapa perusahaan, mesin mungkin dikembangkan di tempat lain, dll.

Proyek perangkat lunak, di sisi lain, hampir selalu dimulai dari awal hanya dengan beberapa kerangka kerja / pembantu di tempat.

2- Waktu untuk mencapai pasar: Waktu bukan masalah penting bagi pesawat. Saya yakin desain Airbus telah selesai tahun sebelum selesai, dan mereka memang memilih untuk mengabaikan terobosan besar yang mungkin terjadi pada waktu itu. (Sama untuk produsen mobil, misalnya, teknologi mutakhir yang mereka kembangkan saat ini akan turun ke jalan dalam 5-10 tahun).

Untuk perangkat lunak, Anda harus sangat gesit, jika saya memulai proyek besar sekarang dan membutuhkan waktu tiga tahun untuk mengembangkannya tanpa perubahan, kemungkinannya cukup tinggi bahwa saya mengandalkan teknologi yang tidak tersedia lagi atau produk saya sudah usang. Ini pada gilirannya menawarkan banyak masalah.

3- Siklus rilis dan versi. - Pesawat harus benar-benar selesai saat "dilepaskan". Tidak ada versi beta yang stabil, versi malam atau yang serupa. Selain itu, setelah selesai, itu hanya dapat dimodifikasi dengan cara yang kecil. Anda tidak dapat menambahkan level tambahan dengan 100 kursi ke boeing yang ada, itu tidak mungkin.

Perangkat lunak di sisi lain memiliki perubahan tambahan yang sering kali hanya "membangun yang berfungsi", tetapi belum tentu produk jadi. Juga, dalam IT, tidak biasa mengatakan "hei, mari kita tambahkan kompartemen bagasi lain ke pesawat kami yang menampung tambahan 50 ton".

Saya pikir jawabannya cukup sederhana:

1) Konstruksi dan implementasi fisik telah ada selama manusia - kami telah memiliki ribuan tahun untuk mengembangkan metode dan teknik kami untuk mengimplementasikan proyek fisik. 'Konstruksi' perangkat lunak, yang membutuhkan keahlian yang sama sekali baru dan berbeda, belum lebih dari 50 tahun - kami belum memiliki waktu yang cukup untuk menyelesaikannya.

2) Konstruksi virtual lebih sulit - Anda harus 'melihat' hal-hal dalam pikiran Anda yang tidak memiliki realitas fisik sama sekali. Ini mengharuskan Anda untuk menganalisis dan mengabstraksi banyak informasi sebelum Anda bahkan tahu seperti apa produk Anda seharusnya terlihat dan langkah-langkah yang diperlukan untuk membuatnya. Tidak demikian ketika membangun jembatan atau bangunan.

3) Seringkali jauh lebih sulit untuk menemukan sumber kegagalan atau bug perangkat lunak daripada saat melakukan rekayasa fisik. Jika girder tertekuk, Anda melihat di mana tekuk dan Anda melihat dukungan yang menahannya dan gagal, dll. Menemukan cacat perangkat lunak dapat memerlukan memeriksa banyak kode dan proses yang berinteraksi - sulit, memakan waktu, dan tidak terikat pada hukum fisika dan matematika dengan cara struktur fisik.

Saya akan mencoba menjawab menggunakan salinan kata demi kata dari artikel dari muse Jack Ganssle yang tertanam. Meskipun ini mengatakan firmware di mana-mana, hanya ganti mental dengan perangkat lunak.

Dibandingkan dengan Apa?

Firmware adalah hal yang paling mahal di alam semesta. Dalam bukunya yang indah "Hukum Agustinus," Norman Augustine, mantan CEO Lockheed Martin, menceritakan kisah yang mengungkap tentang masalah yang dihadapi oleh komunitas pertahanan. Sebuah pesawat tempur berkinerja tinggi adalah keseimbangan rumit dari kebutuhan yang saling bertentangan: jangkauan bahan bakar vs kinerja. Kecepatan vs berat. Tampaknya pada akhir 70-an pejuang berada di sekitar berat seperti yang pernah mereka alami. Para kontraktor, yang selalu mengejar keuntungan yang lebih besar, mencari dengan sia-sia sesuatu yang dapat mereka tambahkan dengan biaya banyak, tetapi itu tidak membebani apa pun.

Jawabannya: firmware. Biaya tak terbatas, nol massa. Avionik sekarang menyumbang lebih dari setengah biaya pesawat tempur. Itu adalah sepotong perubahan ketika Anda mempertimbangkan pesawat tempur Amerika terbaru, F-22, berharga sepertiga dari sejuta dolar per pop. Agustinus praktis tertawa terkekeh-kekeh saat menceritakan kisah ini.

Tetapi mengapa perangkat lunak begitu mahal? Tom DeMarco pernah menjawab pertanyaan ini dengan tiga kata ini: dibandingkan dengan apa? Dia melanjutkan untuk membahas kasus-kasus bisnis yang relatif membosankan, tetapi jawaban itu telah bergema di benak saya selama bertahun-tahun. Dibandingkan dengan apa? Dengan perangkat lunak kami secara rutin membuat perilaku produk dengan kompleksitas yang belum pernah terjadi sebelumnya. Tentu, kodenya mahal. Tetapi tidak pernah dalam sejarah peradaban ada orang yang membangun sesuatu yang begitu rumit.

Pertimbangkan jenis gelembung berikut, diangkat tanpa malu-malu dari Wikipedia dan tidak diperiksa keakuratannya:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

Itu hanya 110 karakter tanpa spasi, mungkin terlempar dalam satu atau dua jam. Misalkan kita tidak memiliki perangkat lunak dan harus menerapkan sejenis menggunakan beberapa strategi lain. Berapa biayanya?

Seorang insinyur mesin mungkin membanggakan bahwa profesinya membangun penyortir jauh sebelum komputer. Pertimbangkan penyortir kartu 82 model IBM era 1949 ( http://www.columbia.edu/acis/history/sorter.html ) dengan throughput 650 kartu per menit, lebih sedikit daripada yang mungkin dikelola cuplikan kode kami bahkan pada 4 MHz Z80. Model 82, tentu saja, hanya mengurutkan satu kolom kartu pada satu waktu; untuk benar-benar menyortir geladak bisa membutuhkan lusinan lintasan.

Berapa lama yang dibutuhkan untuk merancang dan membangun binatang ini? Bertahun-tahun, tidak diragukan lagi. Dan fungsinya tidak ada artinya dibandingkan dengan kode kami yang jauh lebih cepat dan yang dapat menangani dataset raksasa. Tapi itu tahun 1949. Berapa lama untuk membangun semacam gelembung dari komponen elektronik - tanpa FPGA dan VHDL, atau CPU?

Dalam satu jam saya mengelola diagram blok kasar, satu di atas level chip (blok memiliki nama seperti "adder," "16 bit latch" dan sejenisnya). Tetapi logika sequencing jelas sangat berantakan jadi saya baru saja melemparkan PLD, dengan asumsi pada titik tertentu tidak akan terlalu sulit untuk menulis persamaan yang sesuai. Dan, ya, mungkin itu melanggar aturan no-diprogram-logika, tetapi untuk merancang dan men-debug semua logika yang menggunakan gerbang dalam jumlah waktu yang masuk akal tidak mungkin seperti gas buck-a-galon.

Dengan asumsi 16 bit kata dan alamat, sirkuit akan membutuhkan sekitar selusin 16 bit kait, adders, dan sejenisnya. Ditambah memori. Dan saya tidak tahu bagaimana data yang tidak disortir masuk ke dalam RAM atau bagaimana hasilnya diekspor. Itu adalah persyaratan desain yang tidak ditentukan. Solusi perangkat lunak saja secara alami menyelesaikan persyaratan ini hanya dengan menulis prototipe fungsi.

Menerjemahkan diagram blok kasar ke skema mungkin memakan waktu sehari. Lalu ada waktu untuk mendesain dan memproduksi PCB, memesan dan memuat komponen (dan mengubah desain untuk menangani masalah akhir masa pakai yang tak terduga namun tak terhindarkan), dan kemudian tentu saja membuat sirkuit bekerja. Kita bisa berbicara tentang upaya selama berminggu-minggu dan banyak uang untuk papan tulis, suku cadang, dan peralatan uji yang sesuai.

Semua ini untuk menggantikan 7 baris kode kecil. Beberapa program tertanam nyata kurang dari 10.000; banyak yang melebihi satu juta. Berapa banyak perangkat keras dan berapa banyak teknik yang diperlukan untuk mengganti program komputer nyata super-ukuran?

Pertimbangkan program nyata seperti spreadsheet. Berapa banyak sirkuit yang diperlukan untuk membuatnya tanpa prosesor? Bisa jadi ukuran kota.

Firmware adalah hal yang paling mahal di alam semesta, tetapi hanya karena kompleksitas masalah yang tak terpecahkan yang dipecahkannya. Tapi ini jauh lebih murah daripada alternatif apa pun. Jadi, ketika bos Anda dengan jengkel bertanya mengapa perangkat lunak itu begitu lama, Anda tahu harus berkata apa. Dibandingkan dengan apa?

Jadi disana! Perangkat lunak / firmware memiliki kompleksitas yang tak tertandingi.

Rekayasa dan manajemen perangkat lunak pada dasarnya berbeda dari banyak bidang teknik lainnya. Hasil tidak fisik, dan proses produksi adalah desain dan proses pengembangan. Membuat salinan lain dari perangkat lunak pada dasarnya memiliki biaya marjinal nol; semua biaya ditemukan dalam mengembangkan salinan pertama.

Karena pemuda relatif rekayasa perangkat lunak dan manajemen sebagai suatu disiplin, ada beberapa informasi yang salah dan kesalahan yang masih dianggap sebagai fakta ( lihat referensi ini ) yang menghambat pengembangan dan rekayasa perangkat lunak secara keseluruhan.

Tidak semua pengembang diciptakan sama. Ada yang baik, ada yang tidak.

Cobalah membaca kode orang lain setiap saat untuk memahami apa yang saya katakan. Terlalu banyak pernyataan logika tambahan dapat menambah risiko. Risiko-risiko ini dapat menyebabkan perilaku buruk atau serangga. Pernyataan logika tidak cukup dan sekarang Anda memiliki referensi nol. Pemrogram yang baik memahami ini dan tahu kapan harus melakukan apa dan di mana. Tapi tidak ada yang sempurna. Segalanya rumit. Tambahkan pekerjaan orang lain yang tidak dipikirkan dengan baik dan mudah untuk melihat bagaimana proyek berjalan.

Katedral dulu membutuhkan waktu hingga 100 tahun untuk dibangun.

Beberapa pesawat Airbus membutuhkan 1 juta baris kode untuk bekerja.

Semakin banyak waktu Anda memperbaiki sesuatu, semakin banyak peningkatan yang Anda dapatkan, jadi berikan industri kesalahan beberapa abad percobaan-kesalahan untuk menjadi lebih baik, dan kita akan melihat berapa banyak yang dibutuhkan untuk mengembangkan proyek besar yang solid tanpa bug. atau kekurangan.

Proyek besar sering terjadi di organisasi besar. Jika Anda belum pernah bekerja di organisasi besar, ada satu hal yang dijamin dapat mematikan kinerja dan produktivitas: birokrasi.

Anehnya, banyak orang tidak tahu apa birokrasi itu (sering bingung dengan politik), atau bahkan jika / ketika mereka memiliki masalah birokrasi.

Kami baru-baru ini menyimpulkan sebuah proyek untuk mengimplementasikan otentikasi kartu pintar. Awalnya diperkirakan tiga bulan. Butuh 15 bulan. Tidak ada biaya, anggaran, ruang lingkup, atau alasan teknis untuk penundaan ini. Cakupannya sebenarnya cukup sempit - hanya untuk akun dengan hak istimewa tinggi (akun administrator), sekitar 1.200 total akun.

Faktor penting lainnya adalah mitra bisnis Anda. Ini akan termasuk vendor. Jika mitra Anda memiliki masalah yang menyebabkan keterlambatan dalam proyek Anda, tidak ada banyak opsi yang benar-benar akan memperbaiki masalah keterlambatan. Mereka tidak bekerja secara langsung untuk Anda, dan Anda mungkin tidak dapat memecat satu orang itu pada pasangan yang mungkin menjadi penyebabnya. Mitra dapat dipecat, atau dapat dikenakan sanksi finansial atau disinsentif, tetapi itu tidak mengubah fakta bahwa proyek telah mengalami penundaan. Inilah yang terjadi dengan Boeing ketika mereka melakukan strategi sumber raksasa dengan Boeing 787 Dreamliner .

Saya memiliki versi yang lebih singkat untuk Anda:

Apa pun yang mudah dilakukan, atau disederhanakan, kami menulis sebuah program untuk melakukannya alih-alih kami.

Dan kemudian bertarung dengan meta-proses sebagai gantinya.

Itu tidak benar, per se, tetapi setiap hari ribuan blog dibuat, alih-alih menulis mesin blog. Setiap hari kerja, ribuan makro Excel ditulis, alih-alih menulis aplikasi database yang dirancang khusus untuk ini.

Ada banyak faktor lain - beberapa di antaranya disebutkan di sini - tetapi saya ingin menambahkan poin ini ke dalam diskusi.

Kurangnya akuntabilitas ... Orang-orang digugat ketika sebuah pesawat jatuh. Industri perangkat lunak menolak tanggung jawab apa pun atas kerusakan perangkat lunak apa pun, oleh karena itu menciptakan kurangnya insentif untuk menciptakan produk yang kuat dan aman.

Sebagian besar proyek besar memiliki tingkat keterpisahan yang tinggi dari sub-proyek, di mana Anda dapat mendefinisikan sejumlah kecil kendala desain; seluruh proyek akan bekerja ketika masing-masing sub proyek selesai. Jika ada yang tidak beres dalam sebuah sub proyek, seluruh upaya tidak perlu dipertanyakan; Anda tinggal mencari cara alternatif untuk menyelesaikan sub proyek (misalnya menggunakan mesin yang berbeda).

Ini mungkin tetapi sulit, baik secara praktis maupun sebagai masalah alami manusia, dalam proyek perangkat lunak.

Sebagian, industri lain telah belajar dengan cara yang sulit bahwa pemisahan semacam ini adalah hal yang baik. Misalnya, jika Anda akan menggunakan mesin pesawat Rolls Royce, Anda tidak perlu menggunakan baut Rolls Royce khusus dan titik attachment yang hanya bekerja dengan sayap dengan desain tertentu, dan kemudian jika Anda mencoba beralih ke Pratt dan Whitney, Anda harus mendesain ulang seluruh sayap Anda dari bawah ke atas (yang, pada gilirannya, membutuhkan desain ulang lengkap dari pesawat, yang pada gilirannya mengharuskan Anda untuk membeli kursi yang berbeda, yang pada gilirannya mengharuskan Anda untuk membeli sistem hiburan dalam penerbangan yang berbeda, yang...). Mungkin ada beberapa hubungan - Anda tidak bisa hanya bertukar mesin tanpa perawatan - tetapi proyek besar umumnya bekerja lebih baik ketika hal-hal seperti itu diminimalkan.

Saya berpendapat bahwa proyek-proyek perangkat lunak besar yang dirancang sebagai sekelompok proyek perangkat lunak kecil dengan antarmuka yang bersih antara satu sama lain tidak akan sering gagal, selama proyek besar sebenarnya diselesaikan oleh kelompok proyek kecil. (Dimungkinkan untuk melakukan kesalahan dalam hal ini.)

Membangun sistem perangkat lunak sangat berbeda dari membangun struktur fisik. Artinya, implementasinya sangat jauh berbeda. Sementara misalnya membangun kapal tanker besar, Anda melakukan banyak tugas yang relatif sederhana (tidak mudah sekalipun!), Seperti pengelasan bagian bersama-sama dengan robot atau dengan tangan, mengencangkan semua mur dan baut, melukis, melakukan dekorasi dengan membawa semua peralatan dan furnitur dan semacamnya. Semua ini adalah hal yang sangat sederhana untuk dilakukan, sungguh.

Namun, ketika datang ke perangkat lunak, itu menjadi jauh lebih kompleks . Misalnya, bagaimana tepatnya Anda menerapkan bagian login yang aman dan kredensial pengguna menyimpan produk? Pustaka dan alat apa yang dapat Anda gunakan? Dengan perpustakaan dan alat apa yang Anda kenal? Bagaimana tepatnya Anda menulis fungsi hashing + pengasinan dan bagaimana Anda memastikannya aman? Anda dapat melakukan ini dalam banyak cara sehingga tidak mungkin untuk menetapkan pola desain praktis yang sebenarnya untuk hal-hal semacam ini. Ya, pola desain tersebut memang ada pada skala yang lebih kecil sebagai "praktik terbaik", tetapi setiap sistem perangkat lunak sangat berbeda dari yang lain, dan bidang ini maju dan berubah dengan kecepatan yang sangat cepat sehingga pada dasarnya tidak mungkin untuk mengikuti.

Saat membangun rumah, Anda tidak benar-benar mengalami masalah seperti itu di mana Anda menyadari bahwa dinding pendukung utama tampaknya tidak memadai dan perlu diganti, mengharuskan Anda untuk menghancurkan kemajuan sejauh ini dan mulai dari pangkalan dengan mengulangi dinding pendukung . Anda menangani masalah seperti itu pada tahap desain , karena relatif mudah untuk memprediksi jenis dinding pendukung yang dibutuhkan gedung Anda.

Namun tidak demikian halnya dengan perangkat lunak. Anda tidak dapat benar-benar mendesain seluruh produk sebagai satu kesatuan dan kemudian mengimplementasikannya. Proses desain perangkat lunak biasanya berulang, dan tujuan dan persyaratan berubah ketika produk sedang diimplementasikan dan diuji. Pengembangan perangkat lunak secara keseluruhan adalah proses berulang di mana hal-hal biasanya berubah ketika paling tidak diharapkan, dan banyak kali perubahan seperti itu menimbulkan tantangan yang membutuhkan lebih banyak pekerjaan, lebih banyak kompleksitas dan sayangnya dan pada akhirnya lebih banyak uang, waktu dan kerja keras untuk mendapatkan yang benar.

Jadi, pada dasarnya, alasan mengapa sulit untuk mengirimkan proyek besar dan memperkirakan jadwal proyek dan roadmap adalah bahwa pengembangan perangkat lunak dan terutama desain yang bekerja adalah bidang yang sangat kompleks . Kompleksitas adalah akar masalahnya.

Definisi "proyek besar" miring.

Sebuah proyek besar, secara teknis, dapat disampaikan tepat waktu, dan tanpa cacat, diberikan itu adalah sesuatu yang telah dibangun berkali-kali selama bertahun-tahun.

• Kloning Pac-Man.
• Kalkulator
• Editor teks

Saya yakin Anda berpikir ... "tetapi itu adalah proyek kecil ! Editor teks itu sederhana ." Saya tidak setuju dengan Anda. Komputer sangat rumit. Hanya menginstal dan mengatur pengguna pada sistem operasi terkadang sulit, dan Anda bahkan tidak menulis OS, atau membangun perangkat keras.

Proyek yang Anda bicarakan adalah proyek besar , mirip dengan eksplorasi ruang angkasa. Bagaimana Anda tahu berapa lama untuk mengembangkan perjalanan antar galaksi? Model apa yang kita gunakan? Anda memiliki yang diketahui, yang tidak diketahui yang diketahui, yang tidak diketahui yang diketahui, dan akhirnya, yang tidak diketahui yang diketahui, yang banyak muncul dalam pengembangan perangkat lunak.

Saya pikir masalahnya adalah salah satu harapan. Hanya karena teknologinya ada, tidak berarti menggunakannya akan berhasil (atau bijak untuk digunakan) untuk sementara waktu. Jika industri lain berperilaku seperti industri perangkat lunak lakukan, kita akan memiliki pembersih vakum bertenaga black hole untuk dijual pada akhir dekade ini. Atau beberapa "visioner" akan memiliki sumber daya untuk membangun pangkalan bulan, dan memutuskan bahwa Starbucks benar-benar akan "melengkapi" pengalaman bagi pengunjung. Saya tidak berpikir masalahnya adalah industri perangkat lunak, tetapi harapan diletakkan di situ.

Meskipun ini bukan satu-satunya hal yang dapat disebutkan, saya pikir satu hal mendasar yang patut ditunjukkan. Sebagian besar produk dimaksudkan agar sesuai dengan perilaku yang ada. Bahkan produk yang merupakan terobosan radikal (misalnya, mobil) umumnya dibuat agar sesuai dengan perilaku yang ada, dan membuatnya sedikit lebih sederhana / lebih mudah / lebih murah / apa pun untuk melakukannya. Ya, sering ada beberapa efek samping pada perilaku yang ada juga (misalnya, mendapatkan bahan bakar untuk mobil daripada makanan untuk kuda), tetapi sebagian besar yang terakhir cenderung menjadi efek samping yang cukup kecil.

Sebaliknya, hampir semua perangkat lunak yang tidak mengubah perilaku pengguna (misalnya, membiarkan mereka melakukan pekerjaan mereka dengan lebih mudah) pada dasarnya dijamin gagal total sejak hari pertama. Lebih buruk lagi, proyek perangkat lunak besar tidak hanya melibatkan perilaku pengguna pada tingkat individu, tetapi perilaku kelompok besar - seringkali keseluruhan organisasi.

Singkatnya, merancang perangkat lunak itu sendiri sering kali merupakan bagian yang paling mudah dari pekerjaan itu. Bagian yang sulit adalah mendesain ulang pekerjaan masyarakat untuk mereka. Itu sulit untuk memulai; melakukannya dengan cara yang tidak hanya akan berhasil, tetapi juga diterima masih jauh lebih sulit.

Airbus A380 bukan proyek yang sukses seperti yang Anda sebutkan. Saya kebetulan bekerja di perusahaan CAD / CAM, dan saya diberi tahu bahwa itu (kami juga punya proyek Airbus) tertunda beberapa tahun, karena mereka menggunakan versi perangkat lunak yang berbeda di perusahaan yang berbeda. Artinya, berbagai bagian sedang dirancang di berbagai belahan dunia. Dan saat mengintegrasikan mereka mengetahui bahwa semua desain tidak dapat diintegrasikan, sehingga mereka harus mendesain ulang dalam satu versi. Jadi melihat itu, saya tidak berpikir itu berhasil. Seandainya datang 2-3 tahun sebelumnya, itu akan menjadi game changer untuk Airbus.

Juga mengenai perangkat lunak yang kuat, Anda melihat pada pesawat terbang, mobil (ABS, EPS, kontrol iklim, dll.) Atau pesawat ulang-alik yang mereka miliki lebih dari 50% perangkat lunak yang menjalankannya dan saya yakin mereka sangat kuat. Hanya saja kita lebih dekat dengan perangkat lunak, dan ada banyak lagi program perangkat lunak, jadi kita melihat lebih banyak kesalahan di dalamnya.

Kunjungi: http://www.globalprojectstrategy.com/lessons/case.php?id=23 dan lihat seberapa sukses Airbus A380.

Insinyur perangkat lunak di sini, dengan latar belakang teknik, dan seorang istri yang bekerja di bidang konstruksi. Kami telah melakukan diskusi panjang (dan argumen) tentang perbedaan pekerjaan kami.

Rekayasa perangkat lunak adalah tentang merancang hal-hal baru . Hampir semuanya dasar telah dilakukan di perpustakaan sumber terbuka di suatu tempat. Di hampir semua pekerjaan di mana seorang insinyur perangkat lunak disewa, dia harus merancang sesuatu yang tidak ada.

Dalam sesuatu seperti konstruksi dan sebagian besar bentuk teknik, hal-hal yang seharusnya ada di 'perpustakaan' dalam perangkat lunak sudah sepenuhnya dirancang. Ingin membangun menara? Cukup salin dan tempel paket dari struktur yang ada, dengan beberapa modifikasi.

Bahkan, salah satu alasan utama saya memutuskan untuk tidak menjadi insinyur adalah karena Anda menghabiskan sebagian besar waktu Anda merancang peningkatan 10% untuk penemuan yang ada, ketika waktu yang sama dapat digunakan untuk memprogram sesuatu yang lebih terlihat, seperti jaringan sosial .

Tidak banyak desain baru di bidang teknik; Insinyur yang sangat terampil adalah seseorang yang dapat memanipulasi desain yang ada menjadi sesuatu yang baru atau meningkatkannya. Tetapi hampir setiap programmer diharapkan untuk memodifikasi desain, meretasnya, atau membuat sesuatu yang baru.

Lihat kembali sejauh mana standar telah berubah sepenuhnya, dari assembly ke C ke C ++ ke Java, JavaScript, C #, PHP, dan sebagainya. Tidak banyak kode yang dapat didaur ulang dari 10 atau 20 tahun yang lalu. Ini sangat berbeda dengan mengatakan ... industri otomotif atau aeronautika ketika Anda dapat terus meningkatkan desain dari beberapa dekade yang lalu.

Manajemen proyek terkenal sulit dalam perangkat lunak . Perkiraan waktu paling baik dilakukan oleh orang yang melakukan pekerjaan , tetapi ketika mereka sibuk membuat perkiraan, mereka tidak menulis kode . Ini menggoda orang untuk menghindari manajemen proyek sama sekali.

Seringkali, banyak kode tergantung pada orang-orang tertentu, dan jika orang-orang ini terlambat atau tidak dapat melakukan, kode tidak bergerak maju. Sebaliknya, jika Anda ingin membuat mobil, Anda dapat menyewa orang yang berbeda untuk memasang ban, sasis, baterai, mesin, dan sebagainya. Berorientasi objek dan kerangka kerja yang ada memungkinkan ini, tetapi mungkin tidak praktis ketika Anda merancang semuanya dari awal.

Kegagalan mungkin diizinkan dalam perangkat lunak . Pengujian bisa mahal. Dalam perangkat lunak, sangat menggoda untuk melewati semua pengujian itu, ketika Anda bisa memperbaiki kerusakan. Dalam sebagian besar bentuk rekayasa, 'kecelakaan' bisa berakibat fatal.

Anda memiliki metode pemrograman yang menggunakan pengujian ekstensif, seperti pemrograman ekstrim (yang sebenarnya digunakan pada megaproyek perangkat lunak). Tetapi dengan tenggat waktu yang ketat (yang bisa dibuat lebih ketat dengan sengaja), tergoda untuk melewatkan semua pemrograman itu dan meluncurkannya dengan bug. Gaya Joel Spolsky "selalu memperbaiki semua bug" akan menghemat lebih banyak waktu dalam jangka panjang, tetapi yang tidak disiplin akan melewati ini dan gagal.

Proyek kecil lebih baik . Istri saya pernah meminta saya untuk mendapatkan pekerjaan di perusahaan besar. Itu berakhir dengan argumen bahwa perusahaan besar adalah perusahaan yang buruk ... baginya, sebuah perusahaan besar memiliki banyak sumber daya, pengalaman, manajemen proyek fungsional, dan prosedur yang tepat. Bagi saya, perusahaan besar adalah dinosaurus, di mana sebagian besar waktu Anda dihabiskan untuk memperbaiki kode, mengujinya, dan dokumentasi.

Saya telah melihat proyek IT bernilai jutaan dolar dikerjakan oleh kurang dari 10 orang. Lebih banyak orang akan memperlambat proyek dan menambahkan birokrasi yang tidak perlu. WhatsApp adalah contoh proyek 'kecil' yang bernilai miliaran dolar. Bukannya proyek-proyek besar tidak mungkin, tetapi Anda tidak perlu ribuan orang untuk menghasilkan perangkat lunak bernilai miliaran dolar.

Salah satu alasan yang belum benar-benar dibahas dalam pertanyaan lain adalah bahwa bidang perangkat lunak berinovasi dengan kecepatan yang jarang terjadi di dunia berbasis materi.

Salah satu alasannya adalah evolusi perangkat lunak adalah siklus umpan balik positif karena perangkat lunak (bahasa pemrograman, alat bantu, IDE) digunakan untuk membangun perangkat lunak. Ini adalah contoh paling jelas bagi hukum Ray Kurzweil untuk mempercepat pengembalian, menghasilkan kemajuan dengan kecepatan yang tumbuh secara eksponensial. Setelah Anda menguasai satu kerangka kerja, bahasa pemrograman, protokol komunikasi saatnya untuk beralih ke yang berikutnya.

Jika pesawat terbang dibangun seperti perangkat lunak, kita akan mengganti material dengan setiap model lain, menggandakan kapasitas dan kecepatannya setiap 18 bulan, mengganti teknologi mesin untuk setiap model baru dengan sesuatu yang baru saja diciptakan, sambil menambahkan kemampuan untuk berenang dan mencari makhluk luar angkasa kehidupan.

Oh, dan idealnya mendengarkan perintah suara dan berfungsi ganda sebagai teater film, arena paintball, dan klub malam yang benar-benar mendalam dengan ruang gelap setelah perjalanan kerja Anda selesai. Hal yang sama! (Perusahaan yang membuat pesawat terbang yang baru saja membawamu dengan andal dari A ke B naik turun setahun setelah perusahaan yang memiliki teater, paintball, dan klub malam muncul.)

Bagi saya masalah utama yang dihadapi rekayasa perangkat lunak adalah kasus penggunaan, pengguna dan lintas platform.

Gunakan kasing

Berapa banyak use case yang dimiliki pesawat terbang? Sebagian besar hanya terbang dari satu tempat ke tempat lain. Mungkin ada lebih banyak seperti radar, kontrol lalu lintas, dll., Tetapi kasus penggunaannya jelas dan tidak banyak. Dalam rekayasa perangkat lunak, kita dihadapkan dengan persyaratan dan pengguna yang tidak jelas yang tidak tahu apa yang mereka inginkan. Pengguna yang berbeda memerlukan konfigurasi / aliran yang berbeda, dapatkah pesawat disesuaikan sesuai keinginan pengguna (Saya ingin punya tv dan kulkas!)?

Pengguna

Siapa yang mengoperasikan pesawat terbang? Pilot, kopilot, beberapa pelayan (jika dihitung) dan operator menara. Mereka semua pro dan deskripsi pekerjaan mereka jelas. Perangkat lunak digunakan oleh noobs dan dummies, belum lagi peretas dan cracker jahat, sementara masih perlu diintegrasikan dengan modul lain (seperti OpenID atau Google AdSense ). Jika sebuah pesawat dapat dioperasikan oleh boneka tetapi masih selamat dari misil atau perampok ninja, maka Anda dapat mengatakan bahwa pesawat itu memiliki kualitas yang sama dengan perangkat lunak.

Lintas platform

Pesawat terbang hanya di langit bumi. Saya tidak yakin tentang bagaimana mereka menangani iklim yang berkabut atau berangin atau panas, dingin dan lembab, tetapi pesawat terbang tidak dirancang untuk terbang pada tingkat gravitasi yang berbeda (saya akan kagum jika bisa terbang ke Mars ). Terkadang, aplikasi harus bertahan dari platform yang berbeda, seperti Internet Explorer, Google Chrome , Firefox dan Safari untuk browser ( Opera maaf ), atau Windows XP / 7/8, atau Linux untuk level OS. Belum lagi perangkat seluler dan resolusi serta orientasi yang berbeda.

Jika Anda berpikir industri lain menyelesaikan proyek tanpa insiden, Anda harus membaca cerita tentang gedung Citigroup yang dibangun pada tahun 1977. Bahkan setelah hampir 7 tahun perencanaan dan konstruksi, bangunan itu dilengkapi dengan cacat desain yang serius yang akan menyebabkan keruntuhan dari Peristiwa badai diharapkan setiap 16 tahun.

Dengan kata lain, untuk setiap tahun Citicorp Center berdiri, ada peluang 1-in-16 bahwa itu akan runtuh.

Desainer asli tidak mengetahui masalah ini, tetapi untungnya itu ditangkap oleh seorang siswa yang mempelajari bangunan itu.

semuanya tampak baik-baik saja — sampai, seperti yang dikatakan LeMessurier, dia mendapat telepon. Menurut LeMessurier, pada tahun 1978 seorang mahasiswa arsitektur sarjana menghubunginya dengan klaim berani tentang bangunan LeMessurier: bahwa Citicorp Center dapat hancur karena angin.

Perbaikan dilakukan secara harfiah di sampul malam yang melibatkan paling sedikit orang untuk menjaga kerahasiaan cacat desain.

Rencana evakuasi darurat disiapkan untuk radius 10 blok yang mengelilingi gedung.

Mereka dilas sepanjang malam dan berhenti saat fajar, tepat saat penghuni gedung kembali bekerja.

Kisah itu tetap menjadi rahasia sampai penulis Joe Morgenstern mendengarnya diceritakan di sebuah pesta, dan mewawancarai LeMessurier. Morgenstern memecahkan cerita di The New Yorker pada 1995

Yang menimbulkan pertanyaan; berapa banyak cacat desain fatal lainnya dalam proyek yang diam-diam diperbaiki atau diabaikan tanpa pengakuan publik.

• Cacat Desain yang Hampir Menyapu Pencakar Langit NYC (slate.com)
• Citigroup Center (wikipedia.com)