Harapan lulusan versus kenyataan [tertutup]


50

Ketika memilih apa yang ingin kita pelajari, dan lakukan dengan karier dan kehidupan kita, kita semua memiliki beberapa harapan tentang seperti apa jadinya nanti. Sekarang saya telah berada di industri ini selama hampir satu dekade, saya telah sedikit merenungkan apa yang saya pikirkan (ketika saya belajar Ilmu Komputer) pemrograman akan seperti apa kehidupan kerja, dan bagaimana itu sebenarnya berubah menjadi menjadi.

Sejauh ini, dua kejutan terbesar saya (atau harus saya katakan, harapan rusak) adalah banyaknya pekerjaan pemeliharaan yang terlibat dalam perangkat lunak, dan kurangnya profesionalisme:

  1. Pemeliharaan : Di uni, kami semua diberitahu bahwa sebagian besar pekerjaan perangkat lunak adalah pemeliharaan sistem yang ada. Jadi saya tahu untuk mengharapkan ini secara abstrak. Tetapi saya tidak pernah membayangkan betapa luar biasanya hal ini nantinya. Mungkin itu adalah sesuatu yang secara mental saya sayu, dan berharap saya akan membangun lebih banyak barang baru yang keren dari awal. Tetapi sebenarnya adalah sebagian besar pekerjaan sangat pemeliharaan, perbaikan bug, dan berorientasi dukungan.

  2. Kurangnya profesionalisme : Di uni, saya selalu mendapat kesan bahwa pekerjaan perangkat lunak komersial sangat berorientasi pada proses dan direkayasa secara ketat. Saya memiliki gambar proses ISO, rim dokumentasi teknis, setiap fitur dan bug yang didokumentasikan secara ketat, dan lingkungan yang umumnya profesional. Itu merupakan kejutan besar untuk menyadari bahwa sebagian besar perusahaan perangkat lunak beroperasi tidak berbeda dengan tim siswa yang bekerja pada proyek besar sepanjang semester. Dan saya telah bekerja di toko retas kecil, dan perusahaan menengah. Walaupun saya tidak akan mengatakan bahwa itu selalu "tidak profesional", rasanya industri perangkat lunak (secara keseluruhan) jauh dari disiplin teknik yang kuat seperti yang saya harapkan.

Adakah orang lain yang memiliki pengalaman serupa dengan ini? Apa cara di mana harapan Anda akan seperti apa profesi kita akan berbeda dengan kenyataan?


4
Sebagai seorang mahasiswa yang hampir keluar dari universitas, ini adalah pertanyaan yang sangat menarik! Tidak sabar untuk melihat beberapa jawaban
Mike42

8
Apa yang Anda lihat sekarang adalah kenyataan. Fakta-fakta menyenangkan lainnya yang juga termasuk dalam kenyataan adalah: milyaran orang tanpa makanan, buta huruf, di bawah ancaman peperangan yang konstan, pasar keuangan hampir runtuh, dll. Dengan kata lain, perguruan tinggi adalah bidang realitas-distorsi-indah, dan orang-orang dapat pelajari banyak pengetahuan buku teks di dalam perlindungan bidang ini.
rwong

Anda harus mengharapkan apa pun yang Anda inginkan. Jika ternyata sesuatu yang kurang dari yang Anda harapkan tidak menerimanya sebagai kenyataan. Jadilah perintis dan jadikan harapan Anda kenyataan!
Atomix

1
Saya suka pemrograman. Saya benci kenyataan bagaimana perangkat lunak sedang dikembangkan di dunia "nyata". Apa yang Anda gambarkan adalah akun yang cukup akurat tentang keadaan dalam industri perangkat lunak.
Kapten Sensible

Sebagai Fresh Jr.Software Engineer, saya juga mengalami ini, saya pikir ini hanya di negara saya, sekarang saya mendapatkan fitur Unwritten dari Pengembangan Perangkat Lunak.
Parmanand

Jawaban:


27

