5 mitos di industri software development Indonesia

Sejarah mencatat kalau penggunaan komputer di Indonesia dimulai di sekitar tahun 1970-an dan cabang ilmu komputer atau teknik informatika mulai berkembang di Indonesia sekitar akhir tahun 1970-an. Bila memang benar cabang ilmu komputer masuk di Indonesia di tahun tersebut, berarti hampir 40 tahun industri software development di Indonesia tidak mengalami banyak kemajuan yang berarti. Kenapa demikian? Karena selama satu dekade belakangan, tingkat turnover di industri software development di Indonesia masih tergolong tinggi dibandingkan di industri lainnya, delivery date yang tidak sesuai perencanaan dan fitur-fitur yang tidak sesuai permintaan kostumer.

Namun walaupun dengan semua permasalahan pelik tersebut, masih banyak saja praktisi IT di Indonesia yang melakukan hal yang sama seolah-olah kegagalan dalam 40 tahun belakangan belum menjadi cukup bukti kuat untuk mereka merubah cara berpikir dan cara berperilaku dalam software development. Seharusnya orang yang telah gagal berkali-kali langsung belajar dari kegagalan dan tidak melakukan hal yang telah menyebabkan ia gagal untuk kedua kalinya, namun hal tersebut seolah-olah tidak berlaku di Indonesia karena banyak orang Indonesia yang menggunakan kaca mata kuda yang tidak memperhatikan perkembangan dan perubahan di belahan dunia lain.

A problem can’t be solved from the same state of mind that created it. — Einstein

Pada hari ini, pada saat anda sedang membaca artikel ini, di Indonesia ada proyek software development yang sebentar lagi akan gagal dan pada saat yang bersamaan ada beberapa software developer yang baru saja bekerja di perusahaan selama kurang dari satu bulan berniat untuk mengundurkan diri dari perusahaan dimana ia bekerja. Banyak manajer dan petinggi perusahaan yang masih memiliki pola pikir dari teori manajemen dari tahun 1900-an dalam mengelola proyek software development di abad 21. Oleh karena itu banyak dari manajer IT ini yang perlu diganti karena mereka belum menyesuaikan diri dengan perkembangan jaman. Apakah ini hanya merupakan kesalahan mereka saja? Tidak juga, perilaku mereka yang tradisional ini juga banyak dipengaruhi oleh atasan mereka yang berlagak tidak mau tahu dan sebuah departemen yang sering disebut Human Resource Department (HRD) yang masih menggunakan teori-teori jaman kuda yang sudah banyak disangkal oleh ilmuwan dan psikolog. Saya menyebut orang-orang yang duduk di Manajemen dan HRD sebagai partners in crime to demotivate people in the workplace. Saya menyebut teori jaman kuda yang mereka anut tersebut sebagai mitos.

mitos (n). sebuah pemikiran mengenai pengelolaan software development berdasarkan teori dari jaman kuda yang tidak manusiawi dan sudah tidak relevan lagi di abad 21.

1. Software Developer = Resource

Di setiap training yang saya jalankan, selalu ada saja yang mengkorelasikan software developer sebagai resource.

“Pak, bagaimana apabila resource kami terbatas? Apakah Scrum … ?”

Pertanyaan seperti itu selalu langsung saya potong karena resource yang dikorelasikan dengan software developer sangat mengganggu kuping saya. Menurut kamus bahasa inggris, arti dari kata resource adalah:

resource (n). a place or thing that provides something useful and can be used whenever it is needed.

Sayangnya software developer bukanlah a thing (benda) yang bisa dimanfaatkan sewaktu-waktu bila dibutuhkan. Software developer memiliki pemikiran dan perasaan.

Apa itu manajemen?

Banyak teori manajemen yang dianut di Indonesia didasari oleh teori Scientific Management, yang berkembang di sekitar tahun 1910-an. Teori ini berkembang dari lingkungan produksi di pabrik. Oleh karena itu teori ini lebih banyak menekankan pada efisiensi dan produktifitas karyawan pabrik. Teori ini sangat menekankan posisi manajer yang bertugas untuk mengatur karyawan pabrik (labor). Peran manajer dipandang sebagai peran yang sangat penting oleh karena itu manajer haruslah orang-orang yang pintar. Tapi sayangnya Scientific Management ini tidak relevan di industri software development di abad 21.

