Apa ekonomi palsu terburuk dalam pengembangan perangkat lunak? [Tutup]


126

Apa ekonomi palsu terburuk (yaitu cara-cara menghemat uang yang akhirnya lebih mahal daripada yang mereka hemat) yang lazim di industri perangkat lunak dan bagaimana Anda memerangi mereka?


2
:( Saya telah melihat banyak dari ini terlalu sering.
Tony


@ Casey: Ini sedikit terkait, tetapi tidak sepenuhnya. Tautan yang Anda berikan berkaitan langsung dengan uang, sementara jawaban dalam pertanyaan ini di sini juga berkaitan dengan uang dan kepercayaan. Contoh, lihat jawaban saya: programmers.stackexchange.com/questions/19573/…
Gan

Apakah Anda baru saja mengunjungi perusahaan saya .. jangan pikirkan; P
pramodc84

1
@ Mark - terdengar seperti pertanyaan yang bagus, coba saja. Beberapa hal spesifik mungkin lebih baik.
Jon Hopkins

Jawaban:


182

Utang Teknis

yaitu "Lakukan saja dengan cepat, kami akan refactor nanti". Pertama karena saya belum melihat seseorang yang terlibat dalam perilaku ini sebenarnya refactor nanti. Kedua karena melakukan hal-hal dengan cara cepat, alih-alih cara yang baik membuat lebih sulit untuk menambahkan fitur di masa depan atau menyelesaikan bug di masa depan sehingga Anda akhirnya kehilangan waktu dalam jangka panjang.

Sayangnya, banyak yang masih berpikir itu menghemat siklus pengembang agar mereka melakukan sesuatu dengan cepat. Saya kira itu mungkin, tetapi saya belum melihatnya dalam praktik.


2
Saya tidak dapat menghitung berapa kali saya melihat manajemen menghentikan pengembang (2 hingga 3) selama satu hari kemudian spesialis penempatan untuk memperbaiki sesuatu (dan melakukan ini berkali-kali selama siklus hidup produk) daripada menghabiskan 2- 4 hari untuk melakukannya dengan benar. Jawaban yang bagus
DevSolo

4
Jika waktu yang diperlukan untuk memperbaiki dapat diukur dalam dolar, misalnya bug memperbaiki sistem perdagangan saham, maka keputusan manajemen akan condong ke arah pengurangan biaya. Saya telah menemukan bahwa mengusulkan untuk "menambalnya sekarang agar tetap berjalan sementara kami menentukan perbaikan yang tepat untuk memastikan ini tidak pernah terjadi lagi" memenuhi urgensi yang didorong oleh biaya dan juga mendapatkan hasil yang tepat, tetapi Anda harus berjuang untuk ini kadang-kadang .
JBRWilkinson

9
Kami memiliki seluruh kode dengan komentar seperti "Ini adalah retasan, ganti setelah demo" yang telah ada di pangkalan untuk berlangsung 3 hingga 5 tahun sekarang. Tidak ada yang bahkan ingat bahwa itu dilakukan pada saat ini, jadi tidak ada yang menemukannya sampai seseorang (saya) memperbaiki bug dan menjalankannya. Tak perlu dikatakan, pelajaran objek ini telah mengajarkan saya dengan sangat baik untuk melakukannya dengan benar pertama kali jika saya mampu melakukannya.
CodexArcanum

22
Dan jujur, saya terus dikejutkan dengan berapa kali bahkan tidak menghemat waktu jangka pendek!
PeterAllenWebb

6
@ Jorg - Hah? "Utang teknis dan utang desain adalah metafora sinonim dan identik yang merujuk pada konsekuensi akhirnya dari arsitektur perangkat lunak slapdash dan pengembangan perangkat lunak yang tergesa-gesa." en.wikipedia.org/wiki/Technical_debt Inilah yang saya maksud. Sebuah judul yang lebih spesifik akan mungkin telah "menimbulkan Teknis Utang Tanpa Intent untuk Membayar It", namun, banyak orang dalam situasi ini mengatakan diri mereka benar-benar berniat untuk membayar (tetapi tidak), dan saya ingin punchy judul untuk dimasukkan ke dalam teks tebal di bagian atas. "Hutang Teknis" tampaknya merupakan ringkasan yang cukup bagus.
Inaimathi

163

Mempekerjakan 2 pengembang murah bukannya 1 benar-benar hebat. (dengan harga yang sama)


9
Yang ini setidaknya tampaknya memiliki dasar dalam kenyataan; perlu diingat bahwa orang-orang non-teknis tidak bisa mengatakan siapa pengembang yang hebat (jadi mereka kemungkinan besar hanya membayar dua kali lipat lebih banyak daripada orang idiot yang berkonsultasi daripada menjadi superstar yang sebenarnya).
Inaimathi

112
Atau sayangnya, hanya menyewa 1 yang murah ...
DevSolo

4
... atau mempekerjakan seorang guru di mana dua boneka akan melakukan 1,5 dari apa yang guru lakukan untuk 1,0 dari gaji guru: /
bobah

14
Anda tidak mendapatkan 75% guru dari boneka , dan programmer yang benar-benar baik akan melakukan apa yang diperlukan tanpa menjadi sombong tentang hal itu.
Peter Boughton

8
Programmer 10x atau 100x adalah nilai uang yang luar biasa; mereka hanya dibayar 1,5 mungkin 2x. Seperti yang dikatakan Michael Lopp (Rands in Repose), jika Anda hanya menyewa salah satunya di seluruh karier Anda, itu adalah kemenangan bersih.
Tim Williscroft

85

Contoh saya akan menjadi kebalikan dari contoh NimChimpsky , yaitu:

Mencoba mengembangkan sesuatu yang dapat dibeli sendiri di rumah.

Biasanya ini terjadi karena kegagalan untuk benar-benar memeriksa pasar untuk melihat apakah ada sesuatu yang sudah ada yang akan menyelesaikan masalah. Ini dapat diperparah oleh pengembang yang suka "menyelam" pengkodean sebelum melakukan penelitian dan oleh manajer proyek yang gagal memperhitungkan waktu = uang.

Salah satu contoh paling umum yang pernah saya lihat di bidang saya, pengembangan web, adalah perusahaan yang mencoba mengembangkan dan sistem CMS internal. Ini selalu dimulai dari kecil, tetapi segera membengkak dan di luar kendali karena fitur melesat, sementara sepanjang waktu ada banyak produk gratis dan kerangka kerja di luar sana yang akan jauh lebih cocok.


17
Hanya karena itu bisa terjadi, tidak berarti harus demikian. CMS dasar, yah mengapa menciptakan kembali roda. Tetapi ketika Anda mulai berbicara tentang sistem skala besar dan memodelkan proses bisnis yang kompleks - mengapa mencoba dan memasang pasak bundar dalam lubang persegi? Terutama jika Anda memiliki pengembang dan keterampilan yang ada.
NimChimpsky

9
@NimChimpsky - Saya pikir ada contoh yang valid dari keduanya. Saya tentu saja melihat orang-orang menghancurkan proses bisnis mereka dan kehilangan keuntungan yang mereka miliki dengan mencoba menyesuaikannya dengan perangkat lunak, tetapi saya juga melihat pengembang menderita kode sindrom "tidak ditemukan di sini" hal-hal yang bisa mereka unduh karena itu lebih menarik bagi mereka.
Jon Hopkins

3
@NimChimpsky Jika spec membutuhkan pengembangan yang dipesan lebih dahulu, maka itu baik-baik saja - itu membuat kita tetap dalam pekerjaan :) Masalahnya muncul ketika orang tidak terlebih dahulu memeriksa apakah ada sesuatu yang sudah dikembangkan yang sesuai dengan tagihan dan terjun langsung ke dalam pengembangan. Sebuah penelitian kecil bisa sangat bermanfaat!
Dan Diplo