Saya merasa Anda laki-laki. Saya baru saja lulus sedikit lebih dari setahun yang lalu, melompat pada tawaran pekerjaan pertama yang datang kepada saya dan mendapat kejutan terbesar dalam hidup saya.

Hal-hal yang tidak saya harapkan:

Stres sekolah dan Stres kerja tidak sama - Stres bekerja pada proyek sekolah dengan teman-teman, atau bekerja sendiri, bahkan dengan tenggat waktu tesis yang menjulang atau pertahanan proyek khusus tidak sebanding dengan stres tenggat waktu kerja yang tampaknya tidak masuk akal, masalah komunikasi , (sedikit politik kantor) dan masa krisis.

Kurangnya Praktik Terbaik - Sama seperti pengalaman Anda tentang profesionalisme. Sebelum mengambil pekerjaan pertama saya dan selama periode pelatihan saya, saya bergegas meninjau dan membaca tentang praktik terbaik dalam pemrograman dan rekayasa perangkat lunak. Ini tidak diikuti sebagaimana mestinya karena tidak praktis dan, untuk alasan yang adil, praktis. Dan kadang-kadang, pengetahuan Anda tidak berarti banyak terhadap orang lain yang hanya takut pada yang tidak diketahui dan memperlakukan praktik ini dengan jijik.

Apa yang mereka ajarkan di sekolah hanyalah puncak gunung es - Berpikir bahwa apa yang saya pelajari belajar sendiri dan dari kelas sudah cukup untuk membuat saya lulus, saya terkejut untuk sedikitnya ketika saya menatap tercengang pada potongan pertama kode saya. seharusnya mempertahankan. Banyak keterampilan yang saya gunakan sekarang dipelajari di pekerjaan atau selama pekerjaan saya yang saya terus bertanya-tanya apakah saya bisa membuatnya tanpa gelar sarjana sama sekali. XD

Pentingnya Komunikasi - Membuat saya sadar untuk apa semua kelas bahasa Inggris itu. Sebelum dunia nyata, saya tidak bisa melihat relevansi memiliki tiga hingga empat kelas bahasa Inggris yang berbeda di perguruan tinggi ketika sudah diajarkan sejak kami di kelas satu. Anda tidak berguna dalam pekerjaan Anda ketika Anda dapat berbicara dengan komputer tetapi gagal berbicara dengan orang lain.


5
+1 Pentingnya komunikasi. Adapun # 2, itu bukan kurangnya praktik terbaik; itu (i) terlalu banyak praktik terbaik , dan (ii) kurangnya minat dalam mengikuti apa pun.
rwong

1
+1 untuk puncak gunung es! Begitu banyak lulusan berpikir mereka tahu segalanya, sekarang aku merasa aku tahu lebih sedikit dari sebelumnya!
billy.bob

+1 Beberapa poin bagus di sini. Seringkali alasan kurangnya praktik / sistem / prosedur terbaik adalah 'biaya' di muka (yaitu membutuhkan belanja modal untuk membeli) - tetapi harga karena tidak memilikinya adalah peningkatan pemeliharaan atau, lebih buruk lagi, kegagalan produk melalui daftar bug yang melarikan diri atau tidak memenuhi persyaratan .. komunikasi yang baik dapat membantu untuk menghindari :-)
JBRWilkinson

2
Saya suka jawaban ini. Itu bagus. Dan itu membuat saya bertanya-tanya: mengapa tidak ada semacam "magang" seperti yang harus dilalui semua dokter medis? Sebuah zona transisi profesional yang panjang dan serius di mana seseorang dapat terlibat tetapi tidak menghalangi jalan kritis proyek apa pun. Beberapa perusahaan besar mungkin memiliki itu, tetapi itu bukan standar universal dalam profesi ini. Namun pekerjaan yang dilakukan oleh banyak programmer / pengembang SW / insinyur SW sama berbahaya dan kritisnya bagi organisasi dari semua jenis, seperti apa yang dokter lakukan untuk individu.
DarenW

1
Jika memungkinkan saya akan memberikan +1 ekstra untuk titik puncak gunung es!
DarenW

