Apa keputusan teknologi terburuk yang pernah Anda lihat? [Tutup]


10

Ini termasuk keputusan arsitektur, pilihan platform atau situasi apa pun di mana pilihan yang buruk menyebabkan konsekuensi negatif.

Jawaban:


22

Bertahun-tahun yang lalu, saya adalah pengembang utama pada aplikasi yang berpusat pada database yang mulai melemparkan kesalahan. Saya melacaknya ke fakta ada nilai duplikat di bidang database yang seharusnya tidak memungkinkan mereka.

Saya menyalahkan diri sendiri tentang lupa untuk membuat batasan unik pada database ketika saya mendorongnya untuk produksi karena sangat jelas bahwa bidang ini membutuhkan satu. Saya berterima kasih kepada salah satu rekan pengembang yang mengoreksi saya ...

Pengembang lain : "Oh, Anda tidak lupa, ada kendala unik di bidang itu. Saya baru saja menghapusnya."

Saya : "Mengapa Anda menghapusnya?"

Pengembang lain : "Saya melakukan itu beberapa minggu lalu. Saya mendapatkan file data dari pelanggan dan mereka tidak akan mengimpor karena kendala unik memblokir data baru. Jadi saya menghapus kendala sehingga saya bisa selesai mengimpornya."

Saya: "Apakah Anda berhenti untuk mempertimbangkan bahwa mungkin ada masalah jika kami mendapatkan data baru yang tumpang tindih dengan data yang ada dan berpikir tentang menyebutkannya kepada seseorang sebelum mengimpornya?"

Pengembang Lainnya : (tatapan kosong)

Saya : Facepalm.


Itu menyakitkan.


7

Tidak yakin apakah ini dianggap sebagai keputusan teknologi , tetapi saya bertanggung jawab atas situs web pengelola dokumen mirip CMS yang ditulis dalam PHP selama empat tahun. Sepanjang tahun-tahun ini, saya mencoba beberapa kali untuk membuat orang (manajer, pengguna, fitur-pemohon) untuk mungkin, mungkin, seperti, mungkin , mempertimbangkan kemungkinan duduk bersama dan memikirkan persyaratan dan arah masa depan hal itu. Itu tidak pernah terjadi. Itu selalu "tambahkan fitur ini", "tambahkan fitur itu", dan semua orang dengan senang hati tidak menyadari semua cara yang berbeda di mana orang lain menggunakan situs web. Pada saat saya pergi, itu menjadi berantakan besar fitur yang saling berhubungan tetapi tidak terkait, dan saya adalah satu-satunya di seluruh perusahaan yang tahu setiap fitur. Sekarang, tidak ada yang tahu. Mwahaha.


Saatnya mendapatkan konsultan!
Kirk Broadhurst


4

Menulis ulang sistem pesan suara kelas Telco.

Sistem sebelumnya berjalan di Unix dan sekitar 90-an teknologi COM Microsoft datang. Banyak pengembang sedang mengerjakan sistem berbasis NT yang baru ini. Setelah banyak usaha kinerjanya masih belum ada yang mendekati sistem Unix dan pelanggan besar yang membeli sistem baru ini kesal. Perusahaan harus dijual dan beberapa orang harus meninggalkan perusahaan.

Itu jelek. Semua ini terjadi sekitar dua tahun sebelum Joel menulis artikelnya: Hal-Hal yang Seharusnya Tidak Pernah Dilakukan, Bagian I


3

Mengadopsi perpustakaan eksternal (dalam hal ini adalah Spring RCP ) sebelum versi rilis pertama, berdasarkan snapshot SVN. Sudah cukup dijamin bahwa proyek tersebut akan berakhir kurang lebih dan Anda akan menemukan diri Anda terikat pada mayat. Nah, dalam kasus kami bisa lebih buruk. Masih berisiko besar.


Argh, Anda baru saja mengingatkan saya pada bagian lain dari masa lalu saya, saya lebih suka lupa. Saya mewarisi bagian dari proyek (proyek yang sama saya sebutkan dalam jawaban saya) yang dibangun di atas snapshot Spring RCP. Saya tidak pernah mengerti mengapa. Tampaknya tidak menambah apa pun kecuali kerumitan.
Dan Dyer

3

