Pengembangan perangkat lunak dari sisi realita disiplin ilmu TI

X : “mas, aku pgn buat kyk gini, tp kalo aku pake software A, katanya mesti convert ke XML atau pake software B”
saya : “ya, kalo sy memang lebih ringan pake XML, pak, ntar ditaruh di project app.nya”
X : “kalo sy pake software A ini, mas, gimana? saya tuh pengennya kayak aplikasi yg di d*** atau di *****, tau kan mas?”
saya : “yup, pernah pake, pak, install juga kok, malah sy nemu yg lebih bagus lg, smooth di iOS dan Android, tp ya itu tetap saja enakan pake XML atau pake file tambahan dr Adobe AIR (SWF), pak”

Well, sebagai developer, jangan terpaku pada satu tools/software/teknologi saja, ingat, teknologi bisa kadaluarsa, bakal ada terus teknologi2 baru, dan sepantasnya memang kita masih harus terus belajar, biar bisa bersaing.

Ada pernah kejadian : “mas, knapa web servicenya pake rest, pdhal ada SOAP di sini” | “krn rest sdh terbukti lebih ringan, pak” | “lah, kata siapa? teman saya pake SOAP dgn php lancar-lancar aja”
beda case, pak, kalo itu kan infrastukturnya kyk gitu, sedangkan punya kita sekarang terlalu boros kalo pake SOAP. Banyak javascript di sini, kalo pake SOAP, ntar definisiin lg strukturnya di XML dll.. sementara timeline yang ada 3 bulan, pak.”

Nah, satu pelajaran lg, gk bisa kita generalisir satu masalah itu sama dgn masalah lain. Kasus lain, kamu bisa kerjain satu aplikasi dlm 1 malam, liat dulu skala aplikasinya.. krn sejatinya, permasalahan di dalam TI itu beda-beda, tidak bisa semua app itu bisa dalam 1 malam. Maka dari itu, banyaklah bergaul dgn sesama profesional TI, rajin berdiskusi (tidak sekedar bertanya, kadang orang lain jengkel kalo ditanya-tanya terus), dan kembangkan (sambil latihan terus).

Seseorang ingin dibuatkan aplikasi dgn metode re-use, kalau developer sebelumnya rapih dalam mengerjakan dan terstandar, enak, developer lain yg melanjutkan tidak akan keteteran, apalagi kalo dokumentasinya jelas dan lengkap. Tapi kalo yg sebelumnya develop gk selesai, ditinggal programmernya, terus developer yg baru disuruh gantiin dan lanjutin, apalagi tidak ada dokumentasi, dan mesti baca-baca codingan developer sebelumnya yg berantakan, apa gk stress tuh developernya? 

Kalo yang pernah saya hadapi di bank-bank (dulu kebetulan jd developer asp.net di Plasmedia kliennya bank kabeh | loh knapa skrg jd dev. Android? gk laku y? | klo sy skrg msh jd dev. asp.net, mungkin sy msh jomblo, mas soalnya hidupnya kost-kantor-mall-kost-kantor-mall, pas ramadhan aja, terawih gk pernah sempat, buka puasa sering di jalan/di kantor, makanya pas ada kesempatan S2, sy beraniin diri resign dan nyambi2 di jogja, eh alhamdulillah, salah satu klien sy, dr Pusat Kajian Hadis Jakarta menarik sy, skrg bs kenal ust. Lutfi, ust. YM, ust. Arifin Ilham, dll, sambil belajar agama dr beliau2 tsb), mereka (tiap bank) sudah punya core sistemnya, mereka tidak akan mengganti core sistem dan itu tetap berjalan (bahkan ada upgrade core sistem berkala), ketika ada penambahan aplikasi/software, ya biasanya tinggal re-use dengan beberapa penambahan modul dan desain sesuai pakem (guide book) yang sudah diberikan mereka. Dan itu bisa cepat selesai, bahkan untuk aplikasi besar, bisa 1-2 bulan kelar (bukan satu malam/2 minggu, krn birokrasi, kesiapan database, server, sampai konfigurasinya, dsb juga butuh waktu). Tapi gak tau juga ya kalo di tempat lain, pernah sm temen-temen grup PPP di DepKeu, denger-denger sampe ada debat internal antar pejabat dirjen. Itupun ngurusin database sampe cronnya juga njelimet di birokrasi. Syukur PMnya mental baja bisa ngadepin mereka. Dan 3 orang developernya : mas Mulia, Radita dan Nur Hidayat juga handal dalam development app.