Manager’s responsibility is not to make people work, but to make it possible for people to do their work.

Sifat pekerjaan dalam lini development tentunya sangat berbeda dengan lini produksi di pabrik. Software developer bukanlah buruh yang menulis kode seperti buruh pabrik. Hal ini dikarenakan kode yang ditulis oleh software developer sifatnya tidak selalu sama dan algoritma yang ditulis oleh software developer memerlukan tingkat kecerdasan yang tinggi. Paradigma dimana software developer adalah resource didasari oleh pemikiran kalau software developer adalah spare part yang dapat digantikan. Pola pikir tersebut membuat banyak perusahaan di Indonesia menekan biaya software developer serendah mungkin karena software developer hanya dipandang sebagai spare part (resource).

People are NOT Resource

Dalam ilmu akuntansi, resource atau sumber daya seperti mesin fotokopi, komputer, alat tulis, kendaraan kantor maupun gedung dilihat sebagai expense dikarenakan seiring dengan waktu resource ini akan mengalami penyusutan atau depresiasi nilai. Buruh-buruh pabrik pun di dalam pembukuan akuntansi dianggap sebagai expense. Karena buruh dipandang sebagai expense, di banyak perusahaan di Indonesia, software developer pun dilihat sebagai expense. Software developer diperlakukan sebagai “sumber daya” yang harus digunakan semaksimal mungkin daripada diperlakukan seperti manusia yang potensinya perlu dikembangkan.

Cara berpikir bahwa software developer adalah resource dan expense ini memiliki kejanggalan karena software developer sebenarnya adalah sebuah capital investment untuk perusahaan. Software developer tidak akan mengalami penyusutan, namun sebaliknya seiring dengan waktu mereka akan menjadi semakin pintar karena mereka adalah knowledge worker yang menggunakan otaknya untuk bekerja bukan ototnya. Ilmu yang ada di dalam kepala software developer tidak akan usang, kecuali mereka tidak mau terus menerus belajar dan up-to-date dengan perkembangan jaman lagi. Dan bila mereka semakin pintar, maka software yang mereka kembangkan akan semakin berkualitas tinggi.

Software developer bukanlah resource yang perlu dimanage. When software developers are over-managed, they will under-manage themselves. Mereka adalah manusia. Mereka adalah knowledge worker. Mereka adalah capital investment dimana capital utama mereka adalah pengetahuan.

2. Software development = pekerjaan prediktif

Chaos theory adalah sebuah bidang ilmu yang mempelajari sebuah dinamika sistem yang sangat sensitif terhadap keadaan di awal yang menyebabkan keadaan di akhir tidak dapat diprediksi. Lorenz system adalah salah satu contoh dari chaotic system dan sebagai kontras gravitasi dapat dikatakan sebagai sebuah sistem yang memiliki tingkat kepastian yang tinggi.

Adik saya yang sekarang masih duduk di bangku SMA saat ini bekerja paruh waktu di sebuah rumah makan saji cepat yang makanan utamanya adalah burger. Salah satu kebiasaan dari rumah makan saji cepat ini adalah mencari tenaga kerja yang masih duduk di bangku SMA dikarenakan gaji harian seseorang yang masih duduk di bangku SMA jauh lebih murah dibandingkan seseorang yang sudah berkeluarga. Hal ini tidaklah aneh dan bisa diterima oleh akal sehat karena proses untuk membuat burger sifatnya repetitif dan tidak rumit, bahkan seseorang yang masih duduk di bangku SMA pun dapat diberi pelatihan singkat mengenai pembuatan burger kurang dari sehari. Kalau proses mengembangkan software sama dengan proses membuat burger, mungkin cara berpikir bahwa pengembangan software adalah pekerjaan prediktif dapat diterima.

Sayangnya pekerjaan mengembangkan software bukanlah pekerjaan prediktif seperti membuat burger karena software developer tidak pernah membuat software yang sama lebih dari satu kali. Mengembangkan software bukanlah sebuah proses produksi. Bila kita ambil contoh industri otomotif, kita dapat melihat disana ada sebuah divisi R&D (Research & Development) dan ada bagian factory yang bertugas memproduksi mobil yang didisain oleh divisi R&D. Keahlian orang-orang yang berada di divisi R&D berbeda dengan orang-orang yang berada di factory. Orang-orang yang berada di divisi R&D berisi para inovator yang kreatif berbeda dengan orang-orang yang ada di factory yang cukup mengikuti prosedur standard. Para inovator di divisi R&D tidak pernah mendisain mobil yang sama lebih dari satu kali namun orang-orang yang bekerja di lini produksi dapat membuat tipe mobil yang sama berkali-kali dalam sehari. Bila kita ingin menghubungkan sifat pekerjaan software development, maka lebih cocok untuk dihubungkan dengan divisi R&D daripada dengan lini produksi di pabrik. Software developer adalah inovator, bukan buruh pabrik.