6
Mengapa menemukan kembali roda? Karena Anda seorang insinyur roda. Atau karena roda Anda lebih baik daripada roda pria berikutnya. Atau karena rodanya tidak pas. Lihat: mostlymaths.net/2010/03/…
Derek

2
Tempat saya bekerja hampir semuanya OTS bisa dibeli - dan hampir semuanya kembali menemukan di rumah karena menurut Pemimpin Fearless kami (tm) "lingkungan kita adalah begitu kompleks sehingga tidak ada di pasaran bisa mungkin mengatasinya". Pfeh! Tapi apa hei - membayar tagihan. Kami diberitahu kemarin bahwa komponen utama dari perangkat lunak kami akan ditulis ulang tahun depan - DENGAN INTERFACE GRAFIS! Ooooooh-aaaaaaah! Saya semua berkicau ... (<pheh!>)
Bob Jarvis

73

Tidak ada sumber daya khusus untuk manajemen proyek

Saya telah mengalami beberapa kali ketika beberapa programmer dikontrak, dan seseorang yang sudah memiliki pekerjaan harian yang menuntut seharusnya mengelola proyek, tetapi pada kenyataannya terlalu sibuk dengan tugas-tugas lain sehingga proyek tidak pernah benar-benar mendapatkan momentum. Pemrogram membuat "prototipe" dan semacamnya, tetapi tanpa petunjuk, sebagian besar berjalan berputar-putar agar terlihat sibuk.

Peralatan buruk untuk programmer baru

Saya pernah mengalami perusahaan di mana kebijakan itu adalah "programmer baru harus bekerja pada PC yang benar-benar tua dengan layar kecil sampai mereka membuktikan bahwa mereka layak". Tidak mengherankan bahwa kebijakan semacam itu menyebabkan seleksi negatif yang mengusir orang-orang baik yang selalu memiliki pilihan untuk bekerja di lingkungan yang lebih waras.


19
+1. Tidak menyediakan peralatan yang baik untuk karyawan Anda telah "pasti gagal" tertulis di atasnya.
Terence Ponce

3
+1. Tetapi perhatikan hal berikut: di banyak perusahaan, anggaran perangkat keras termasuk dalam infrastruktur dan terpisah dari anggaran pembangunan. Manajer infrastruktur tidak akan mengambil untung terhadap anggarannya untuk membantu mengurangi anggaran manajer pengembangan. Saya telah melihat permainan politik yang jahat ini beberapa kali.
Fil

3
Bagaimana dengan peralatan yang buruk untuk SEMUA programmer? Mantan majikan saya membayar kami upah Lembah Silikon untuk menulis kode pada desktop yang biasa-biasa saja lima tahun sebelumnya. Karena tenggat waktu yang ditiupkan, mereka memberhentikan setengah dari staf setahun yang lalu, dan sebagian besar sisanya pada bulan Juli - tapi nak, apakah mereka menghemat uang untuk peralatan!
Bob Murphy

1
Kaz: Setiap pengembang harus memiliki mesin yang memadai. Jika membeli perangkat keras baru berarti bahwa PC pengembang baru sedikit lebih baik daripada pengembang lain, well, dalam kasus terburuk Anda memiliki mesin swap jika mereka jenis orang yang sesuai ukuran kontol. Orang normal tidak akan peduli selama mereka memiliki perasaan yang memungkinkan mereka bekerja secara efisien. Di tempat saya bekerja saat ini, saya memiliki PC yang lebih baru (mungkin lebih cepat) daripada orang yang mempekerjakan saya. Orang-orang yang datang setelah saya memiliki PC yang lebih baru, mungkin lebih cepat. Tebak apa? Tidak ada yang peduli, karena semua mesin kami cukup cepat.
user281377

