Saya adalah pengembang yang relatif baru, baru dari perguruan tinggi. Sementara di perguruan tinggi dan selama pencarian kerja berikutnya, saya menyadari bahwa ada banyak metodologi pengembangan perangkat lunak "modern" yang kurang pendidikan saya: pengujian unit, logging, normalisasi basis data, pengembangan tangkas (vs. konsep tangkas generik), gaya pengkodean panduan, refactoring, ulasan kode, tidak ada metode dokumentasi standar (atau bahkan persyaratan), dll.

Secara keseluruhan, saya tidak melihat ini masalah. Saya mengharapkan pekerjaan pertama saya untuk merangkul semua ide ini dan mengajarkannya kepada saya di tempat kerja. Kemudian saya mendapatkan pekerjaan pertama saya (pengembangan web penuh tumpukan) di sebuah perusahaan besar dan saya menyadari bahwa kami tidak melakukan hal-hal ini. Sebenarnya saya, yang paling tidak berpengalaman dalam tim, adalah orang yang mempelopori upaya untuk mempercepat tim saya dengan teknik pemrograman "modern" - karena saya khawatir tidak melakukannya adalah bunuh diri profesional di ujung jalan.

Pertama saya mulai dengan perangkat lunak logging (log4J), tetapi kemudian saya dengan cepat pindah ke menulis styleguide saya sendiri, kemudian meninggalkannya untuk Google styleguide - dan kemudian saya menyadari bahwa pengembangan web Java kami menggunakan pengontrol depan yang ditulis tangan, jadi saya mendorong untuk adopsi kami pada Spring - tetapi kemudian saya menyadari bahwa kami juga tidak memiliki unit test, tetapi saya sudah mempelajari Spring ... dan seperti yang Anda lihat, itu menjadi luar biasa terlalu cepat, terutama ketika dipasangkan dengan pekerjaan pengembangan normal. Selain itu, sulit bagi saya untuk menjadi "ahli" cukup dalam metodologi ini untuk mengajar orang lain di dalamnya tanpa mencurahkan terlalu banyak waktu untuk satu pun dari mereka, apalagi mereka semua.

Dari semua teknik ini, yang saya lihat sebagai "diharapkan" di dunia pengembangan perangkat lunak saat ini, bagaimana saya mengintegrasikan mereka ke dalam tim sebagai pemain baru tanpa membebani diri saya dan tim?

Bagaimana saya bisa memengaruhi tim saya untuk menjadi lebih gesit? terkait, tapi saya bukan pengembang Agile seperti penanya di sini, dan saya melihat serangkaian metodologi yang lebih luas daripada Agile.

Kedengarannya bagi saya seperti Anda meletakkan kereta di depan kuda.

Apa masalah utama yang dihadapi tim Anda dan teknologi mana yang akan membantu memperbaikinya?

Misalnya, jika ada banyak bug, terutama bug tipe regresi, maka pengujian unit mungkin merupakan titik awal. Jika tim Anda kekurangan waktu, mungkin kerangka kerja dapat membantu (jangka menengah hingga panjang). Jika orang kesulitan membaca kode masing-masing, penataan mungkin berguna.

Ingatlah bahwa tujuan bisnis tempat Anda bekerja adalah untuk menghasilkan uang, bukan untuk membuat kode.

Jawa? Modern?! Anda gagal pada rintangan pertama. Jika Anda ingin benar-benar modern dan menghindari "bunuh diri profesional" maka Anda harus menulis kode Rust. Tentu saja, minggu depan, semuanya akan berubah dan Anda harus belajar sesuatu yang lebih baru untuk mengikuti!

Atau, Anda dapat menerima bahwa tidak ada sejumlah teknologi atau metodologi atau kerangka kerja kata kunci atau du jour lainnya yang akan mengubah fakta bahwa Anda ingin membangun produk berkualitas yang berfungsi. Tidak masalah jika Anda tidak menggunakan gesit jika Anda berhasil menghasilkan output yang tepat. Tentu saja, jika tidak, maka Anda mungkin ingin mengubah beberapa hal tetapi kemungkinan tidak ada latihan khusus yang akan memperbaiki masalah. Mereka akan tetap menjadi masalah manusia yang dapat diperbaiki dengan berbagai cara.