Namun sangat disayangkan sekali banyak manajer proyek yang masih menganggap kalau tipe pekerjaan di software development adalah pekerjaan yang dapat diprediksi dari awal seperti pekerjaan membuat burger. Manajer proyek akan berusaha semaksimal mungkin untuk membuat work breakdown structure (WBS) yang mendekati sempurna supaya proyeknya tidak gagal. Dan ketika proyeknya gagal, di proyek berikutnya mereka akan berusaha untuk menghabiskan lebih banyak waktu untuk membuat WBS-nya semakin mendekati sempurna lagi dan kalau perlu kali ini tambahkan buffer. Cara berpikir seperti ini sangat tidak relevan di software development karena kebanyakan teori manajemen proyek yang dianut manajer proyek banyak dilandaskan oleh teori manajemen proyek konstruksi yang sifatnya memang cenderung prediktif. Proses konstruksi bangunan yang banyak menggunakan teori teknik sipil dan teori fisika membuatnya cenderung prediktif. Anda tentu masih ingat di SMA kalau pelajaran fisika sering disebut sebagai ilmu pasti. Kalau saja mengembangkan software didasari oleh rumus-rumus fisika, mungkin kita bisa menggunakan WBS dan kita tidak perlu memiliki software developer yang cerdas, cukup yang sekelas kuli bangunan saja. Andaikan saja manajer proyek ini memiliki kerendahan hati untuk mengakui kalau ilmu manajemen proyek mereka tidak relevan di software development, mungkin lebih banyak software developer saat ini yang bahagia dan tidak menyesali kenapa dirinya adalah seorang software developer.

Coercing people into commitments then blaming them for not meeting those commitments is an abuse.

Mitos ini semakin diperparah oleh salesman yang memberikan janji palsu kepada klien hanya agar dia mendapatkan proyek dari kostumernya. Si salesman akan mendapatkan bonus dari perusahaan karena sudah menggolkan proyek, sedangkan software developer harus menderita karena deadline yang dijanjikan oleh salesman kepada kostumer sering kali tidak masuk akal. Bukankah ini adalah proses pemanipulasian yang sangat kejam? Banyak salesman di perusahaan software yang berpikir kalau membuat software sama seperti membuat mi instan goreng telur. Dan jangan salahkan bila software yang dikembangkan oleh software developer menjadi berkualitas rendah.

Software developers don’t work effectively when they’re pushed into a no-win situation.

Untuk tipe pekerjaan yang memiliki banyak ketidakpastian seperti software development, metode empiris lebih tepat untuk digunakan. Manajer proyek yang mengira kalau tipe pekerjaan software development sifatnya prediktif kemungkinan tidak pernah terlibat atau sudah lama tidak terlibat dalam software development atau memang timnya mengembangkan software sederhana dengan teknologi sederhana yang jumlah penggunanya hanya satu orang.

3. Sukses = On-Time, On-Budget dan On-Scope

Di awal tahun ini, dalam sebuah perjalanan pulang dari outing kantor dimana saya pada waktu itu menjadi trainer untuk tim di perusahaan tersebut, menuju Jakarta salah seorang dari peserta outing mendapatkan sebuah pesan singkat dari atasannya yang isinya kira-kira adalah:

“Jangan lupa ya John, target kita tahun ini adalah Always On”.

Pemikiran yang menekankan kalau sukses adalah On-Time, On-Budget dan On-Scope berasal dari teori manajemen proyek tradisional. Tiga kriteria sukses ini seringkali disebut dengan Project Management Iron Triangle. Kalau tipe proyek atau tipe pekerjaan yang dilakukan adalah prediktif seperti membuat burger maka pemikiran ini dapat diterima oleh akal sehat. Namun mengembangkan software tidak sama dengan membuat burger.

Solusinya adalah lembur