3
Ketika perangkat keras tidak memadai saya membuat titik untuk memberi tahu manajemen, biasanya dengan melakukan pekerjaan yang bermanfaat seperti memotong kuku saya atau membaca kertas selama kompilasi panjang. Saya mendapatkan mesin lambat yang lama? Tentu, tidak masalah. Oh, Anda punya perbaikan bug terburu-buru dan saya harus melakukan build? Tentu saja, Tuan-Manajer-bwana-sahib-bung - sampai jumpa dalam 90 menit! (Pernah seorang manajer bertanya kepada saya apa yang saya lakukan sepanjang hari - saya katakan padanya, "Bangun kembali aplikasi. Empat kali". "DALAM JAM DELAPAN?!?" Serunya. Butuh waktu 10 jam ". Mesin baru muncul tidak lama setelah ... :-)
Bob Jarvis

71

Kita dapat menghemat uang dengan membuat programer berfungsi ganda sebagai penguji / penulis teknis

Jika Anda membayar gaji programmer untuk pekerjaan penguji / penulis teknis, maka Anda membuang-buang uang dan kemungkinan mendapatkan pekerjaan yang berkualitas lebih rendah daripada seseorang yang telah mendedikasikan karir mereka untuk tugas itu. Juga, ketika seorang programmer menghadapi ujian tenggat waktu yang ketat dan dokumentasi sangat mungkin untuk dijatuhkan atau dilakukan setengah-setengah untuk memenuhi itu.

BTW: Pengembang SELALU menghadapi tenggat waktu yang ketat.


12
Orang pintar bisa melakukan kesalahan dengan baik.
Jon Hopkins

3
Saya sudah melakukan entri data, meskipun saya tentu tidak akan menurunkan tarif saya untuk itu. Mereka menginginkan seseorang yang cepat dan akurat untuk beberapa entri data penting, dan mereka tidak keberatan membayar setidaknya tiga kali lipat tingkat entri data. Pilihan mereka.
David Thornley

1
Saya berpendapat bahwa itu adalah tugas pemrogram untuk menguji kode mereka, tapi saya tidak yakin apakah itu yang Anda maksud.
Ben Lakey

3
Pemrogram harus menguji kode mereka sendiri, tidak dengan pengecualian memiliki penguji khusus yang profesional dalam memecahkan perangkat lunak.
JohnFx

1
Setuju tentang penulisan teknis, tidak setuju tentang pengujian. Pengujian adalah bagian alami dari penulisan perangkat lunak yang baik. Menulis teknis terlalu banyak bergeser dari pengkodean. Saya merasa saya perlu mengubah banyak gigi untuk beralih dari pengkodean ke penulisan teknis dan rasanya seperti penggunaan waktu saya yang buruk.
Adam Bruss

63

Meneliti / Membaca / Menulis kode yang tidak terkait dengan pengembangan produk adalah pemborosan sumber daya.

Beberapa programmer dan bahkan manajer percaya akan hal itu. Biasanya, mereka hanya melakukan pemrograman berdasarkan pengetahuan di kepala mereka, dan melakukan riset dan mencari jawaban ketika mereka menghadapi masalah. Mereka tidak terus meningkatkan pengetahuan mereka secara proaktif. Pendapat saya, kita harus selalu memperbarui diri, dan pengetahuan yang kita kumpulkan akan berguna bagi kita dalam memecahkan masalah yang ada dan di masa depan. Tentu saja, Anda harus mengalokasikan waktu Anda dengan bijak untuk melakukannya.

Ini juga mirip dengan jawaban Dan . Beberapa manajer hanya ingin pengembang cepat menyelam dan mengembangkan produk sesuai dengan persyaratan tanpa meneliti produk yang ada di pasar.


3
Saya berharap saya bisa membatalkan ini lebih dari satu kali.
MAK

1
Mari kita menulis perpustakaan GUI. Mari kita membangun toolkit perpesanan. Jika Anda tidak MENJUAL perangkat lunak, itu hanya bagian dari hal yang lebih besar, demi Tuhan gunakan saja implementasi orang lain. Poin keamanan untuk menggunakan solusi open source, Anda selalu dapat memperbaiki dan mendukungnya jika perlu. Jika Anda punya uang untuk membeli solusi dengan sumber termasuk melakukannya, tetapi berhati-hatilah dengan buruknya kualitas komponen perangkat lunak komersial. Vendor jarang menjual komponen kepada Anda dua kali sehingga Anda mungkin kecewa begitu Anda memilikinya (Saya tahu saya pernah bekerja di tempat-tempat yang telah digigit oleh ini sebelumnya)
Tim Williscroft

58

Dalam banyak kasus, offshoring membutuhkan lebih banyak uang. Di perusahaan saya sangat sulit untuk mendapatkan slot karyawan baru, kami sangat didorong untuk melakukan outsourcing. Juga sulit untuk mendapatkan kontraktor di tempat; ada rasio 3: 1 di lepas pantai dan di darat yang seharusnya mereka pertahankan. Akibatnya, banyak tim hanya menyewa selusin lepas pantai dan nyaris tidak menggunakannya sama sekali, hanya supaya mereka bisa mendapatkan 4 kontraktor di tempat.


18
+1. Pengalaman saya dengan off-shoring adalah bahwa hal itu pasti menghabiskan lebih banyak uang daripada menghemat.
Adam Crossland

2
+1, tetapi di luar negeri dapat berfungsi jika digunakan dengan benar

3
+1. Kami tampaknya mendapatkan pengembang lepas pantai yang berbeda di setiap proyek baru, yang berarti pengembang darat menghabiskan sebagian besar waktu mereka untuk mengajar model lepas pantai yang baru untuk bisnis dan model domain teknis selain memberikan dukungan teknis. Akhir dari proyek dan mereka pergi ke tempat lain dan kami mulai dari awal lagi dengan pengembang 'murah' berikutnya.
Chris Knight

8
banyak tim hanya menyewa selusin lepas pantai dan nyaris tidak menggunakannya sama sekali, hanya saja mereka bisa mendapatkan 4 kontraktor di tempat. Wow.
poolie

1
Dan lupa bahwa kehendak offshoring pada dasarnya memperpanjang batas waktu. Kami memiliki QA lepas pantai dan butuh 3-4 hari untuk mengambil kembali sesuatu yang dapat ditarik kembali oleh orang di kantor yang sama dalam waktu kurang dari satu jam karena perbedaan waktu.
HLGEM

50

Umpan balik panjang!

Itu terjadi pada semua orang: Anda membangun sesuatu yang menurut Anda luar biasa, dan ternyata Anda salah. Bukan itu masalahnya. Masalahnya adalah berapa lama Anda menghabiskan waktu membangun sebelum mengetahui bahwa Anda harus berhenti.

Pada level tinggi, Anda melihat masalah ini dengan siklus rilis panjang. Jika Anda membangun selama setahun tanpa umpan balik, Anda bertaruh sepanjang tahun. Semakin sering Anda melepaskan, semakin kecil judi Anda, dan semakin baik judi Anda.

Tetapi itu juga terjadi pada level terendah. Sebagai pengembang, saya sangat suka tinjauan kode yang sering (atau, lebih baik, pemrograman pasangan) karena membatasi jumlah waktu saya dapat terus melakukan sesuatu yang bodoh sebelum seseorang berkata, "Hei, ada cara yang lebih sederhana!" Untuk alasan yang sama, saya suka unit test saya berjalan dengan cepat dan sering, jadi saya bisa menangkap dan membunuh bug sebelum mereka tumbuh.

Setelah Anda mulai memperhatikan pentingnya loop umpan balik pendek, Anda akan melihatnya di mana-mana. Misalnya, gagasan militer tentang loop OODA .


6
+1. Juga: semakin lama umpan balik, semakin sedikit Anda ingat tentang tugas. Pada ekstremnya, Anda perlu memperkenalkan kembali diri Anda dengan seluruh basis kode lagi.
Joseph Tanenbaum

Bagaimana ini ekonomi palsu? Apa tabungan yang dimaksud?
Chris Pitman

Maksudnya adalah untuk menghemat waktu "terbuang" pada hal-hal yang Anda lakukan setiap loop. Misalnya, Membangun, menguji, melepaskan, memperhatikan pengguna. Itulah alasannya. Saya pikir itu benar-benar berakar pada penghindaran ketidaknyamanan.
William Pietri

Inilah sebabnya mengapa sangat penting bahwa pengulas dan teman pasangan memiliki kerendahan hati dan menghormati kode sandi sebanyak mungkin. Satu pengulas bermasalah yang memperlakukan pembuat kode dengan buruk dan Anda dapat menjamin bahwa umpan balik akan bertambah banyak.
Jonathan Neufeld

47

Bukan anekdot saya sendiri, tetapi saya pernah mendengar tentang sebuah toko yang berhenti memberikan kopi gratis kepada para pengembangnya, sebaliknya mengatakan kepada mereka bahwa setiap kali mereka ingin mendapatkan kopi, mereka bebas untuk berjalan ke kedai kopi terdekat (sekitar sepuluh menit) perjalanan setiap jalan) dan beli beberapa.