Adapun bunuh diri profesional, jika Anda tahu apa yang Anda lakukan dan fleksibel maka Anda tidak perlu hal-hal yang Anda sebutkan. Orang-orang akan terus menemukan cara-cara baru untuk melakukan pekerjaan lama dan Anda akan selalu mengejar ketinggalan. Atau Anda bisa menggunakan teknik apa pun yang digunakan perusahaan Anda saat ini. Ketika Anda mengubah perusahaan Anda, Anda cukup belajar dan menggunakan teknik yang mereka gunakan.

Terlalu banyak anak yang terpaku pada semua alat baru yang bisa mereka gunakan, lupa bahwa alat ini tidak berharga di tangan seorang pemula. Pelajari praktiknya terlebih dahulu, begitu Anda adalah pengembang yang berpengalaman, Anda dapat mulai "memperbaiki" praktik pengembangan dengan "hal-hal baru yang keren", tetapi pada saat itu Anda diharapkan telah menyadari bahwa itu tidak sepenting yang Anda pikirkan, dan hanya digunakan ketika mereka benar-benar dibutuhkan.

Banyak perusahaan terjebak seperti ini; Anda bahkan mungkin terkejut mendapati bahwa beberapa kolega pengembang Anda belajar sendiri dan menjadi pengembang tanpa latar belakang formal apa pun. Pengembang ini sering kali lebih baik dalam pekerjaannya, karena merekalah yang akan terdorong untuk mempelajari keterampilan baru dan sukses alih-alih hanya melakukan pekerjaan itu. Sayangnya ini juga bisa berarti bahwa, meskipun mereka sangat baik dalam pemrograman, mereka mungkin tidak menyadari manfaat dari praktik-praktik ini. Faktanya adalah ini adalah praktik terbaik , bukan praktik umum . Yang terbaik menggunakannya, tetapi mereka sama sekali tidak persyaratan untuk berhasil, mereka hanya alat untuk membantu membuat kesuksesan lebih mudah.

Anda benar sekali, akan sangat sulit untuk mencoba mengimplementasikan semuanya sekaligus. Anda mungkin akan membakar diri Anda (dan mungkin tim Anda) karena berusaha melakukannya, yang akan menurunkan motivasi masa depan untuk mengadopsi metodologi / teknologi baru. Hal terbaik untuk dilakukan dalam situasi seperti ini adalah memilih satuhal (logging mungkin merupakan awal yang baik, karena Anda mungkin punya jalan sulit di depan menemukan bug tanpa login, dan pasti ada bug) dan bicarakan dengan tim tentang hal itu. Anda tidak harus menerapkan ini sendirian; Anda akan lebih baik mendiskusikan pro dan kontra dengan tim (dan bos Anda, yang benar-benar HARUS berada di papan dengan sesuatu seperti ini) dan membuat rencana untuk mengimplementasikannya. Ini akan harus semudah mungkin (ingat, Anda memberitahu orang-orang bahwa sekarang mereka harus menulis ekstra kode selain apa yang sudah mereka lakukan).

Dan biarkan saya katakan lagi, pastikan bos Anda membeli . Ini sangat penting; Anda mungkin akan menemukan bahwa kecepatan perbaikan / rilis melambat saat Anda menerapkan hal-hal baru. Intinya adalah bahwa Anda membayar dimuka untuk menghemat garis; mereka HARUS memahami ini dan berada di pihak Anda. Jika Anda tidak mendapatkan mereka di papan, Anda berjuang di pertempuran yang kalah terbaik, dan paling buruk mereka mungkin menganggap Anda secara aktif menyabotase tim (tanyakan kepada saya bagaimana saya tahu).