18

Sebagian besar pekerjaan yang Anda lakukan tidak merusak

Ketika di Uni, saya bekerja pada rutinitas AI untuk mengendalikan robot yang bermain sepak bola, saya membuat kompiler dan meretas kernel sistem operasi.

Namun di dunia nyata, 99% * pengembangan perangkat lunak sebenarnya cukup membosankan. Saya selalu mengagumi arsitek atau pembangun yang, ketika ditanya "apa pekerjaan Anda?" dapat menunjuk ke sebuah bangunan atau apa pun dan mengatakan "Saya melakukan itu ". Tetapi kebanyakan pengembang perangkat lunak tidak dapat melakukan itu. Ketika ditanya "apa pekerjaanmu?" yang paling dekat dengan yang pernah saya dapat datang adalah ketika saya dulu bekerja untuk sebuah perusahaan yang membangun perangkat lunak yang memproses pesan SMS untuk stasiun radio dan sejenisnya ... Saya bisa mengatakan, "Anda tahu kapan Anda mengirim pesan teks ke sebuah stasiun radio untuk memilih lagu, yah saya menulis perangkat lunak yang memproses suara dan barang-barang itu. " Masih belum ada yang sedingin mungkin menunjuk ke sebuah bangunan dan berkata "Aku membangun itu."

Tentu saja, ada yang orang yang bisa mengatakan "Saya bekerja pada Windows" atau apa pun, tapi aku yakin mereka tidak benar-benar memberitahu siapa pun bahwa karena takut pertanyaan makhluk berikutnya "Saya tidak bisa mendapatkan printer saya untuk bekerja, bisakah kamu memperbaikinya untukku? "


* dan 62% dari semua statistik dibuat di tempat


1
ini benar, tetapi bukan terobosan bukan berarti itu tidak penting atau penting. Ada banyak aplikasi yang bukan merupakan terobosan yang tanpa dukungan dan perbaikan, mungkin macet mengatakan ekonomi kita (di sisi ekstrem ...) ... ditambah akan selalu ada inovasi tergantung pada proyek dari waktu ke waktu ...
aggietech

3
Banyak dari kita membuka jalan baru setiap hari. Ini mungkin bukan obat untuk kanker, tapi kami merayakan kemenangan kecil dengan balita semua, putaran kue / muffin / donat, dll, untuk menandai momen tersebut. Banyak pekerjaan, tidak hanya pemrograman, tidak memiliki output yang dapat Anda tunjukkan kepada teman / keluarga Anda, tetapi itu masalah pembingkaian: Anda bisa mengatakan "Saya mengonfigurasi switch jaringan, server DNS, dan Firewall", atau Anda dapat mengubah frase ini sebagai "Anda tahu internet - Facebook, YouTube, Twitter, dan semua itu? Yah, saya bantu membuatnya berfungsi".
JBRWilkinson

1
@JBRWilkinson: +1. Kasus terbaik "membingkai ulang" yang pernah saya miliki adalah dengan pekerjaan sebelumnya di mana saya bekerja pada perangkat lunak pager rumah sakit NurseCall. Anda dapat mengatakan sesuatu yang umum tentang itu seperti "Saya menulis program yang menjalankan beepers". OTOH, Anda juga dapat mengatakan "Saya menulis perangkat lunak yang membantu rumah sakit berjalan lebih baik dan saya mungkin menyelamatkan nyawa !!". Belum memikirkan hal itu sampai sekarang ... tetapi secara statistik itu mungkin benar. Saya sebenarnya merasa jauh lebih baik tentang pekerjaan itu sekarang. yaitu perangkat lunak yang keluar ke produksi sebelumnya berkat usaha saya, dll. Mungkin benar-benar menyelamatkan nyawa. :)
Bobby Tables

1
@ Guzica: Bahwa Anda bisa / berkontribusi untuk menyelamatkan nyawa setiap hari mungkin adalah kepuasan kerja terbaik yang bisa dilakukan siapa pun - dilakukan dengan baik!
JBRWilkinson