Cukup banyak definisi ekonomi palsu.


4
Itu cukup istimewa. Bandingkan dan kontraskan dengan beberapa bank dagang di London yang memiliki Starbucks bersubsidi yang dibangun di gedung untuk menghilangkan waktu yang diperlukan untuk keluar dan mendapatkan kopi.
Jon Hopkins

48
Saya tidak setuju bahwa ini otomatis ekonomi palsu - 10 menit udara segar saat berjalan di luar untuk membeli kopi akan mengoksidasi karyawan dan meningkatkan konsentrasi mereka dan (walaupun terbatas) interaksi sosial akan mengurangi depresi, terutama di musim dingin. Karyawan yang tidak mendapatkan kopi karena tidak gratis, kemungkinan akan pulang tepat waktu, lebih banyak tidur dan memiliki kesehatan yang lebih baik karena berkurangnya asupan kafein.
JBRWilkinson

6
-1, 20 menit berjalan kaki sangat cocok untuk membebaskan pikiran Anda, dan mendapatkan perspektif baru tentang masalahnya.
Malfist

23
@Malfist: Seperti yang saya mengerti, bukan hanya 20 menit berjalan kaki, tetapi juga 15 menit menunggu untuk benar-benar mendapatkan kopi yang mengganggu pekerjaan. Istirahat 45 menit pada suatu saat dalam sehari cukup banyak akan menghancurkan produktivitas selama lebih dari satu setengah jam. Semua untuk menghemat 100 dolar sebulan untuk kopi.
EricBoersma

8
20 + 15 = 35 [enam karakter lagi]
Malfist

47

Menyediakan workstation satu layar karena monitor kedua terlalu mahal . Bahkan jika itu hanya menghemat satu jam kerja setiap tahun, layar kedua masih merupakan investasi yang bagus. Saya tahu pasti bahwa pekerjaan saya telah menyelamatkan saya, berjam-jam.

Pengaturan multi-monitor dapat membuat hampir semua tugas lebih efisien, tidak hanya tugas pengembangan. Tiga monitor bahkan lebih baik daripada dua, tetapi efeknya menjadi kurang jelas dengan setiap layar tambahan.

Pengaturan multi-monitor:

  • mengurangi overhead peralihan jendela
  • memungkinkan Anda untuk mengawasi hal-hal yang berjalan di latar belakang (mail, kompilasi, dll.).
  • memberi Anda perasaan kebebasan. Ini seperti berada di atrium vs. berada di lemari sapu.
  • dll ...