Setelah Anda membawa barang-barang ini ke meja, diskusikan dengan tim, rencanakan cara mengimplementasikannya, dan tindak lanjut, yang kedua, ketiga, kedelapan, dll. Akan lebih mudah. Tidak hanya itu, ada potensi bagi tim dan atasan Anda untuk mendapatkan rasa hormat kepada Anda karena saran Anda diterapkan dan diakui sebagai nilai tambah. Bagus! Pastikan Anda tetap fleksibel: Anda berusaha melawan kelembaman di sini, dan perubahan itu tidak mudah. bersiaplah untuk perlahan menjadi kecilperubahan, dan pastikan Anda dapat melacak kemajuan dan nilai yang diperoleh. Jika Anda menerapkan proses masuk dalam proses baru dan ini membantu Anda menghemat waktu menemukan bug dalam tiga minggu, buat masalah besar tentang itu! Pastikan semua orang tahu bahwa perusahaan baru saja menghemat $ XXX dengan melakukan hal yang benar sebelumnya. Di sisi lain, jika Anda mendapatkan pushback, atau memiliki tenggat waktu yang ketat, jangan mencoba memaksakan masalah tersebut. Biarkan perubahan baru meluncur untuk saat ini, dan putar kembali. Anda tidak akan pernah menang dengan mencoba memaksa tim untuk melakukan sesuatu yang tidak ingin mereka lakukan, dan Anda dapat yakin bahwa hal pertama yang mereka sarankan untuk dijatuhkan adalah pekerjaan 'ekstra' baru (seperti menulis logging, atau mengikuti sebuah styleguide alih-alih hanya 'membuatnya bekerja').

Saya harap Anda belum menyampaikan masalah ini kepada rekan kerja Anda seperti yang Anda lakukan pada kami di pos Anda. ITULAH bunuh diri profesional.

Masalah pertama adalah bahwa Anda mencoba untuk mengajarkan teknologi dan metode yang bahkan Anda tidak memiliki pengalaman dengan sekelompok programmer itu, mungkin agak ketinggalan jaman, tetapi mendapatkan pekerjaan "selesai". Kemungkinan bumerang itu tidak terbatas, dan mungkin akan membawa banyak kegembiraan bagi rekan kerja Anda. Sangat menarik dan mengagumkan bahwa Anda ingin meningkatkan diri dan departemen Anda, tetapi hindari menggunakan istilah seperti "ujung tombak". Hormat kami, jangan gunakan kata itu.

Sebagai masalah sampingan di atas, periksa apakah Anda melakukan beberapa pekerjaan . Saya telah bekerja sebagai programmer mandiri yang belajar sendiri untuk banyak waktu, dan saya tahu betapa mudahnya mengesampingkan pekerjaan yang sebenarnya untuk mengeksplorasi kerangka kerja yang menjanjikan, teknologi dan sejenisnya. Pastikan diri Anda bahwa kinerja Anda berada dalam parameter yang diharapkan (tidak, tidak ada yang peduli bahwa Anda menghabiskan 20 jam meneliti Musim Semi jika laporan yang mereka tanyakan tidak selesai).

Dari semua hal di atas, hindari menjadi guru (kecuali jika itu terkait dengan bidang / teknologi di mana sebenarnya Anda memiliki cukup pengalaman). Presentasi yang lebih netral akan menunjukkan keuntungan, katakanlah, pengujian otomatis, dan membiarkan manajemen memilih siapa yang mereka inginkan untuk meneliti pro dan kontra dari praktik-praktik tersebut.

Sekarang, untuk menyajikan "praktik terbaik" itu, ada dua cara untuk menjelaskannya kepada tim Anda:

• Karena saya katakan bahwa itu adalah praktik terbaik, dan itu sudah cukup.
• Karena mereka berguna dan membantu menyelesaikan masalah.

