Antara idealisme dan realita

Dikutip dari milis netindonesia.net

Hendry Wijaya wrote:
.... saya ingin mengajak teman2 sekalian berdiskusi mengenai 1
> hal : sepanjang saya kuliah dan skrg bekerja, umumnya ada 2 cara
> pandang programmer dalam memandang pekerjaannya, yg pertama adalah yg
> memandang yg penting dalam pekerjaan sebagai programmer adalah
> tugasnya selesai, gaji didapat ( kalau yg freelance uang proyek
> dibayar ), dan akibatnya adalah dalam mengerjakan program, tipe yg ini
> gak peduli dengan yg namanya UML, OOP - atau dgn kata lain idealisme
> belakangan saja, yg penting program jadi. Toh, client-nya juga gak
> ngerti OOP. Yang kedua, adalah yg dalam mengerjakan proyek benar2
> strict, harus OOP misalnya. Pas saya kuliah, saya pikir kerja di
> software house itu, tipenya yang ke-2, dimana kerjaan kita harus
> serapi mungkin, agar coding kita mudah di-maintain. Tapi dlm
> kenyataan, di t4 kerja saya maupun dr sharing temen2 lainnya, banyak
> sekali software house yg tipe pertama. Saya baru bekerja 1 bulan
> setengah, dan jujur saja saya cukup kaget dengan realita ini. Nach,
> akibat lingkungan kerja seperti ini jugalah, yang membawa saya kepada
> pola pikir pragmatisme ( pola pertama ). Apalagi deadline project yg
> cukup singkat, yg membuat kita berpikir yg penting program itu jadi.
> Bagaimana pendapat teman2 sekalian di sini akan hal ini?

Slamet Santoso replied:

Begitulah beda alam pikir sekolahan dengan realita bisnis. Di sekolah, teori dan konsep diasumsikan berjalan di atas environment yang ideal. Pertimbangan yang dipakai juga homogen, tidak banyak, hanya dari sudut pandang software engineering semata. Kompleksitas dan besarnya persoalan juga diabaikan. Nggak perlu juga difikirkan soal budget yang tersedia dan berapa waktu yang tersisa.

Realita bisnis berbeda. Ada limitasi waktu, budget, jumlah orang, ekspektasi calon pemakai, dll. Pekerjaan coding adalah konsekuensi dari keputusan bisnis, yang seringnya merupakan hasil "trade-off" dari parameter engineering dan economics. Ada plesetan "murah minta bagus ??", "bagus minta cepat???", "cepat minta handal???", "handal minta user friendly???", dll.

Ada pertanyaan-pertanyaan yang belum terjawab di soal seperti ini. Contohnya: Apakah cocok kita gunakan rationale unified process dan UML nya secara menyeluruh untuk segala jenis proyek software development, berapapun budget yg tersedia? Apakah cocok kita gunakan OOP, kalau analisis dan desainnya masih terstruktur? Atau apakah cocok OOP untuk software yang tanpa analisis dan desain? Atau perlukah kita memakai OOP untuk semua kegiatan coding? Perlukah analisis dan desain, jika tim pengembang beranggota 1 orang?
Prinsip dari cara menjawab pertanyaan-pertanyaan di atas itulah yang nantinya akan membedakan tim/ perusahaan mana yang bersikap pragmatis, mana yg taktis, dan mana yg tidak realistis. Sangat beruntung jika Anda berada dalam tim yang berfikir taktis.

Semua prinsip dalam software engineering biasanya dilandasi oleh tujuan jangka panjang, skala dan lingkup pekerjaan yang mungkin membesar, pekerjaan dilakukan oleh tim bukan 1 orang, dll. Ada investasi di awal yang buahnya akan dinikmati di akhir.

Saran saya, jika Anda ingin menjadi besar, berfikir dan bertindaklah dengan selalu mempertimbangkan adanya kemungkinan perubahan di masa depan. Jadi, maintainability itu penting, meskipun butuh investasi. Jangan pula bermewah-mewahan dengan segudang konsep dan teori. Fikirkan background situasi di balik lahirnya teori dan biaya yang keluar untuk implementasi teori tersebut.