1
Haha, jawaban luar biasa dan +1 karena memiliki selera humor!
Kapten Sensible

17

Jika Anda melihat perangkat lunak hari ini, melalui lensa sejarah teknik, itu pasti semacam rekayasa — tapi itu jenis rekayasa yang dilakukan orang tanpa konsep lengkungan. Sebagian besar perangkat lunak saat ini sangat mirip dengan piramida Mesir dengan jutaan batu bata bertumpuk satu sama lain, tanpa integritas struktural, tetapi hanya dilakukan dengan kekuatan kasar dan ribuan budak. -Alan Kay, 2004

wawancara lengkap: http://queue.acm.org/detail.cfm?id=1039523

Saya bukan dokter hewan industri; Justru sebaliknya, saya lulusan baru tetapi dari sekolah CS top di AS Tapi perasaan insting saya adalah bahwa cara kita membangun perangkat lunak salah. Alih-alih menekan tombol jeda dan memeriksa kembali dasar-dasar bagaimana kami memprogram kami baru saja bergegas maju menggunakan model tanggal dari 50-an, 60-an terus menambahkan sedikit gula di atas. Jika kita terus seperti ini, kita tidak akan pernah melewati di mana kita berada. Manusia tidak bisa mengelola kompleksitas hal-hal yang merupakan ukuran dari basis kode MS Windows. Kami membutuhkan cara baru. Saya tidak tahu apa itu.

Saya pikir ini adalah alasan yang mendasari perasaan bahwa toko-toko perangkat lunak besar dan kecil tampaknya membuat perangkat lunak dengan meretasnya bersama tanpa pemahaman mendalam tentang prinsip-prinsip dasar.


Sebagai lulusan yang relatif baru, saya mendapat kesan bahwa cara banyak tempat melakukan perangkat lunak adalah salah, tetapi tempat kerja saya saat ini adalah ... tidak sempurna, tetapi mereka mencoba, dan itu bekerja jauh lebih baik . Tentu saja tampaknya ada cukup banyak tempat yang menggunakan pendekatan "brute force" yang mengerikan ... tetapi jika Anda berada di salah satu tempat itu, pertimbangkan untuk mencari tempat lain.

1
Pengembangan perangkat lunak secara keseluruhan adalah proses evolusi, bukan revolusioner. Tentu, Anda bisa membangun struktur piramida dari karbon nanotube secara teori yang lebih kuat, lebih tahan lama, dan lebih ringan daripada teori piramida Mesir. Tetapi tidak praktis atau layak untuk melakukannya. Jika tempat Anda bekerja benar-benar buruk, cari pekerjaan baru. Kalau tidak, jangan terlalu terjebak dalam kesempurnaan karena pekerjaan pemrograman nyata memiliki kendala nyata (seperti waktu / dana). Ingat bahwa "Dalam teori, teori dan praktik adalah sama. Dalam praktiknya tidak sama."
Evan Plaice

>>> Kami membutuhkan cara baru. Saya tidak tahu apa itu. - Begitu juga orang lain, jadi terus berlanjut!
Gary Willoughby

5