Menggunakan argumen pertama, kecuali Anda adalah bos atau anggota tim yang sangat senior, kecil kemungkinan mereka akan memberi Anda perhatian. Dan "Saya membaca buku dari Knuth yang mengatakan demikian" atau "orang-orang dari SE mengatakan bahwa" tidak akan menimbulkan kesan, juga ("orang-orang itu tidak bekerja di sini sehingga mereka tidak benar-benar tahu apa yang baik untuk toko IT ini. "). Mereka memiliki metode, rutinitas, prosedur, dan hal-hal yang "kurang lebih" berfungsi, jadi mengapa mengambil upaya dan risiko perubahan?

Agar pendekatan kedua berhasil, harus ada kesadaran bahwa ada masalah . Begitu:

• jangan memaksakan siang dan malam untuk pengujian otomatis. Tunggu hingga pembaruan merusak beberapa fitur, dan tim harus bekerja lembur untuk memperbaikinya, lalu mengusulkan untuk membangun sistem pengujian otomatis.
• jangan meminta ulasan kode. Tunggu sampai Joe dalam cuti panjang dan ada kebutuhan untuk mengubah dalam modul yang hanya diketahui oleh Joe, dan tunjukkan kepada bos Anda berapa banyak waktu yang hilang hanya untuk mencoba memahami kode Joe.

Tentu saja, perubahan akan lambat dan progresif (lebih-lebih dalam perusahaan besar). Jika Anda bisa memperkenalkan tinjauan kode dan pengujian otomatis dalam lima tahun, Anda harus memberi selamat kepada diri sendiri atas pekerjaan yang dilakukan dengan baik. Tetapi, kecuali ada penulisan ulang yang lengkap karena sebab-sebab eksternal, lupakan fantasi apa pun yang akan mereka ubah menjadi IS inti, katakanlah, Spring ( Joel menjelaskan cara itu lebih baik daripada yang pernah saya bisa, bahkan sebelum Anda dilahirkan ¹ ); pada saat itu Anda bisa, paling banyak, memasukkan Spring ke daftar platform yang didukung untuk menulis sistem yang tidak kritis.

Selamat datang di dunia perusahaan IT, nak! :-p

¹ : Ok, mungkin aku sedikit bersemangat, tapi tidak terlalu banyak.

Anda harus mulai dengan buku Bekerja Efektif dengan Kode Legacy oleh Michael Feathers. Dari pengantar buku, "Ini tentang mengambil sistem yang kusut, buram, berbelit-belit dan perlahan-lahan, sepotong demi sepotong, langkah demi langkah, mengubahnya menjadi sistem yang sederhana, terstruktur dengan baik, dirancang dengan baik." Dia kebanyakan memulai dengan pengujian otomatis, sehingga Anda dapat melakukan refactor dengan aman (Anda akan tahu jika Anda memecahkan apa pun), dan dia memasukkan banyak strategi untuk membawa kode yang sulit di bawah pengujian otomatis. Ini berguna untuk setiap proyek yang masih dalam pengembangan. Setelah Anda mendapatkan beberapa pesanan dasar, Anda dapat melihat teknologi modern apa yang benar-benar diuntungkan oleh proyek Anda - tetapi jangan menganggap Anda membutuhkan semuanya.

Jika Anda ingin mempelajari kerangka kerja baru (atau sesuatu) untuk alasan profesional daripada karena proyek Anda saat ini benar-benar membutuhkannya, maka Anda harus menggunakannya dalam beberapa proyek pribadi (pada waktu Anda sendiri).

Kontrol sumber.

Anda tidak menyebutkannya, semoga karena sudah ada di tempat, tetapi, kalau-kalau tidak, mulai dari sana.

Kontrol sumber memiliki dampak terbesar, kecuali dalam keadaan langka yang secara patologis membutuhkan sesuatu yang lain.

Dan Anda bisa mulai sendiri jika awalnya tidak ada yang membeli.

Jawaban Langsung

Jawaban lain memberikan 'meta-poin' yang baik tentang penerapan praktik yang lebih baik, tetapi, hanya untuk memberi Anda beberapa panduan yang relevan secara langsung, berikut ini adalah urutan kasar praktik terbaik yang saya sarankan untuk diterapkan tim Anda (atau tim mana pun) (pertama):