2
Pernah menghadapi masalah itu sekali. Menulis surat kepada salah satu CEO kami yang menghitung dengan jelas bahwa dengan peningkatan efisiensi 5% saya akan menghemat sejumlah uang senilai monitor dalam waktu setengah bulan relatif terhadap pendapatan bersih saya. Perhitungan ini cukup ketat ... tapi ... Saya kira Anda sudah tahu akhir ceritanya :)
Raffael

39

Perangkat keras termurah diberikan kepada konsultan ketika biaya konsultan lebih dari $ 150 / jam .

Menempatkannya dalam perspektif perangkat keras yang lebih baik setidaknya dapat membuat pekerjaan 30 menit lebih efektif per hari. Itu akan memberi 30 menit * 20 hari kerja per bulan = 600 menit / bulan = 10 jam / bulan> lebih dari 1 hari kerja = 10 jam * 150 $ / jam = 1500 $

Sekarang bukankah konsultan akan bekerja lebih efisien jika ia memiliki komputer $ 1500? Apakah itu akan membuat konsultan tidak terlalu kesal?

Sekarang masalahnya tampaknya ada dua anggaran, satu untuk konsultan dan satu untuk perangkat keras PC.


8
Sebagai konsultan, saya pernah ke sana, melakukan itu, dan mendapatkan t-shirt. (Hanya mendapat $ 80 / jam.) Tapi hei, itu salah satu alasan saya suka kontrak per jam. Tidak seperti posisi bergaji, jika klien konsultan memilih untuk membuang waktu saya dan saya harus bekerja ekstra untuk menebusnya, itu lebih banyak uang di saku saya.
Bob Murphy

2
Jangan tersinggung, tetapi jika saya membayar $ 150 / jam untuk seorang konsultan, lebih baik dia memiliki komputer sendiri.
Steven Evers

8
@SnOrfus: Itu biasanya tidak berfungsi di lingkungan perusahaan, di mana ada kontrol ketat terhadap PC yang diizinkan pada domain. Anda harus memberi mereka perangkat keras.
HardCode

1
@ Kode Keras - Ya, saya kira. Saya bisa mengerti intinya sekarang.
Steven Evers

3
@HardCode Pada proyek baru-baru ini, alih-alih menambahkan kami (kontraktor) ke jaringan internal perusahaan mereka, mereka mengkarantina kami ke saluran DSL kami sendiri. Saluran DSL khusus untuk 3 pengembang @ $ 40 sebulan adalah perubahan besar dan membuatnya mudah bagi kami untuk mendorong pembaruan dari jarak jauh tanpa membuat staf TI panik. Plus, jika PC produksi yang menjalankan kode kita terinfeksi dan macet, itu secara otomatis menjadi kesalahan kita karena kita bertanggung jawab atas keamanan komunikasi dan laptop pribadi kita. Bisakah Anda mengatakan win-win-win.
Evan Plaice

38

Bulan kerja menghemat hari perencanaan

(Tidak menginvestasikan cukup waktu ke perencanaan)


21
Di sekolah pascasarjana ada ungkapan bahwa beberapa minggu di lab dapat menghemat satu jam waktu perpustakaan.
David Thornley

7
Ya. Ketika saya mengambil kelas laboratorium sarjana di mana kami mengidentifikasi bahan kimia yang tidak dikenal, prof mengatakan kepada kami "satu jam di perpustakaan akan menghemat empat di laboratorium". Saya menganggapnya serius, dan itu lucu untuk melenggang ke lab selama satu jam seminggu dan mendapatkan pandangan buruk dari pra-med yang menghabiskan dua belas jam seminggu melakukan tes amina pada senyawa yang jelas bukan amina. Dan ketika saya mengajar lab yang sama beberapa tahun kemudian, saya memberi para siswa saran yang sama, dan hanya sedikit yang benar-benar memakainya.
Bob Murphy

3
Jika Anda gagal merencanakan, Anda berencana untuk gagal

27

Saya kira yang paling lazim adalah manajer tidak menyediakan alat yang dibutuhkan pengembang untuk melakukan pekerjaannya secara efisien.

Pada dasarnya, poin 9 pada Tes Joel .


2
Saya telah mengerjakan proyek-proyek di mana mereka membuat kami membuang-buang waktu satu atau dua minggu daripada membeli, misalnya, perpustakaan seharga $ 300 dengan pekerjaan yang sudah dilakukan - dan lebih baik (kami bukan "pengembang kontrol" tempat saya bekerja.) Atau pilih beberapa perangkat lunak "karena dibuat oleh" ini atau itu "perusahaan" alih-alih mencari apakah ada alternatif yang lebih baik, kemudian buat hidup kita seperti neraka selama bertahun-tahun.
MetalMikester

Saya sendiri pernah mengalami yang itu. Alasan PM / klien adalah kami tidak memiliki item anggaran untuk membeli barang-barang untuk klien (perubahan kontak itu menyebalkan) sehingga kami harus menemukan kembali roda (lagi).
Ken Henderson

24

"Lempar (cukup) mayat pada masalah" sayangnya masih dapat digunakan di beberapa tempat. Hukum Brook menentang ini dari The Mythical Man-Month , meskipun beberapa membutuhkan pengalaman untuk mempelajari pelajaran ini. Secara umum, ini bukan sesuatu yang bisa saya hentikan karena manajemen mungkin percaya pernyataan palsu tentang menambahkan orang dan tidak harus membayar harga untuk itu.


2
+1. Ya Tuhan. Ini saat ini terjadi pada skala epik pada proyek besar tempat saya bekerja.
Bobby Tables

3
Saya bekerja dengan sekelompok pemimpin proyek, manajer, dll, yang semuanya memiliki sertifikasi manajemen proyek yang sangat bagus (apa pun namanya) dan BUKAN SATU DARI MEREKA pernah mendengar tentang The Mythical Man-Month sebelum saya memperkenalkan mereka untuk itu. Sheesh!
Bob Jarvis

