Apa yang bisa dipelajari programmer dari industri konstruksi? [Tutup]

Ketika berbicara dengan rekan kerja tentang perancangan dan prinsip pengembangan perangkat lunak, saya perhatikan salah satu sumber analogi yang paling umum adalah industri konstruksi. Kami membangun perangkat lunak dan kami menganggap desain dan struktur sebagai arsitektur .

Salah satu cara terbaik untuk belajar (atau mengajar) adalah dengan menganalisis analogi - analogi apa yang bisa diambil dari konstruksi? (apakah sudah umum digunakan dalam perangkat lunak atau tidak).

Harap berikan deskripsi, atau pengalaman pribadi Anda, mengenai bagaimana konsep pemrograman mirip dengan konsep konstruksi.

^{[Kredit untuk Pemrograman konsep yang diambil dari seni dan humaniora untuk ide]}

Di situlah pola desain berasal.

Orang yang diduga memperkenalkan konsep itu kepada dunia adalah Christopher Alexander dalam bukunya "Bahasa Pola: Kota, Bangunan, Konstruksi" pada tahun 1977 . Dari sana, Geng Empat (GoF) mengambilnya , dan sisanya adalah sejarah.

Bahkan sekarang selama kuliah dan dalam pengembangan perangkat lunak dan buku-buku arsitektur analogi antara dunia konstruksi dan dunia pengembangan perangkat lunak tetap berlaku.

Beberapa analogi dan referensi yang dapat saya pikirkan atau ingat:

• Misalnya, mengubah persyaratan selama konstruksi bangunan, mungkin akan menjadi lebih jelas bagi klien betapa absurdnya hal ini, misalnya: "OH, dan saya menginginkan garasi alih-alih di mana dapur yang baru saja Anda selesaikan".
• Bantuan sementara seperti perancah (artinya dalam dunia konstruksi | pengembangan perangkat lunak )
• Klien tidak dapat terus menambahkan fitur tanpa biaya, banyak kali mereka ingin hal-hal dilakukan secara gratis, dan kadang-kadang kita cukup bodoh untuk menerima; yang tidak bisa terjadi di dunia konstruksi (lihat persyaratan creep ).
• The peran dalam pengembangan perangkat lunak: arsitek adalah pusat desain solusi; konsultan dan kontraktor dapat merupakan ketentuan yang dapat dipertukarkan; para pekerja adalah programmer.
• Klien tidak dapat memberikan persyaratan yang akurat dalam kedua kasus.
• Perkiraan anggaran dan waktu seringkali salah.
• Produk tidak dapat benar-benar dilihat dalam bentuk aslinya hingga akhir .
• Bangunan mungkin memiliki kesalahan konstruksi setelah dibangun, perangkat lunak cara yang sama memiliki bug .
• Jika produk tersebut dikerjakan dengan buruk, kadang-kadang lebih disukai untuk dihancurkan dan mulai lagi daripada memperbaikinya.
• Tidak tahu tentang hasil aktual dan nyata dari pekerjaan berkualitas buruk, klien menginginkan solusi termurah .
• Sumber Terbuka . Saya baru saja menonton ceramah ini dari Doc Searls yang disebut " Mengapa Semua Bisnis Akan Didasarkan pada Sumber Terbuka " di mana ia menceritakan bagaimana komunitas konstruksi berbagi teknik dan pengetahuan umum alih-alih mematenkan mereka seperti komunitas sumber terbuka, bahkan ketika beberapa barang di gedung mengandung produk-produk eksklusif bawaan.
• Proyek menjadi lebih baik untuk semua orang jika klien terlibat secara aktif .

(Jika lebih banyak terlintas dalam pikiran, saya akan menambahkannya.)

Ada beberapa yang tidak berpikir analogi umum itu benar, bacaan yang disarankan untuk ini adalah The Software Construction Analogy is Broken . Juga, ada pertanyaan tentang ini di SO berjudul Apa yang salah dengan analogi antara perangkat lunak dan konstruksi bangunan? .