1. Kontrol sumber
2. Pelacakan masalah (manajemen proyek dan tugas)
3. Pembuatan otomatis ¹
4. Penyebaran otomatis

^{1 _{Praktik yang sangat terkait adalah mengotomatisasi, atau setidaknya mendokumentasikan , menyiapkan lingkungan pengembangan dan pengembangan dari setiap aplikasi atau proyek perangkat lunak yang Anda kembangkan atau pelihara. Ini jauh kurang berguna karena Anda (mudah-mudahan) jarang melakukan hal ini atau jarang.}}

Yang lainnya

Anda menyebutkan beberapa praktik baik lainnya - "pengujian unit, pencatatan, normalisasi basis data, ... refactoring, ... dokumentasi" - tetapi ini semua adalah praktik yang dapat dan harus diadopsi secara bertahap dan bertahap. Tak satu pun dari mereka perlu diadopsi sekaligus dan Anda mungkin akan lebih baik mengadopsi mereka sama sekali dengan mengadopsi mereka dengan hati-hati dan penuh perhatian.

Keempat praktik yang saya sebutkan di atas juga akan membuat mengadopsi, dan bereksperimen dengan, praktik baru semudah mungkin. Misalnya, pengujian unit dapat dimasukkan ke dalam bangunan otomatis Anda dan dokumentasi dapat dipublikasikan sebagai bagian dari penyebaran otomatis Anda.

Beberapa praktik lain yang Anda sebutkan - "pengembangan lincah, ... panduan gaya pengkodean, ... ulasan kode, ... metode dokumentasi standar" dan kerangka kerja (misalnya Musim Semi) - benar-benar opsional atau memiliki nilai yang meragukan. Dan itu benar dari banyak (kemungkinan?) Kemungkinan praktik yang akan Anda temukan atau temui.

Pengembangan lincah jelas tidak unggul dari metodologi lain yang digunakan. Dan banyak orang (termasuk saya) memiliki pengalaman mengerikan dengannya. Tetapi banyak orang benar-benar menyukainya (atau menyukainya) juga. Cobalah!

Panduan gaya pengkodean dapat membantu, terutama untuk proyek-proyek besar, atau dalam tim besar, tetapi juga banyak pekerjaan untuk menegakkan pedoman tersebut dan yang mungkin bukan penggunaan waktu terbaik bagi siapa pun yang melakukannya.

Ulasan kode juga dapat sangat membantu - sudahkah Anda meminta rekan kerja Anda untuk meninjau kode Anda? Ingatlah bahwa Anda tidak memerlukan proses formal untuk mengadopsi praktik yang baik!

Dokumentasi hebat - apakah Anda punya? Jika demikian, bagus untuk Anda! Apakah Anda menghadapi banyak pekerjaan tambahan yang dapat dicegah dengan memiliki (lebih banyak) dokumentasi "standar"? Jika ya, maka itu mungkin sesuatu yang layak dilakukan. Namun, katakanlah jika perangkat lunak Anda digunakan oleh sekelompok kecil orang, Anda mungkin tidak memerlukan dokumentasi apa pun . (Atau Anda dapat langsung memasukkan dokumentasi ke dalam perangkat lunak Anda. Itu selalu pilihan saya.)

Kerangka adalah ... pedang bermata dua (sangat tajam). Solusi enkapsulasi dan terawat dengan baik untuk fitur non-inti perangkat lunak Anda sangat bagus ... sampai tidak. Saya tidak yakin apa sebenarnya "pengontrol depan tulisan tangan" tetapi tidak ada penjelasan yang jelas mengapa mereka lebih rendah dari kode yang memanfaatkan Spring. Sudahkah Anda mempertimbangkan merangkum logika umum dalam semua pengontrol ini ke dalam kerangka kerja in-house Anda sendiri? Mengadopsi Pegas, dan menulis ulang semua kode Anda yang ada, bisa menjadi proyek refactoring yang sangat besar (atau, lebih mungkin, menulis ulang) dan itu mungkin bukan perubahan terbaik yang dapat Anda lakukan pada kode Anda . Tentu saja Anda tidak boleh menulis semua perangkat lunak yang Anda gunakan - kerangka kerja (dan perpustakaan) sangat bagus!Tapi mungkin Anda tidak harus menggunakan Spring (atau alternatif) untuk menulis aplikasi web yang hebat (atau bagus).