“halah banyak ngomong, yg penting ngerjain!” |  “nah iya, yg penting kerjain, anda sudah pernah ngerjain yg kyk gitu belum? mengerjakan sesuatu itu harus rapih, tdk bisa asal jadi, tepat sasaran untuk stakeholdernya, tepat guna dalam fungsi, teknologi dan biaya. Karena sejatinya, software itu mesti memiliki prinsip : useful, usable dan beautiful. Dengan proses bisnis yang tertata dan metodologi yang tepat sehingga siklus pengembangannya berjalan sesuai rencana”

Satu lagi..software personal jelas beda dgn software pemerintahan. software setipe front-end jelas beda dengan setipe backend.
Satu teknologi di satu tempat itu cepat, belum tentu di tempat lain jg cepat. Ada beberapa karakteristik dan parameter yg mendukung/menghalangi hal tsb. untuk bisa dikatakan itu cepat/lambat.

Ada kalanya kita sbg. developer sudah berbuat sesuatu utk klien, tp kurang puas dgn hasil kerja keras sendiri krn terkendala waktu yang diberikan sedikit, ada kalanya kita nemu kelompok developer yang diberikan waktu banyak, tp ngerjainnya asal-asalan, yang penting duitnya turun..alhasil tidak dipakai dan merepotkan user. Dan banyak kejadian-kejadian dengan plot twist yang dihadapi developer. “Kalo ketemu klien yg awam TI, minta cepet, ya garap aja, kalo ntar klien ngerasa tidak puas atau kurang pas, tinggal buka penawaran baru” 

Yang jelas, teruslah berusaha sebaik mungkin, jangan pesimis, kalo ada orang berusaha menjatuhkan, coba gerak terus saja. Dan satu hal, tidak ada salahnya mendengar dan belajar dari yang sudah berpengalaman/ahli biar makin meningkat ilmu yang kita pelajari, dan tentunya jadi bermanfaat lebih luas hasil yang kita kerjakan.

Fighting Spirit mahasiswa sekarang lemah!

Pelajaran yg saya dapatkan hari ini dari pak Lukito dari ngobrol di plurk.

mungkin banyak orang bisa berbagi ilmu, tp belum mampu mengajarkan mereka untuk mandiri, menyadari hak dan kewajibannya. Hanya fokus pada hal membagi, tidak mengajarkan..
Alhasil, kebanyakan mahasiswa itu fighting spiritnya lemah, kurang menghargai orang lain, menunggu dijemput, bukan datang mencari, dan terlalu fokus pada hal yang ada.

Karena ini lagi musim ributin capres, saya coba berikan analoginya, seperti calon pemerintah yang punya visi : “menaikan tunjangan 3x lipat”, tp tanpa menjabarkan misinya hal-hal yang bisa membuat rakyatnya mandiri, mengajarkan mereka buat lebih berkualitas. Jatuhnya, ketika pemerintah memberikan apa yang rakyatnya inginkan, selanjutnya rakyat nanti akan banyak menuntut pemerintah (manja).

Dan ini ada beberapa contoh yang dihadapi :

“maaf, mas kuota internet sy gk cukup, boleh copy gk mas, kita ketemuan, mas”

“maaf/maklum masih newbie, mas, ajarin dong dr dasar”

“saya googling ga nemu, mas”