Di banyak perusahaan di Indonesia, overtime sering kali dijadikan solusi agar software yang telah dijanjikan oleh pihak manajemen ke kostumer bisa selesai tepat waktu. Seolah-olah kalau software yang sedang dikembangkan tersebut tidak selesai tepat waktu maka dunia akan kiamat. Namun dilihat dari sisi manapun juga, lembur sangatlah tidak efektif.

“Overtime” will always be followed by an equal period of “undertime” where people trying to catch up with their lives.

Setiap jam software developer lembur, setiap jam juga mereka akan kehilangan waktu dengan keluarga dan teman-temannya. Semakin sering mereka lembur, semakin mereka tidak memiliki kehidupan. Lembur adalah sebuah solusi jangka pendek namun dampak jangka panjangnya lebih menyakitkan. Atasan yang lebih peduli untuk memenuhi target Always-On daripada kehidupan anggota timnya adalah seorang atasan yang egois dan tidak manusiawi.

Running a company is not always about making profit, most importantly about making the life of others around us much better.

Kualitas tidak penting

Berdasarkan kamus perusahaan, definisi dari lembur adalah penambahan waktu untuk meningkatkan kuantitas pekerjaan bukan untuk meningkatkan kualitas software yang sedang dikembangkan. Bagi manajemen, men-deliver software lebih cepat walaupun dengan kualitas yang rendah itu lebih penting karena mereka beranggapan bahwa nantinya masih ada waktu di Post Implementation Review (PIR) atau User Acceptance Test (UAT) untuk memperbaiki software. Namun liciknya adalah manajemen akan tetap melaporkan kepada stakeholder dan kostumer kalau proyeknya sudah diselesaikan dengan sukses karena mereka sudah memenuhi kriteria on-time, on-scope dan on-budget, walaupun dengan kualitas rendah!

Menganggap bahwa software berkualitas rendah yang diselesaikan sesuai waktu, ruang lingkup pekerjaan dan dana yang ditetapkan sebagai sebuah kriteria kesuksesan bagaikan sebuah ilusi. Software development adalah sebuah seni, menulis kode yang bersih (clean code) memerlukan kehati-hatian ekstra dan waktu yang relatif lebih lama dibandingkan menulis kode serabutan (dirty code). Kode yang berkualitas rendah akan semakin memperlambat penambahan fitur baru dan semakin meningkatkan biaya untuk maintenance software di jangka panjang. Saya sudah sering melihat software developer yang mengundurkan diri dari sebuah perusahaan karena software yang ia kelola berkualitas rendah. Perusahaan di Indonesia yang bangkrut karena kualitas software yang mereka kembangkan rendah juga banyak.

4. Produktivitas = kuantitas waktu bekerja

Kualitas waktu tinggi = kualitas software tinggi

Dalam dunia software development, waktu untuk berpikir/melamun adalah sesuatu yang sangat penting karena software berkualitas dibuat oleh knowledge worker yang menggunakan otaknya bukan ototnya. Di mayoritas perusahaan di Indonesia, seorang software developer dikatakan produktif apabila ia duduk dan mengetik kode dalam jangka waktu yang lama. Bahkan ada perusahaan di Indonesia yang mengukur produktivitas software developer berdasarkan jumlah baris kode yang ditulis oleh software developer dalam sehari. Bila software developer sedang melamun atau sedang jalan-jalan di taman, maka mereka dianggap tidak bekerja dan merugikan perusahaan. Bagaimana apabila pada saat mereka melamun mereka sedang memikirkan sebuah algoritma yang dapat membuat kode menjadi lebih efisien dan bersih (clean code)? Bagaimana apabila lamunan tersebut menghasilkan pemikiran yang membuat user experience software menjadi semakin bagus? Software developer itu bagaikan seorang seniman lukis, ketika mereka sedang melamun mereka sebenarnya sedang produktif. Kalau anda bukan seorang software developer, anda tidak akan memahami ini.

Interupsi tiada henti

Wired-in adalah sebuah keadaan dimana software developer terhubung ke kode yang sedang mereka tulis sama seperti saat seseorang melakukan meditasi tanpa menyadari apa yang telah terjadi di sekitarnya dan berapa banyak waktu yang terlalu ketika ia sedang menulis kode tersebut. Kalau anda adalah seorang software developer, tentunya anda tahu apa yang sedang saya maksud.

For knowledge workers like software developer, being in the flow is important because only when they are in the flow their work goes well.