Lihatlah ke sekeliling tim yang menjadi bagian Anda. Dapatkah Anda melihat bukti bahwa pengembangan yang didorong oleh pengujian atau normalisasi basis data akan meningkatkan kualitas perangkat lunak yang Anda tulis atau membuat orang lebih produktif?

Sudahkah Anda mencoba berbicara dengan salah satu pengawas pembangunan tentang hal itu, atau kepala pengembangan? Obrolan yang benar-benar informal akan menjadi awal yang baik. Apa yang membuat Anda berpikir bahwa orang-orang di atas Anda belum memiliki ide yang sama tetapi tidak dapat / tidak akan mengimplementasikannya karena bisnis tidak akan mengizinkannya?

Saya menemukan bahwa memimpin dengan memberi contoh adalah cara yang baik untuk dilakukan. Orang-orang jauh kurang tahan jika orang lain telah melakukan pekerjaan dan dapat menunjukkan kepada mereka bagaimana mereplikasi itu. Perkenalkan TDD ke dalam proyek yang sedang Anda kerjakan. Mintalah untuk memberikan presentasi kepada seluruh anggota tim, atau bahkan beberapa orang lain dan tunjukkan kepada mereka apa yang telah Anda lakukan. Apa yang dikatakan @DrewJordan tentang menerima pembelian dari bos lebih penting daripada yang mungkin Anda sadari.

Temukan cacatnya. Perbaiki cacat. Tunjukkan perbaikannya.

Mari lakukan normalisasi * terlebih dahulu. Dan memang, saya sarankan Anda mengambilnya dulu, karena kurangnya normalisasi kemungkinan akan menghasilkan data kereta yang sebenarnya yang tidak bisa ada sebaliknya, sedangkan sisanya adalah kasus di mana praktik terbaik mungkin bisa membantu tetapi lebih sulit untuk mengatakan "Bug A disebabkan oleh tidak mengikuti kebijakan X ". Jika Anda memiliki database yang tidak dinormalisasi, maka Anda memiliki tempat di mana data bisa tidak konsisten.

Ini adalah taruhan yang bagus bahwa Anda akan dapat menemukan kasus aktual dari data yang tidak konsisten. Anda sekarang telah menemukan dua hal:

1. Bug dalam data Anda.

2. Bug dalam skema database Anda.

Anda sebenarnya tahu tentang bug kedua pertama, tetapi yang pertama lebih mudah dibuktikan dan juga sesuatu yang menyebabkan masalah nyata, bukan sesuatu yang secara teoritis bisa.

Sayangnya salah satu alasan nyata untuk menolak database dinormalisasi dinormalisasi adalah bahwa pertanyaan apa yang harus dilakukan dengan data kereta tidak selalu mudah, tetapi Anda akan menemukan bug yang sebenarnya.

(Berhati-hatilah karena ada alasan mengapa seseorang terkadang men-denormalisasikan beberapa data dengan sengaja. Jangan salah mengartikan melanggar aturan karena ketidaktahuan akan aturan tersebut; jika Anda menormalkan sebuah tabel yang sengaja dinormalisasi untuk kecepatan pencarian, Anda menang tidak akan memenangkan pujian. Meskipun di sini, denormalisasi menjadi penuh adalah sesuatu yang harus dilakukan secara prosedural, jadi jika tabel yang dinormalisasi tidak dibuat secara otomatis berdasarkan isi tabel yang dinormalisasi masih ada kemajuan untuk dibuat).