2
Saya mendengar kutipan hebat tentang ini sekali: 9 wanita tidak bisa menghasilkan bayi dalam sebulan
Richard

@ Richard Saya menggunakan yang itu dalam rapat. memberi saya kesenangan luar biasa!
Tjaart

21

Pertemuan sehari-hari :

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...  

9
Bertemu hanya demi pertemuan ...
Gan

5
Agenda untuk hari ini: Apa yang akan ada dalam agenda untuk pertemuan besok?
Mark C

9
Rapat harian baik-baik saja jika ini singkat; Rapat stand-up 3 menit bergaya scrum tidak membuang banyak waktu, tetapi tetap perhatikan semua orang tentang perkembangan orang lain. Namun, pertemuan panjang dengan banyak peserta yang tidak tertarik adalah racun.
9000

3
@ Mark C - Ini mungkin terdengar seperti lelucon, tapi saya sebenarnya diundang ke rapat untuk merencanakan apa yang akan menjadi agenda pertemuan hari berikutnya ...
Gavin Coates

@ Gavin Coates ini nyata dan situasi ... :)
Zzz

20

Membeli perangkat lunak bukan mengembangkannya secara internal.

Saya memiliki pengalaman sistem manajemen skala entreprise, yang fokus pada HR dan Laboratorium Biologi.

Solusi yang tidak mahal harganya £ 50-100 ribu dan membutuhkan pengembangan dan penyesuaian lebih lanjut untuk memenuhi persyaratan bisnis.

Solusi yang dikembangkan secara internal membutuhkan waktu (<6) bulan untuk berkembang, dengan proyek lain sedang dikerjakan secara paralel, dan memanfaatkan pengembang yang sudah bekerja.

Saya beralih dari sektor publik tempat kami menjalankan LIMS (sistem manajemen informasi lab) internal dan menjalankannya, ke sebuah perusahaan farmasi internasional besar di mana penerapan solusi off the shelf memakan waktu lebih dari setahun dan tidak ada tempat yang lengkap.

(6 bulan pengembang sudah dipekerjakan bekerja pada proyek-proyek lain secara paralel. Jadi ~ 10k. Dan itu tidak termasuk biaya dukungan yang terkait dengan solusi off-rak). Poin utama adalah bahwa sistem yang dikembangkan secara internal sebenarnya sedang digunakan! Jadi Anda kemudian memiliki manfaat biaya tambahan yang terkait dengan itu, yang saya tidak dapat hitung.

Saya setuju untuk situs web dasar dll, mengapa repot mengembangkan situs Anda sendiri. Tetapi untuk sistem kompleks besar dan jika Anda sudah memiliki keterampilan di rumah, saya akan membangunnya sendiri .


26
Saya yakin ada banyak contoh yang berlawanan juga.
Jon Hopkins

13
Untuk membeli atau mengembangkan, turun ke orang yang tepat melakukan uji tuntas. Sederhana seperti itu. Berpikirlah sebelum bertindak. (+1)
DevSolo

4
@DevSolo: tepat. Keputusan build-atau-beli harus didukung oleh analisis biaya-manfaat, daripada sikap emotif 'tidak ditemukan di sini' atau 'Saya suka perangkat lunak XXX'.
JBRWilkinson