Saya tidak mendapatkan gelar, tetapi saya mengambil sedikit di perpustakaan dan laboratorium perguruan tinggi dan universitas.

  • Big Iron - Teknologi yang mereka ajarkan terutama mainframe dan minicomputer. Dekan satu perguruan tinggi memberi tahu saya bahwa saya tidak akan bisa mendapatkan pekerjaan karena saya bahkan tidak tahu apa itu masterfile. Saya tidak punya niat untuk mengerjakan mainframe karena saya tidak mampu membelinya, tapi saya tidak akan sebodoh itu untuk tidak sedikit dipersiapkan. VAXen keren, dan saya berharap mendapat bayaran untuk kode Micro VAX saya sendiri di bilik saya. Sayang sekali pasar itu benar-benar meledak. (Ternyata saya memiliki dua posisi bekerja dengan mainframe ... sebagai kontraktor untuk IBM.)

  • Rekayasa Perangkat Lunak - Setelah Pemrograman Terstruktur, SASD, dan metodologi desain lainnya, Anda mungkin berpikir kami akan menjadi insinyur nyata. Aku melakukannya. Tetapi para guru hanya memberikan sedikit panduan tentang teknik desain yang saya baca di perpustakaan. Siswa dibiarkan berjuang sendiri dan micros membuatnya terlalu mudah untuk men-flail kode sampai mereka mendapatkan jawaban yang mereka sukai. Saya tidak menyadari betapa buruknya itu di pasar kerja. Entah bagaimana saya harus melakukan sedikit kode baru, jadi itu tidak terlalu membosankan. Tetapi saya juga mengambil banyak, dan mereka cukup buruk itu seperti proyek baru karena saya harus memperbaiki banyak kode. Itu adalah kombinasi meneliti fungsi yang ada dan membuat kode baru (penggantinya); alat tulis untuk menyederhanakan proses dan melembagakan manajemen proyek yang lebih baik.

  • Karir teknologi tinggi - Ini adalah satu hal ketika sekolah memiliki bangunan dan peralatan lama (peralatan punch card diganti semester sebelum saya mulai ... pada tahun 1984), tetapi ketika Anda bekerja di gudang yang kurang terang atau untuk bos yang menutup telepon pada pelanggan yang menghubungi saluran dukungan, Anda mulai menyadari bahwa deskripsi pekerjaan Anda tidak mungkin mencakup memasak popcorn dengan laser 5-megawatt.


5
  • Pengembangan terutama kerja tim. Itu berarti bahwa komunikasi (lisan dan membaca), membaca kode orang lain dan menggunakan kembali modul sebelumnya (baik internal dan eksternal) adalah sesuatu yang harus dihadapi hampir setiap hari. Di kampus saya, paling tidak saya harus membuat kode dengan lebih banyak orang dalam beberapa kesempatan, jadi saya pikir bagian utama dari pekerjaan itu adalah untuk membuat kode sendiri, di hutan belantara. Bukan itu.
  • Menjelaskan hal-hal kepada non-pengembang itu sulit (juga dibahas untuk poin pertama), dan merupakan tanggung jawab Anda untuk menyampaikan poin Anda (bukan dari 99% lainnya di dunia).
  • Tes yang baik adalah tes yang gagal. (pertama kali, setidaknya) Dan, tentu saja, tidak ada kode bebas bug. Anda bukan programmer yang buruk jika Anda memiliki bug. Bug hanyalah bagian (sangat penting dan menghabiskan waktu) dari pekerjaan Anda.
  • Tidak ada peluru perak. Setiap teknologi memiliki kelebihan dan kekurangan.
  • Perguruan tinggi tidak mengajarkan Anda teknologi tercanggih. Tetapi juga, 90% karya menggunakan teknologi yang cukup tua. Ngomong-ngomong, kadang-kadang itulah yang dibutuhkan.
  • Orang-orang non-teknis membuat keputusan tentang solusi teknis , sebagian besar untuk alasan esoteris seperti pemeliharaan, kemitraan, ketersediaan pekerja ...
  • Anda baru mulai , padawan muda .

Saya mulai menyadari sejak saat itu tentang fakta bahwa pengkodean adalah pekerjaan yang Anda lakukan bersama dengan lebih banyak orang, khususnya sekarang bahwa open-source lebih menonjol. Tetapi ketika saya masih kuliah (akhir tahun sembilan puluhan), saya yakin bahwa saya akan melakukan sesuatu dari awal dan tidak pernah melihat ke kode orang lain atau harus berkoordinasi dengan orang lain ...

Melihat ke belakang, bagi saya salah satu bagian terbaik adalah belajar dan mengajar orang lain .


"Perguruan tinggi tidak mengajarkan Anda teknologi tercanggih.": Ya dan tidak. Dalam beberapa bidang, akademisi 20-30 tahun ke depan membangun industri ini, dan Anda dapat belajar beberapa di perguruan tinggi.
Giorgio