Untuk yang lainnya, perkenalkan mereka ketika mereka membantu dalam jangka pendek, untuk kemudian membangun mereka dalam jangka panjang. Misalnya, jika Anda diberikan sepotong kecil kode untuk dibuat, tulislah tes unit untuk itu. Lebih baik lagi, jika Anda diberi bug untuk memperbaikinya, tulis unit test yang gagal karena bug tersebut dan kemudian ketika Anda telah memperbaiki bug sebutkan fakta bahwa bug tersebut berlalu ketika Anda menutup bug (atau mengirim email yang mengatakan bahwa itu sudah diperbaiki) , atau terserah).

* Kebetulan, tidak terlalu modern. Alasan itu disebut normalisasi dan tidak normalisasi atau sesuatu yang lain, adalah bahwa pada saat itu adalah lelucon topikal untuk tetap -ization di ujung hal yang membuat menyenangkan dari nama Richard Nixon Vietnamisasi kebijakan.

Saya akan menentang keinginan dan berkata: cari pekerjaan baru setelah menghabiskan waktu di sini untuk membuat resume Anda sedikit. Bertujuan untuk sekitar satu tahun. Meskipun banyak hal adalah "kata kunci," masalah seperti tidak lengkapnya pengujian unit tidak dapat dilakukan untuk satu pengembang, dan kemungkinannya adalah jika programmer yang bekerja di sana tidak memiliki keinginan untuk pengujian, Anda tidak akan pernah mendapatkan pembelian dan bahkan dapat membahayakan posisi Anda. di perusahaan dengan membuat orang menganggap Anda sebagai penipu. Anda harus berada di tempat di mana Anda bisa mendapatkan bimbingan, bukan mencoba mendorong budaya menuju kompetensi dasar.

Ada banyak proposal untuk meningkatkan paradigma pemrograman . Kata kunci terpanas sekarang tampaknya pemrograman tangkas dan berorientasi objek. Atau apakah mereka? Keduanya memudar secara substansial dibandingkan dengan apa yang baru saja mereka lima tahun lalu.

Anda dapat cukup percaya diri bahwa metodologi apa pun yang diterapkan berusaha mencapai hasil akhir yang sama: membantu insinyur secara ekonomis menghasilkan produk akhir yang cukup baik.

Ada satu paradigma yang kontroversial diperkenalkan pada 1960-an: terstruktur pemrograman : hanya menggunakan "tingkat tinggi" konstruksi seperti while, for, repeat, if/ then/ else, switch/ casepernyataan bukan banyak digunakan gotopernyataan yang telah diterima secara default. Ada masih perdebatan tentang apakah gotomemiliki penggunaan sah sama sekali.

Saya menerima bahwa meminimalkan penggunaan gotoadalah hal yang baik, tetapi seperti semua hal yang baik, adalah mungkin untuk melangkah terlalu jauh.

Anda menyebut agilemetodologi sebagai sesuatu yang positif. Saya berada di satu tim pengembangan selama sekitar enam bulan yang dengan sengaja mengikuti rejimen lincah yang ditentukan. Saya menemukan itu sama seperti metodologi manajemen proyek yang tercerahkan dari beberapa dekade yang lalu, kecuali semuanya diganti namanya. Mungkin dengan menggabungkan kembali dan menjual kembali ide-ide untuk mengkomunikasikan seseorang mencari nafkah dan perusahaan dapat merasa baik tentang "melihat" pakaian baru kaisar .

Pelajaran Agile yang paling berharga, yang telah dikenal sejak lama, adalah bahwa fleksibilitas untuk menemukan jalan yang lebih baik ke produk jadi adalah hal yang baik dan kemampuan untuk menemukan jalan itu bisa datang dari siapa saja — bukan hanya manajemen tingkat atas.

Dari sebuah tulisan oleh pemimpin anti-goto Edsger Dijkstra:

Seni pemrograman adalah seni mengatur kerumitan, menguasai banyak orang dan menghindari kekacauan bajingannya seefektif mungkin.

—Dijkstra, dalam: Dahl, Dijkstra & Hoare 1972, hal. 6. (lihat halaman 6 di sini .)