9
Jika Anda akan membuat pernyataan menyeluruh tentang build vs buy, seharusnya: lebih memilih untuk membeli solusi untuk masalah yang bukan bagian dari kompetensi inti perusahaan Anda. Ini tidak selalu merupakan jawaban yang tepat, tetapi ini adalah posisi default yang masuk akal, dan hampir dapat diandalkan seperti klise. Untuk mengatakan bahwa membeli peranti lunak yang tidak tersedia adalah ekonomi yang salah, meskipun, bahkan bukan klise yang berguna. Saya merasa sakit hati karena solusi 'E' (yang seharusnya berarti 'Perusahaan', tetapi sebenarnya berarti 'Mahal' '). Tetapi kehadiran opsi yang buruk tidak berarti tidak ada yang bagus di luar sana.
evadeflow

2
Saya pikir masalahnya adalah membeli dan kemudian masih membutuhkan pengembangan lebih lanjut dan kustomisasi , biaya sedikit penyesuaian pada sistem yang dibawa sering dapat lebih dari menulis sistem kecil Anda sendiri yang hanya melakukan apa yang Anda inginkan. Jadi beli jika Anda dapat bekerja dengan cara sistem yang Anda beli mengharapkan Anda untuk bekerja, tetapi membeli & kustomisasi dapat memberikan yang lebih buruk dari kedua belah pihak!
Ian

15

Membeli produk yang mahal saat alternatif sumber terbuka lebih baik dan gratis.

Berapa banyak perusahaan yang menggunakan git? Berapa banyak perusahaan yang menggunakan kontrol versi perusahaan yang jelek?


1
Eh, bisakah ini dianggap "ekonomi palsu terburuk"? Atau mungkin Anda perlu menguraikan lebih lanjut ...?
Gan

3
Saya tidak yakin saya sepenuhnya setuju dengan contoh kontrol sumber, paling tidak. Git secara khusus dirancang untuk memecahkan masalah open-source: Banyak pengembang, sedikit kendali pusat, banyak cabang, dll. Perangkat lunak "enterprisey" bekerja di bawah serangkaian asumsi yang berbeda: Kebutuhan untuk mengelola berbagai produk di seluruh bisnis, keamanan, alur kerja, dll.
PeterAllenWebb

1
@ Gan: Mereka pikir menggunakan open source adalah ekonomi palsu, tetapi mereka memiliki semuanya mundur.
hasen

3
Saya seorang kontributor untuk X11 dan GNOME, dan cukup kompeten dalam menggunakan git dan mengelola server gitosis. Meskipun demikian, musim panas ini saya mengalihkan pekerjaan konsultasi saya dari git ke server Perforce yang dibayar secara pribadi karena melakukan banyak hal secara otomatis yang harus Anda lakukan secara manual dengan git. Karena saya dibayar untuk mengirimkan kode dan tidak bermain-main dengan kontrol versi, menggunakan dan membayar untuk "kontrol versi jelek perusahaan" jauh lebih hemat biaya daripada menggunakan git.
Bob Murphy

7
Open source vs produk komersial benar-benar merupakan dasar "kasus per kasus" dalam pengalaman saya.
MetalMikester

14

Menggunakan bahasa "sederhana" tanpa banyak ekspresi

Ya, ini membuatnya lebih mudah untuk menemukan programmer untuk menjaga kode, tetapi membuatnya lebih sulit untuk menemukan programmer yang baik yang tidak hanya mempelajari kata kunci terbaru yang akan membuat mereka dipekerjakan. Ya, itu membuat kode bit individual lebih mudah dimengerti, tetapi juga membuatnya sekaku 2x4 dan meningkatkan volume kode yang perlu dipahami. Ya, itu didukung oleh sebuah perusahaan besar, tetapi mengatakan perusahaan besar berinovasi dengan lambat dan birokratis.


4
@burnt_hand: Saya pada dasarnya merujuk pada keengganan risiko manajemen yang berlebihan dalam hal pilihan bahasa.
dsimcha

1
+1: Tetap gunakan C karena "kami memiliki keterampilan itu dan mempelajari beberapa bahasa baru yang mewah seperti Python / Perl / PHP menambah banyak risiko". Mendengarnya lebih dari sekali. Apakah itu berarti tim terlalu bodoh untuk belajar bahasa baru?
S.Lott

1
@ S.Lott Agen Perekrutan mengira Anda !, tapi itu cerita lain
burnt_hand

2
yaitu perusahaan yang tetap menggunakan Java dan C # dan terlalu takut untuk menyentuh python atau ruby ​​karena mereka bukan "standar industri", yang mengingatkan saya pada: paulgraham.com/avg.html
hasen

1
@hansen: Esai Paul Graham sebagian menginspirasi saya untuk menulis posting ini. Inspirasi saya yang lain adalah pekerjaan saya mengembangkan perpustakaan (termasuk perpustakaan standar) untuk bahasa pemrograman D.
dsimcha

13

Manajer proyek / pemimpin tim yang buruk.

Karena satu orang yang tidak kompeten memiliki kekuatan untuk merusak pekerjaan sekelompok orang. Pada akhirnya, proyek akan jauh lebih baik tanpa keputusan manajemen atas (pimpinan proyek / tim).

Dosis "Lakukan saja dengan cepat, kami akan refactor nanti" memutuskan.


4
Saya setuju bahwa ada manajer yang buruk, tetapi "proyek akan jauh lebih baik tanpa keputusan manajemen atas"? Umumnya ini adalah orang-orang yang mensponsori proyek. Bagi saya ini agak mirip dengan pengembang yang saya temui yang berpikir memahami teknologi lebih penting daripada memahami bisnis dan melupakan siapa pelanggan sebenarnya.
Jon Hopkins

2
@ Jon Hopkins Dengan manajemen atas saya tidak merujuk pelanggan. Intinya adalah "manajer proyek yang buruk" adalah mereka yang melakukan kesalahan demi kesalahan, dan menentang sekelompok orang. Menurut Anda siapa yang memutuskan, "Lakukan saja dengan cepat, kami akan refactor nanti". Baca jawabannya dengan nilai tertinggi!
Amir Rezaei

ah, lebih jelas. Saya menghapus -1 saya.
Jon Hopkins

Saya telah memperhatikan tren yang mengganggu manajer proyek yang memuja waktu dan biaya dibandingkan kualitas. Saya yakin saya bukan satu-satunya. PM suka menggunakan diagram segitiga dengan Biaya / Kualitas / Waktu di atasnya tetapi Kualitas selalu mendapatkan boot pertama. Ini sangat menyedihkan, dan melembagakan dan memaksa metrik manajemen proyek (PMI) pada sesuatu yang rumit seperti perangkat lunak hanya tampaknya membuat segalanya lebih buruk.
Bernard Dy

1
@Bernard - waktu dan biaya dapat diukur. Kualitas? Tidak terlalu banyak. Sedih tetapi IMO benar ...
Bob Jarvis

12

Persyaratan pengguna tidak ada

Langkah penting dan sulit dalam merancang produk perangkat lunak adalah menentukan apa yang sebenarnya diinginkan pelanggan untuk dilakukan.

Percaya atau tidak kadang-kadang bagian ini hilang atau ketinggalan jaman. Apa yang terjadi pada biaya adalah bahwa seseorang menciptakan fungsionalitas yang tidak pernah diminta oleh pengguna akhir.


Saya pikir ini harus di atas!
Roopesh Shenoy

8

Produktivitas bernilai lebih dari kreativitas

Kreativitas sulit diukur secara umum, dan paling sering tidak mungkin untuk diamati, apalagi ukurannya, ketika menyangkut pengembangan perangkat lunak. Produktivitas, di sisi lain, dapat diukur (seringkali buruk), dan dapat diamati.

Akibatnya, pengembang yang dapat (menulis lebih banyak baris kode | menulis kode lebih cepat | membaca technobabble lebih cepat dalam menanggapi pertanyaan | lebih produktif) cenderung lebih dihargai daripada mereka yang (menggunakan lebih sedikit baris kode untuk menyelesaikan masalah yang sama | membutuhkan waktu lebih lama untuk menulis kode, tetapi menghasilkan produk yang lebih dapat diandalkan | memahami materi pelajaran dengan cukup baik untuk menjawab pertanyaan dengan jelas, mudah dimengerti, Bahasa Inggris | menyelesaikan masalah secara kreatif).


6

Semua di bawah ini bisa buruk jika digunakan atau tidak digunakan dengan tidak tepat

  • perangkat lunak internal vs internal

  • Kepatuhan ISO 9001 (ekonomi - mitigasi risiko kerugian SPM jika kualitas produk turun)

  • pengembangan / outsourcing QA

  • prosedur pengembangan / pembangunan / pelepasan / dukungan


Bagaimana ISO 9001 merupakan "ekonomi" (salah)?
Andrew Grimm

@Andrew Grimm - kepatuhan memastikan tingkat kualitas tertentu yang mengurangi risiko akibat kualitas yang buruk (misalnya hilangnya MSS) sehingga potensi ekonomi menjadi jelas. Untuk departemen kecil ini mungkin tidak pantas karena kerugian pada overhead lebih tinggi daripada risiko potensial
bobah

1
@Andrew - dalam pengalaman saya itu tergantung apa yang Anda inginkan. Jika Anda ingin meningkatkan kualitas, itu mungkin ekonomi yang salah karena cenderung mahal dan tidak cocok untuk perangkat lunak. Jika Anda menginginkannya sebagai hal pemasaran atau karena hanya diharapkan dalam industri Anda, maka itu berpotensi ide yang baik.
Jon Hopkins

5
@Andrew Grimm - "Satu-satunya" yang dijamin oleh ISO 9001 adalah kualitas yang konsisten dan dapat diulang. Itu tidak menjamin kualitas "tinggi". Namun, jika kualifikasi ISO 9001 adalah yang dibutuhkan dalam ruang pasar yang diinginkan perusahaan, maka itu diperlukan.
Vatine

1
@Vatine: Apa yang dijamin ISO 9001 konsisten, proses yang berulang. Di beberapa bidang, di mana proses yang konsisten menghasilkan kualitas yang konsisten, itu penting. Itu tidak menjamin kualitas tinggi, tetapi jika pelanggan melihat sesuatu yang telah Anda lakukan dengan baik dan tahu bahwa Anda bersertifikat ISO 9001, mereka akan yakin dengan kualitas yang sama.
David Thornley

4

Memiliki terlalu banyak manajer pengiriman yang tidak dapat ditagih.

Beberapa tahun yang lalu, di perusahaan kami, kami memiliki beberapa proyek anggaran besar yang sedang berlangsung dan rekrutmen sedang memuncak. Pada waktu itu perusahaan kami mempekerjakan terlalu banyak manajer pengiriman (Banyak dari mereka bukan IT!) Dan sangat sedikit coders / penguji. Rasio Manajer terhadap Pemrogram adalah 1: 2. Kemudian, setelah menyelesaikan proyek-proyek itu, kami menghadapi situasi di mana kami memiliki banyak manajer ini (beberapa di antaranya adalah pemalas) yang duduk di bangku tanpa melakukan apa pun. Kami memiliki satu siklus penilaian di mana semua orang mendapat sedikit / tidak ada kenaikan gaji (Bahkan kami programmer yang bekerja keras, desah) sehingga perusahaan tidak perlu memberhentikan siapa pun! Untungnya, perusahaan menyadari situasi ini dan melakukan RIGHTSIZING pada kuartal pertama tahun ini!


3

Optimasi sebelum pembuatan profil (alias optimasi prematur).

Sudah terlalu sering saya melihat seseorang meraih solusi cerdas yang tidak perlu mempersulit pemeliharaan dan keterbacaan dengan alasan lebih cepat. Secara alami, kode tersebut belum ditandai (bahkan tidak dengan tolok ukur mikro), sehingga dengan cepat menjadi "lebih cepat berdasarkan argumen yang lebih persuasif" pada bagian kode yang kemungkinan besar tidak memengaruhi kinerja keseluruhan keseluruhan aplikasi oleh banyak.

Karena itu, ini adalah ekonomi yang sangat palsu, dan jenis ekonomi palsu yang kadang-kadang melibatkan bahkan para profesional yang berpengalaman sekalipun.


3

Terbatas atau tidak ada akses internet

Karena jelas karyawan Anda akan menggunakan internet untuk bermain game facebook dan tidak terlalu mencari jawaban untuk pertanyaan teknis di Stackoverflow.

Pada kenyataannya tentu saja internet adalah dorongan produktivitas yang sangat besar, dan walaupun mungkin tepat untuk menggunakan semacam filter situs untuk situs yang benar-benar cerdik, ada yang salah jika memblokir file readme studio visual atau memblokir halaman pemerintah daerah telford karena suatu alasan. "pariwisata seks"


2

Membuat pengembang Anda menggunakan monitor 15 inci dan PC dengan spesifikasi rendah karena merupakan standar perusahaan.

Monitor berukuran wajar yang murah, cepat untuk menginstal dan membuat programmer lebih produktif serta membuat programmer Anda berpikir Anda peduli tentang mereka.


2

Terlalu banyak Sarjana Administrasi Bisnis (atau sejenisnya), yang diorganisasikan secara hierarki, yang mencoba menerapkan apa yang mereka pikirkan tentang manajemen modern: Mengganggu orang dengan "KPI", "SLA" dan yang tidak, membutuhkan "laporan" (tanpa, tentu saja, memperhatikan infrastruktur untuk menghasilkan mereka), sehingga programmer menghabiskan hari-hari mereka dengan mengisi lembar EXCEL yang mewah, laporan Q4 dan apa yang tidak dan menyalin dari satu alat manajemen baru yang hebat dan menempelkannya ke yang lain (tampaknya menjadi aturan bahwa alat-alat ini tidak pernah saling memadukan dan tidak dapat saling menyatu), dan menghadiri pertemuan di mana laporan dan angka disajikan (dan semua orang dibuat merasa bersalah karena gagal memenuhi KPI ini atau itu).

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.