Kami telah mengambil banyak kata dan ide dari industri konstruksi sepanjang sejarah pengembangan perangkat lunak, dan pada kenyataannya kami mungkin mengambil banyak, dan saya tidak berpikir ada sesuatu yang tersisa untuk diambil.

Kami mengambil seluruh proses meminta pelanggan membuat spesifikasi, kemudian perencanaan arsitek, lalu insinyur merancang dan terakhir menerapkan kode monyet dari industri konstruksi, dan ternyata sepenuhnya salah arah.

Ini karena ketika Anda membangun sebuah rumah, jika fondasi Anda salah, Anda merasa bersalah. Serius berpengaruh. Untuk mengangkat bangunan dan mengganti fondasinya, biayanya lebih tinggi daripada membuang semuanya dan memulai lagi dari awal. Tetapi dalam perangkat lunak itu sepenuhnya mungkin. Saya telah membuat ulang perangkat lunak klien menjadi solusi client-server tanpa pengguna memperhatikan apa pun, kecuali bahwa saya memindahkan modem ke ruang server. Itu seperti mengganti fondasi beton dengan perahu saat penghuninya sedang tidur.

Perangkat lunak tidak seperti konstruksi. Dan itulah mengapa seluruh industri perangkat lunak menyalakan waktu di awal kenakalan dan seluruh proses "air terjun" dalam menjalankan proyek digantikan dengan proses gesit hanya dalam beberapa tahun.

Adapun kata - kata banyak diambil dari konstruksi, benar dan salah.

Kerangka kerja adalah yang paling jelas belum diambil. Dan ada pipa .

Saya telah menggunakan analogi ini ... banyak proyek perangkat lunak dimulai karena orang yang membutuhkan beberapa perangkat lunak tahu sama dengan "tukang", dan mereka mempekerjakan orang ini untuk membuat mereka perangkat lunak yang setara dengan gudang kebun. Ini adalah aplikasi kecil yang berguna yang melakukan tugasnya dengan sangat baik.

Pelanggan kemudian kembali ke tukang, senang dengan pekerjaan mereka, dan meminta mereka untuk mengubah perangkat lunak untuk melakukan satu hal lagi. Sering kali, fitur baru ini tidak ada hubungannya dengan permintaan asli, jadi hampir seperti mereka meminta Anda untuk membangun kamar lain di belakang kebun dengan pintu masuk yang terpisah.

Kemudian mereka ingin meletakkan lampu di dalam gudang, sehingga mereka memiliki tukang kembali, dan dia menjalankan satu sirkuit dari panel utama di rumah, memasang saklar lampu rantai tarik di langit-langit setiap kamar dan menghubungkan mereka ke sirkuit .

Pelanggan kemudian memutuskan bahwa mereka ingin menjalankan beberapa alat listrik, tetapi itu terus meniup pemutus sirkuit, sehingga mereka memanggil orang itu kembali dan dia benar-benar harus merobek satu rangkaian dia berlari ke panel utama, dan memasang konduktor yang lebih besar dan sebuah sub-panel di dalam gudang. Dia harus menjalankan kawat dua kali, dan membayar dua izin listrik, dll. Ini tidak efisien.

Kemudian klien meminta sesuatu yang absurd: bisakah Anda mengubah kebun saya menjadi garasi? Saya tidak ingin Anda melakukan kembali apa yang telah Anda lakukan ... Saya hanya ingin Anda membuatnya lebih besar sehingga saya dapat memarkir mobil saya di sana. Kemudian, dalam banyak kasus, tukang itu berpikir "pelanggan selalu benar" dan mulai membangun tambahan di 3 sisi gudang untuk membuatnya lebih besar, merobohkan dinding di antara partisi, dll. Tentu saja, atap berakhir melorot karena tidak dibangun dengan benar, dll.