Salah satu contoh yang saya ingat terlibat komit ke server aplikasi Java tertentu sejak awal meskipun fakta bahwa ia belum memiliki fitur yang diperlukan untuk proyek, hanya peta jalan ketika mereka akan dilaksanakan. Tentu saja vendor tidak memberikan secepat yang ditunjukkan, yang seharusnya menjadi masalah besar tetapi pada kenyataannya hanya salah satu dari banyak ayam jantan di jalan lambat menuju kegagalan.

Sebagian besar contoh masalah yang saya temui ini melibatkan komitmen pada teknologi yang belum terbukti / belum matang, sering kali karena seseorang yang berpengaruh di sisi teknis adalah pendukung pembangunan yang digerakkan oleh resume.


1

Tiga tahun lalu, departemen BusDev kami mengatakan bahwa mereka harus membangun sistem mgmt konten mereka pada Documentum karena perusahaan-perusahaan Farmasi yang mereka coba jangkau mengetahui nama itu dan merasa nyaman dengan teknologi itu. Jadi kami menghabiskan banyak uang untuk membangunnya, lalu menyimpannya 12 bulan kemudian.

Pada bulan Februari tahun ini mereka mengumumkan sistem baru akan didasarkan pada Sharepoint 2010. Ingin menebak mengapa? Karena, tiba-tiba, INI adalah nama yang dikenal oleh Pharmas dan nama yang membuat mereka nyaman!
Kami akan melihat apa yang dibawa 2012!

\\ uSlackr


0

Menulis sistem operasi modern dalam C / C ++. Kami sudah tahu sejak Worm Morris (akhir 80-an) bahwa itu adalah bahasa yang sama sekali tidak cocok untuk membangun perangkat lunak jaringan, tetapi itu tidak menghentikan siapa pun untuk melakukannya, yang pada dasarnya sama dengan IMO kelalaian kriminal.


5
-1 Apakah ini saya, atau ini tentang kelima atau keenam kalinya Anda memposting tentang C sebagai kesalahan? FUD melelahkan. Hanya karena Anda tidak dapat kode C tanpa membuat kesalahan keamanan tidak berarti orang lain tidak bisa. Anda tidak dapat membenci bahasa berdasarkan praktik buruk apa yang mungkin terjadi.
alternatif

2
Ini adalah FUD untuk menyatakan bahwa fakta bahwa "C adalah bahasa yang buruk" adalah pengetahuan umum tujuan.
alternatif

2
@ mathepic: Apakah saya mengatakan sesuatu yang samar-samar karena itu "bahasa yang buruk"? Saya katakan itu sama sekali tidak cocok untuk membangun program, seperti sistem operasi, yang memiliki persyaratan keamanan. Dan itu adalah fakta objektif dan pengetahuan umum.
Mason Wheeler

6
@mathepic: Saya dengan Mason dalam hal ini. Telah diketahui secara luas dan diterima bahwa penanganan string dalam C menyebabkan buffer overflows dan dalam bahasa pemrograman yang tepat tidak . Tidak peduli seberapa bagus Anda berpikir bahwa Anda “andal, secara konsisten mengkode C dengan aman” (pff), bahasa yang tidak perlu meningkatkan insiden bug adalah bahasa yang buruk.
Timwi

3
@Timwi: Jawaban aslinya mengatakan "C / C ++". Di C ++, penanganan string tidak menyebabkan buffer overflows. Bukan berarti saya penggemar berat std::string, tapi itu berhasil, dan bersama dengan templat kelas kontainer dapat menghilangkan sejumlah besar kesalahan potensial.
David Thornley

0

Apa yang saya lihat ....

Kembali pada 1980-an, ada perusahaan bernama Prime yang memproduksi komputer yang menjalankan versi Pick database dan BASIC. Departemen pengguna tempat saya bekerja pada waktu itu membeli satu benar-benar yakin bahwa ini akan menghemat banyak uang, bahwa mereka akan mendapatkan pemrosesan dan hasil yang mereka inginkan dengan satu analis bisnis pada seperempat waktu. Tidak lama sama sekali sebelum ada empat analis program penuh waktu dan tumpukan pekerjaan.

Kesalahan besar dalam memperkirakan apa yang akan dilakukan teknologi untuk mereka.


1
Pick tua yang bagus. Saya selalu mempertanyakan memiliki OS / Database / Bahasa Pemrograman yang dinamai menurut nama mereka. (mis. Dick Pick)
Bill
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.