3
  • Pemrograman komputer adalah non-fisik dan non-intuitif.
    • Ketika seorang pembangun rumah menyelesaikan pekerjaannya, ia dapat berjalan-jalan dan segera melihat / merasakan jika ada sesuatu yang salah. Bug pemrograman komputer tidak dapat ditemukan dengan cara yang sama, dan dapat mengintai di sistem selama berbulan-bulan, atau bahkan puluhan tahun.
    • Sementara seorang programmer dapat melihat / merasakan sepotong kode sumber melalui tinjauan kode, itu tidak dijamin untuk menemukan setiap kesalahan yang terkandung dalam kode. Komputer, bagaimanapun, akan mampu mereproduksi kesalahan dengan tepat setiap kali dengan menjalankan program dengan input tertentu. Dengan demikian, pemahaman manusia tentang sepotong kode sumber selalu merupakan model esensi yang tidak sempurna yang menjadi petunjuk bagi komputer.
  • Sangat mudah untuk membuat kode program yang menangani kasus yang paling umum, tetapi sepenuhnya gagal menangani kasus tepi.
    • Dalam disiplin lain, relatif mudah untuk menerapkan tindakan perbaikan setelah fakta. Bahkan mungkin ada badan pengetahuan khusus yang dikhususkan untuk tindakan perbaikan. Tidak ada hal seperti itu dalam Pengembangan Perangkat Lunak.
    • Untungnya, pengembangan yang digerakkan oleh tes membantu mengkodifikasi kasus tepi yang seharusnya ditangani oleh kode.
    • Ditambahkan Di sisi lain, metodologi pengembangan perangkat lunak tertentu tampaknya menunjukkan bahwa kita dapat mengekstraksi nilai bisnis (waktu lebih cepat ke pasar, dll.) Dengan secara sadar memilih untuk tidak menangani kasus tepi, dan untuk mengomunikasikan keputusan tersebut kepada pelanggan.
  • Pelanggan dapat menemukan nilai bisnis dalam perangkat lunak yang hanya menangani kasus yang paling umum, oleh karena itu penyedia perangkat lunak tidak terlalu khawatir tentang penanganan kasus yang jarang terjadi.
    • Pelanggan hanya belajar untuk menghindari sisi yang kasar.

Ditambahkan

  • Keanggunan kode sumber tidak dihargai.
    • Pelanggan tidak melihat keanggunan kode sumber. Mereka hanya melihat keanggunan antarmuka pengguna dan interaksi.
    • Programmer, di sisi lain, biasanya tidak menghargai keanggunan antarmuka pengguna, dan mereka biasanya tidak tinggal dalam satu proyek untuk waktu yang cukup lama untuk mulai menghargai desain perangkat lunak yang elegan.
    • Karena baik pelanggan maupun pemrogram tidak menghargai keanggunan kode sumber, tidak akan dinilai oleh bisnis.

Ditambahkan

Dua sen saya: biasakan saja.


8
pembangunan rumah dibandingkan dengan memperbaiki bug, hmm? "Hei, aku baru saja memutar doornob ke arah yang salah, dan rumah itu lenyap begitu saja!"
xor_eq

3

Gambar proses ISO, rim dokumentasi teknis, setiap fitur dan bug yang didokumentasikan secara ketat, dan lingkungan yang umumnya profesional menggambarkan perusahaan saya dengan cukup baik. Kami melakukan produk infrastruktur software / hardware penting, jadi, baik, tekanan pada kualitas (kita ISO 9001, misalnya).


1
@ Guzica: Salah satu perusahaan tempat saya bekerja cukup berorientasi pada teknik. Tidak bersertifikat ISO9001, tetapi mengikuti proses in-house yang cukup ketat secara formal. Yang lain, yah, seperti yang dikatakan - tidak lebih terorganisir daripada sekelompok siswa CS yang melakukan tugas akhir tahun bersama.
Bobby Tables

2

Saya pikir setelah lulus bahwa orang-orang yang bertanggung jawab akan dapat mengenali pekerjaan yang baik dari pekerjaan yang buruk. Setelah menyerahkan salinan sejuta "kode hebat yang disatukan oleh pembuat kode teratas kami" dan membuatnya terlihat seperti ini:

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