“mas ada tutorial bahasa indonesia gk? sy gk bisa baca yg bhs inggris”

“mas, sy pake cara ini, tp gagal, bisa dicekin gk mas, errornya?”

“mas, sy bikin aplikasi kyk gini, itu rasanya kok jd panjang bgt, ada cara singkat gk mas?”

kadang saya gk suka dengan orang yg apa adanya… ujung2nya ada apanya… gk mw usaha lebih keras..
malah bbrp message FB saya diamkan saja pas lagi sibuk ataupun karena terlalu sering mendapatkan seperti itu. Kurang sabarnya saya.

Jaman sekarang, internet murah, hdd murah, jaman sy kuliah, flashdisk max. 128 MB, itupun mahal, duit jg ngepas dikirimnya, internetpun mesti di warnet, krn blm ada model modem dan provider internet murah. Apalagi zaman dosen-dosen kita? 
Yang sewajarnya, mencari informasi itu lebih mudah di zaman sekarang.

Bila tidak bisa bahasa inggris, ya belajar, masih sempat belajar, daripada waktu banyak habis buat ngegame dan berjejaring.

Lalu bagaimana etikanya?
Ini masalah yg saya hadapi dengan panitia sebuah workshop, saya berkeluh kesah di plurk, dan pak Lukito memberikan tanggapan :
“Bilang saja klo anda tdk suka diperlakukan dmk. Tunjukkan bhw apa yg mrk lakukan itu tdk menghargai pembicara..Ttg jadwal, ttg HR, ttg pemberitahuan yg mepet. bbrp panitia mhs sptnya perlu diberitahu ttg adab terkait pembicara, jd ajarilah mrk. Kalau saya, saya ga akan mau disuruh menemui panitia atau mengunduhkan file2 yg diperlukan utk demo..Bukan apa2, tp justru utk ngajarin mrk ttg hak dan kewajiban masing2. Sptnya mhs panitianya blm pengalaman mengadakan acara2 gini ya”

dan ini membawa hikmah ke yang lain, bahwa pentingnya membagi pengetahuan ke yang lain tapi juga mengajarkan, ya mengajarkan mereka tentang hak dan kewajiban.

Jadi, ketika orang bertanya, coba jawab, tp jangan abaikan untuk beritahukan ia bahwa alur belajarnya yg benar ttg ilmu tsb seperti ini.

Dengan memberikan mereka : arah yg benar, cara yang baik dalam belajar, dan juga mengajarkan mereka buat semangat belajar (dengan memotivasi dengan arah yang kita beri tersebut), insya’ Allah, mereka bisa mandiri mencari informasi sendiri.
Karena, mereka tentu tersesat dalam belajar, bingung harus belajar apa dulu. Saya juga dulu mengalami demikian.

Terus ajarkan mereka, “mas, kalo bertanya, sebaiknya spesifik, ke kasus yg dihadapi, jangan minta ajari dari awal, kasian saya nantinya mas, membagi banyak waktu buat mas, padahal saya ada hak dan kewajiban.. Jadi coba aja dulu, pelan-pelan, pelajari dari berbagai sumber..ini saya kasih link-link yang bagus, terus coba bikin aplikasi sederhana, seperti mengganti background, rumus menghitung luas misalnya, atau deteksi lokasi sederhana, baru kalo kesulitan, bertanyalah ke pokok masalah. Jangan dateng-dateng langsung nanya, dan minta ajarin bikin aplikasi yang lebih besar.”

Tp jangan takut juga bertanya, bila mengasyikan, malah terkadang orang yang kita tanyai itu ikut2an belajar dari situ. Apalagi mereka bisa mengakrabkan diri dengan baik. Datang bawa masalah, tentu harus diceritakan kronologinya, sedang buat aplikasi apa, errornya muncul apa, terus input-outputnya apa… jangan datang-datang, copas sourcecode, dan minta carikan errornya 