Namun sayangnya berdasarkan pengamatan, software developer sering kali mendapatkan interupsi yang terlalu banyak sehingga merusak flow mereka menulis kode. Karena mereka jarang sekali untuk bisa in the flow, akibatnya kualitas waktu yang mereka miliki selama mereka berada di kantor sangat rendah. Jumlah waktu yang habis dalam satu hari karena jumlah meeting dan teleconference yang harus mereka hadiri lebih banyak dari jumlah waktu yang mereka dedikasikan untuk menulis kode. Belum lagi ditambah interupsi tidak penting dari atasan dan dari pengguna. Akhirnya mereka baru bisa benar-benar berkonsentrasi penuh untuk menulis kode yang cantik setelah jam kantor selesai. Oh iya, belum lagi ditambah beberapa proyek yang harus dikerjakan secara paralel oleh software developer membuat waktu berkualitas mereka menurun.

The quality of software developer’s time is important, not just its quantity.

Interrupsi membuat kualitas waktu software developer menjadi rendah, dan dengan keadaan tersebut perusahaan masih mengharapkan semua pekerjaan (on-scope) untuk selesai tepat waktu (on-time)? Sungguh tidak masuk akal bukan?

Manajemen gaya feodal

Sejarah mencatat kalau pada sekitar abad 17-an Spanyol dan Inggris memiliki cara yang cukup berbeda untuk memperkaya dirinya. Menurut sudut pandang Spanyol, kekayaan di bumi itu berjumlah tetap, sehingga cara mereka untuk memperkaya dirinya adalah dengan mengambil sebanyak mungkin emas dari negara yang mereka jajah dan membawa semuanya kembali ke Spanyol. VOC dapat dikatakan juga memiliki cara berpikir yang sama dengan penjajah Spanyol. Sedangkan Inggris berpikir kalau teknologi dan inovasi adalah cara yang efektif untuk mereka dapat memperkaya dirinya. Oleh karena itu pada masa itu Inggris mengalami revolusi industri sedangkan Spanyol mengalami inflasi karena mereka memiliki terlalu banyak emas di negaranya namun tidak cukup banyak pembeli.

Gaya manajemen di kebanyakan perusahaan software di Indonesia menggunakan cara feodal ala penjajah Spanyol atau VOC. Perusahaan ingin menyedot waktu yang sebanyak-banyaknya dari software developer untuk menyelesaikan pekerjaan sebanyak-banyaknya agar perusahaan tidak merugi sama sekali, persis dengan gaya Spanyol menjajah. Kalau pekerjaan belum selesai tepat waktu, maka software developer harus lembur. Kalau software developer tidak kelihatan sibuk dan kelihatan sering melamun mereka akan diberikan proyek untuk dikerjakan secara paralel sebanyak mungkin. Lagi-lagi ini juga ditambah oleh pemikiran kalau software developer adalah sebuah resource yang perlu dioptimalkan bukan seorang manusia.

5. Coach — bukan peran yang dianggap penting

Often the answers to many questions are already within us. We just need the help from someone to bring them out. — Mae Jamison

Orang tidak menjadi lebih hebat karena di-manage, tetapi karena mereka di-coaching. Paradigma software developer harus di-manage berasal dari sudut pandang kalau software developer pada dasarnya adalah seorang pemberontak yang tidak bisa diatur, tidak dewasa dan tidak cukup kompeten untuk mengatur diri mereka sendiri, oleh karena itu perlu ada seseorang yang lebih pintar untuk mengatur mereka. Ini dinamakan paradigma perbudakan. Paradigma software developer harus di-coaching berasal dari sudut pandang kalau software developer itu baik adanya yang memiliki potensi untuk dapat mengelola dirinya sendiri tanpa diperintah di kemudian hari.

Competent adults don’t need to be managed.

Karena software developer dianggap tidak kompeten maka mereka perlu dimanage bagaikan bidak catur oleh orang lain yang dianggap lebih pintar, dalam hal ini manajer proyek dan kadang ditambah beberapa lapisan lagi seperti Technical Leader, System Analyst, Solution Architect dan Business Analyst. Cara berpikir seperti ini secara tidak langsung membuat software developer berada pada hirarki paling bawah struktur organisasi sama seperti kuli bangunan yang berada di hirarki paling bawah.

Performance appraisal tahunan manipulatif