Jadi klien tidak lagi terkesan, tetapi mereka masih menginginkan lebih. Mereka meminta tukang itu berulang-ulang untuk hanya menambah satu ruangan lagi, atau mengubah ruangan yang ada ini untuk melakukan ini, dll. Anda berakhir dengan sesuatu yang terlihat seperti The Burrow dan kira-kira sama secara arsitektur.

Sekarang kebanyakan orang tidak cukup bodoh untuk mencoba ini di dunia konstruksi, tetapi itu terjadi setiap saat di dunia perangkat lunak, karena orang tidak membuat koneksi ini:

1. Seseorang yang memenuhi syarat untuk membangun gudang kebun yang benar-benar bagus belum tentu memenuhi syarat untuk membangun rumah.

2. Jika Anda tahu sebelumnya bahwa Anda akan membangun rumah secara bertahap, tetapi itu hanya akan dimulai sebagai gudang kebun, Anda akan melakukan hal-hal yang berbeda dan gudang kebun akan jauh lebih mahal (Anda akan menuangkan pad yang benar-benar tebal, pastikan Anda menjalankan konduktor yang cukup besar untuk muatan penuh rumah jadi, dll).

3. Dalam banyak kasus, peningkatan dari satu tahap ke tahap lain melibatkan pembatalan banyak pekerjaan yang sebelumnya dilakukan, membuatnya lebih mahal daripada yang seharusnya.

4. Dalam dunia konstruksi, kami dapat memberikan pelanggan ide yang bagus seperti apa hasilnya selama tahap desain, tetapi kami tidak memiliki kemampuan itu di dunia perangkat lunak. Jika Anda sampai pada titik itu, pada dasarnya Anda telah menulis sebagian besar perangkat lunak.

Agile Manifesto adalah hasil dari pengakuan bahwa analogi perangkat lunak / konstruksi rusak. Hal-hal seperti tes unit otomatis dan siklus rilis berulang tidak memiliki paralel dalam konstruksi. Hal-hal ini mengambil keuntungan dari biaya hampir nol untuk beralih dari desain ke prototipe (kami menyebutnya kompilasi atau bangunan).

Istilah Selesai bekerja dan Potong datang ke pikiran.

Gagasan bahwa tidak apa-apa untuk menunda beberapa pilihan estetika ketika keputusan struktural utama selesai.

Pepatah lama: Ukur dua kali dan potong sekali.

Sunting: Ada bagian dalam Manifesto Daftar Periksa oleh Atul Gawande, yang berbicara tentang mengelola pekerjaan konstruksi besar. Ketika mereka sampai pada titik yang benar-benar rumit, mereka mengadakan pertemuan dengan para ahli yang terlibat untuk meninjau kembali masalah dan melihat apakah ada sesuatu selama proyek telah terjadi yang harus diketahui semua orang. Kita mungkin tidak bisa merencanakannya sebelumnya.

Keterbatasan ada dalam konstruksi dan pemrograman .

Jika Anda sebagai pelanggan tidak dapat membuat permintaan konyol seperti memperpanjang gedung hotel jadi selama akhir pekan dan menempatkan bandara ke lantai bawah tanah dan landasan pacu di penthouse-nya, mengapa Anda tidak dapat menerima bahwa tidak semua penyesuaian dengan yang sudah selesai perangkat lunak apakah mungkin? Ini bukan bola ajaib 0s dan 1s, ini adalah struktur konstruksi yang kompleks, meskipun tidak material tetapi dengan keterbatasannya juga.

Saya bekerja di bidang konstruksi melalui sekolah dan ada tempat di mana itu bahkan bukan analogi, konsep yang sama berlaku. Namun seringkali, godaan perbandingan berjalan terlalu jauh.