Semoga ini bisa memberikan pelajaran bersama, khususnya bagi diri saya pribadi. 🙂

Mohon maaf bila menyinggung, semoga tidak dinilai negatif  😀

6 pelajaran hidup yang dapat kita pelajari dari seni pemrograman

  1. Flow Chart sederhana adalah segalanya
    Sama halnya seperti seorang programmer, ketika kita dihadapi masalah besar, sebisa mungkin dipecahkan menjadi bagian-bagian terkecil, Baru dengan mudah kita dapat mengambil keputusan atas masalah tersebut.
  2. Setiap hal ada tempatnya.
    Selalu, ktika kita men-develop aplikasi, tentu di tahap awal kita menempatkan variable2 yang ingin kita pakai beserta tipe datanya (inisialisasi), begitu jg hal lain, slalu ada tempatnya, semua ada aturannya.
    Sama seperti kehidupan nyata, di mana letak tempat menaruh peralatan kerja, menaruh makanan, menaruh permasalahan kantor ya di kantor, bukan di rumah, dan sebagainya.
  3. Re-use/menggunakan kembali module yang sudah ada untuk menghemat waktu
    Setiap programmer yg baik akhirnya belajar bahwa ketika sudah membuat sebuah function ataupun module, dapat digunakan kembali untuk pengembangan aplikasi yang lain/berikutnya. Jadi menghemat waktu tentunya
    Henry Ford pernah berkata tentang Model T, “Setiap pelanggan dapat memiliki mobil dicat warna apa saja yang dia inginkan, asalkan itu hitam.”
    Alasan ini yang dipake Ford untuk merakit mobil dan membuat produk-produknya keluar pintu lebih cepat jika ia bisa menggunakan kembali peralatan yang sama (cat warna yg sama) tanpa harus menciptakan proses setiap kali mobil baru dibuat.
  4. Dokumen(tasi) adalah segalanya
    Kalo programmer yang “khilaf” 😐 dokumentasi itu malah diabaikan, atau malah dikerjakan pas aplikasi selesai 😐 sama aja boong :)) keasikan ngoding sih jadinya males, malah terkadang dianggap repot 😐 “gak ah, mending ngoding aja, ntar jg gampang diinget-inget, gak taunya mesti tracing code lagi”
    Sebenernya dokumentasi itu penting, dengan adanya dokumentasi, kita mencatat setiap hal yg kita perbuat dengan aplikasi itu, apa kesalahan dan perbaikannya, apa fungsi-fungsinya, dan tau tata letaknya, jadi mempermudah developer lain (berikutnya) untuk mengembangkan, dan bahkan bagi user.
    Sama seperti sehari-hari, terkadang jadwal penting, rutinitas sehari-hari, dan apa saja yang mesti dilakukan perlu dicatat di dalam sebuah catatan/agenda, memudahkan anda mengingat dan tidak tertinggal satu halpun.
  5. Jangan terjebak di satu situasi yang buruk.
    Ketika aplikasi mengalami looping gk berujung, process CPU jadi tinggi, dan tentunya si programmer harus mencari alternatif cara agar aplikasi berjalan lancar. Begitu jg dengan kehidupan nyata, ketika sudah merencanakan sesuatu, tau2 datang hal yg tidak diprediksi, satu2nya cara adalah menyiapkan “skenario terburuk” dari rencana itu, jadi tidak stuck di situ saja.
  6. Free Up Memory ketika kamu selesai.
    Kalo buat aplikasi, misal aplikasi Android, terapin masalah service, yang jelas setiap execute dalam durasi beberapa waktu, butuh free-up memory, agar app.tersebut tetap efisien ketika berjalan. Jika tidak, bakal makan banyak memory.
    Di kehidupan sehari-hari, sama juga, abis kerja, abis makan, cepetan diberesin dan dibersiin ruangannya, jangan sampe numpuk sampah, peralatan kerja berserakan, dsb. Malah buat aktifitas berikutnya jadi lambat.