Rather than have a yearly performance evaluation, how about making course correcting info available all year long?

Ritual tahunan yang dilakukan oleh perusahaan yang bernama performance appraisal diharapkan dapat memotivasi software developer di tahun berikutnya. Namun ini sebenarnya adalah tipu muslihat yang sebenarnya bertujuan untuk memanipulasi motivasi software developer karena sifat performance appraisal yang men-judge kinerja software developer selama satu tahun ke belakang. Men-judge software developer dianggap lebih penting daripada memberikan coaching terus menerus yang dapat memperbesar kapasitas dan kapabilitas software developer. Yang lebih parah lagi kalau kriteria kinerja tinggi software developer yang digunakan pada saat performance appraisal adalah iron triangle  — on-time, on-budget dan on-scope — yang tidak masuk akal itu. HRD adalah salah satu pihak yang diharapkan untuk dapat memberikan coaching kepada software developer mengingat banyak dari mereka yang memiliki latar belakang psikologi, namun berapa banyak dari HRD yang paham mengenai Agile Coaching dan memberikan coaching secara aktif kepada software developer di Indonesia? Hampir tidak ada.

“Leadership is the process of creating an environment in which people become empowered.”

Perusahaan sering kali bermimpi untuk mendapatkan software developer yang mature dan self-organising, namun pada saat yang bersamaan perusahaan tidak menempatkan investasi yang cukup untuk sebuah peran yang bertugas untuk mendewasakan software developer. Perusahaan berharap ada sebuah mukjizat dari surga yang dapat mendewasakan software developer dalam sekejap. Walaupun peran seperti Agile Coach dan Scrum Master sudah dirasakan manfaatnya dan dianggap penting di belahan dunia lain, tetapi peran ini belum dianggap penting sama sekali di Indonesia. Kenapa demikian? Karena seorang Agile Coach atau Scrum Master dilihat sebagai seseorang yang lemah dan tidak memiliki otoritas. Orang Indonesia ingin memerintah orang lain, karena hanya dengan demikian ia dipandang sebagai seseorang pemimpin yang hebat dan memiliki otoritas. Top-down approach gaya penjajah lebih digemari oleh perusahaan-perusahaan di Indonesia daripada bottom-up approach yang memaksimalkan collective intelligence.

Top down solutions ignore the knowledge & wisdom that exists throughout an organization.

Seseorang tidak secara otomatis menjadi dewasa, bahkan sampai saat ini pun saya masih memiliki mentor pribadi yang secara terus menurus membantu saya dalam karir saya. Kepemimpinan bukanlah mengenai mengambil semaksimal mungkin dari orang-orang di perusahaan kita namun justru mengenai pelayanan terhadap orang-orang kita. Software developer pada dasarnya adalah orang-orang yang cerdas. Orang cerdas perlu di-coaching agar potensi yang ada di dalam diri mereka dapat dikeluarkan. Bottom up approach dengan model Scrum lebih tepat untuk lingkungan software development yang berisi banyak knowledge worker.

---

Apabila anda adalah seorang software developer yang menginginkan agar HRD, atasan, manajer proyek, analis bisnis, user, kostumer, sales, marketing memahami bahwa apa yang anda kerjakan sebagai software developer itu kompleks silahkan sebarkan artikel ini. Kalau anda ingin memperbaiki ekosistem software development di Indonesia dan menyelamatkan lebih banyak lagi software developer yang saat ini sedang di-abuse dengan manajemen gaya feodal, silahkan sebarkan artikel ini. Silahkan retweet, share, like, reblog, recommend, repath, sebar ke milis kantor, sebar ke forum diskusi tanpa harus meminta ijin terlebih dahulu dari saya.

Ini adalah peperangan melawan cara berpikir feodal di dalam industri software development Indonesia yang sudah mencapai tingkat akut. Mari kita bersama memanusiawikan software developer di Indonesia. Bila semakin banyak orang Indonesia yang teredukasi mengenai proses kerja software development yang seharusnya dan bisa keluar dari cara berpikir kuno yang tidak bisa dibuktikan secara ilmiah, maka ekosistem software development di Indonesia akan semakin sehat dan semakin banyak software developer yang tidak perlu merenungi nasib kenapa dirinya adalah seorang software developer.

sumber : https://medium.com/modern-management/5-mitos-di-industri-software-development-indonesia-df5045350e45