Ketika saya mengerjakan perkiraan untuk suatu pekerjaan, saya tahu ada rata-rata yang cukup kuat tentang berapa lama waktu untuk melakukan sesuatu. Untuk membuat jendela etalase misalnya, kami hanya menghitung jumlah sambungan dalam bingkai dari rencana dan memiliki ide yang cukup bagus berapa lama. Sama seperti pemrograman, kami harus memperhitungkan variabel dalam jadwal meskipun itu bisa menyedot kehidupan Anda. Sebagai contoh: memiliki kru pipa muncul untuk menemukan bahwa tempat parkir sedang diaspal dan mereka tidak dapat masuk ke gedung karena aspal panas di jalan agak mahal.

Namun, konstruksi memiliki pengalaman selama ribuan tahun. Aturan dasar perdagangan didorong oleh hukum fisika yang sama seperti sebelumnya. Perhitungan beban angin dan beban mati adalah sama seperti ketika dilakukan dengan aturan geser. Perbaikan dalam alat dan teknik telah terjadi, tetapi pada kecepatan yang lebih rendah dibandingkan dengan apa yang kita alami.

Di sisi lain, kami masih menemukan bahwa banyak pola dan praktik kami membutuhkan ruang untuk perbaikan. Singleton dulu ide yang baik, sekarang sebagian besar yang berpikir tentang hal itu lebih suka pola IoC / DI.

Di mana kita juga kurang dalam lisensi dan sertifikasi yang berarti. Di banyak daerah, bahkan untuk sekadar menjadi tukang reparasi apalagi tukang instal, seorang tukang ledeng harus memiliki lisensi atau bekerja di bawah pengawasan seseorang yang ada. Untuk mendapatkan lisensi itu diperlukan sejumlah waktu untuk bekerja di lapangan. Saya tidak mendukung atau menentang perizinan, hanya menunjukkannya karena ini merupakan perbedaan besar.

Tentu saja di kedua bidang, seorang arsitek dapat menggambar sesuatu yang tidak dapat diimplementasikan.

Perancah , "struktur sementara yang digunakan untuk mendukung orang dan material dalam konstruksi atau perbaikan bangunan dan struktur besar lainnya." ^{[definisi dari wikipedia]}

Konsep ini berfungsi karena scaffolding dalam pemrograman dapat dibuat dengan cepat dan menyediakan fungsionalitas sementara sampai struktur yang sebenarnya ada.

Saya tahu beberapa perusahaan konstruksi yang bekerja di pertanian untuk penawar terendah, melakukan pekerjaan yang ceroboh, mengabaikan apa yang seharusnya menjadi tugas garansi, fokus pada tanggal atas kualitas, dan kemudian membebankan keuntungan konyol untuk produk "jadi".

Tetapi saya tidak berpikir programmer atau agen konsultasi telah belajar apa pun dari praktik tersebut.

Bug dapat menjadi sangat mahal, atau bahkan membunuh orang?

Ada pedoman dasar untuk proyek-proyek teknik kompleks dari segala disiplin ilmu:

1. pentingnya perencanaan, cetak biru, desain, dll.,
2. pentingnya matematika yang mendasarinya
3. menggunakan kembali ide / pembelajaran dari proyek serupa lainnya
4. menggunakan blok bangunan / komponen siap pakai yang dibangun oleh orang lain
5. memperbaiki masalah sangat awal dalam siklus hidup
   dll,

Kesamaan antara arsitektur, sipil dan disiplin rekayasa perangkat lunak tampaknya terutama berasal dari tidak adanya jalur perakitan : setiap proyek unik dalam kemauannya sendiri.

Lembur

Tetapi di industri konstruksi, pekerja mendapatkan upah lembur mereka.

Penggunaan standar, konvensi, dan komponen pra-bangun. Anda tidak akan mengalami masalah seperti ini.

Saya tidak dapat menemukan apa pun di pasar yang sesuai dengan soket buatan kami.

Ketika semua yang Anda miliki adalah palu, semuanya tampak seperti paku. :)

Cedera regangan berulang

Mereka merupakan bahaya pekerjaan di kedua industri, dan tindakan pencegahan harus diambil untuk mencegahnya. Begitu mereka mulai, mereka sulit disembuhkan.