Aku hampir menyerah berusaha memahami apa yang terjadi di antara telinga bos berambut runcing. "Hebat" berarti mimpi buruk pemeliharaan, "baik" berarti crash dalam angin sepoi-sepoi, dan "kekacauan mengerikan" berarti entah itu atau basis kode yang terstruktur dengan baik yang para insinyurnya menolak untuk memenuhi tenggat waktu yang tidak senonoh hanya untuk menjaga kewarasan mereka.


1

Saya telah mendengarnya berpendapat bahwa semua rekayasa perangkat lunak setelah baris pertama kode adalah pemeliharaan. Dan itu sepertinya cocok dengan pengalaman saya. Satu-satunya kode yang saya tulis yang tidak memiliki sebagian besar biaya pemeliharaan adalah kode yang tidak berhasil sehingga tidak pernah atau hanya digunakan secara singkat.

Saya pikir Anda dapat menemukan tim teknik yang disiplin yang mengembangkan dan mengikuti proses yang kuat yang mengarah pada pelepasan kode yang kuat dimana tim dapat memiliki tingkat kepercayaan yang tinggi (walaupun saya tidak akan berbelit-belit dengan dokumentasi dalam jumlah besar). Saya percaya bahwa saya bekerja di tim seperti itu saat ini. Meskipun saya sudah pasti mengalami jenis perkembangan lainnya.

Namun hal yang saya hargai adalah, tantangannya tidak selalu menemukan algoritma yang sempurna atau solusi terbersih untuk masalah tersebut. Tetapi seringkali menukar semua jenis kendala (sumber daya, pengetahuan, uang, waktu, keterampilan, risiko, pelatihan pengguna yang sudah ada, dll., Dll) untuk mencapai pengembalian tertinggi untuk investasi yang tersedia. Yaitu membangun sistem yang paling cocok untuk semua faktor itu dan bukan hanya pengaruh teknis.


Poin yang sangat bagus. Dua dari perusahaan menengah / besar tempat saya bekerja telah menunjukkan perbedaan yang mencolok antara kedua kasus ini. Yang satu sangat berorientasi pada teknik, dan yang lainnya bekerja lebih seperti sekelompok tim mahasiswa CompSci yang mengerjakan proyek tahun terakhir yang terpisah dalam gelembung mereka sendiri - lalu entah bagaimana harus mengintegrasikannya nanti. (Catatan: Manajemen sebenarnya mendukung "gelembung-gelembung" ini - nama sebenarnya - berpikir bahwa itu lebih efisien bagi tim untuk bekerja secara terpisah daripada khawatir tentang integrasi selama pengembangan. Saya tidak bercanda.)
Bobby Tables

1

Banyak perangkat lunak yang tidak membuatnya cukup sampai digunakan / dibeli cukup. Ketika seseorang berhasil, ia cenderung bertahan dan hanya "kacau" dalam pemeliharaan.

Harapan pengguna meningkat setiap hari untuk fitur, tetapi di banyak bidang, mereka lebih rendah di bidang teknik. Mari kita asumsikan perangkat lunak transaksi perbankan sekokoh dan direkayasa secara profesional seperti mobil modern. Penanganan volume adalah keajaiban modern, tetapi apa tentang keandalan setiap transaksi? Tidak terlalu banyak. Posting Anda tentang omong kosong pertama anak anjing Anda di karpet dijatuhkan, jadi apa. Ini lebih seperti kantong plastik kecil di toko kelontong. Mereka menghasilkan miliaran dari mereka, mereka merobek-robek dan dibuang. Kebanyakan orang tidak cukup peduli untuk meminta tas yang lebih baik.

Saya pikir perangkat lunak berkualitas akhirnya dibuat. Beberapa di antaranya mencapai pasar lebih cepat daripada kebanyakan produk komersial. Siapa yang bisa mengendarai mobil dalam Beta?

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.