Tag Archives: didiet noor

Ramainya Usaha Rintisan Transportasi di Indonesia, Apa Untungnya untuk Pengembang?

Tahun 2016 ini menjadi sebuah puncak dari keramaian usaha rintisan (startup) dalam bidang transportasi dan jasa logistik instan. Berita terakhir bahkan Go-Jek membukukan pendanaan sebanyak $550.000.000,00 atau dengan kurs 1 USD = 13197.6 IDR; nilainya sekitar Rp 7.258.652.500.000,00. Iya digitnya sebanyak itu. Sangat luar biasa.

Uang sebanyak itu tentunya bisa digunakan untuk mengembangkan produknya menjadi lebih baik dan lebih aman. Saya berharap bagian sangkalan (disclaimer) ini tidak ada lagi dan saya mau pakai Go-Jek lagi.

Kami tidak menjamin keamanan database kami dan kami juga tidak menjamin bahwa data yang anda berikan tidak akan ditahan/terganggu ketika sedang dikirimkan kepada kami. Setiap pengiriman informasi oleh anda kepada kami merupakan risiko anda sendiri. Anda tidak boleh mengungkapkan sandi anda kepada siapa pun. Bagaimanapun efektifnya suatu teknologi, tidak ada sistem keamanan yang tidak dapat ditembus.

Tapi kali ini saya tidak membahas itu tentunya karena melenceng jauh dari judul. Saya akan bahas apa untungnya untuk pemrogram/pengembang di Indonesia.

Adanya Kebutuhan Memecahkan Masalah

Saya sangat senang akhir-akhir ini usaha-usaha rintisan yang ada di Indonesia mulai dengan masalah yang nyata. Go-Jek sendiri sudah dimulai tahun 2011, tetapi baru mulai mendapatkan traksi tahun 2015. Permasalahan kemacetan dan harga ojek yang mahal diatasi dengan adanya Go-Jek ini.

Masalah lain yang juga diatasi oleh Go-Jek adalah soal logistik. Go-Jek mengatasi permasalahan pengiriman instan. Dulu tidak ada seperti ini. Kita perlu harus mengirim surat dan barang sendiri atau meminta tolong kurir. Akses orang terhadap kurir terbatas, tetapi sekarang semua orang punya kurir, tinggal di-Go-Jek-in aja.

Masalah logistik instan ini juga baru ada di beberapa tahun terakhir karena mulai banyaknya platform dagang daring horisontal C2C (consumer to consumer) maupun dari pedagang-pedagang di Facebook. Sekarang mereka punya pilihan untuk mengirimkan barangnya dalam waktu kurang dari sehari.

Keberadaan Masalah Membentuk Talenta

Keberadaan masalah-masalah besar inilah yang membentuk talenta-talenta teknologi. Kemampuan talenta diasah dari perusahaan-perusahaan di mana dia bekerja. Banyaknya e-commerce beberapa tahun belakangan melahirkan talenta-talenta teknologi seperti pemrogram, perancang, dan pemasar digital yang mengerti tentang keperluan e-commerce dari sisi teknologi dan operasinya karena mereka terpapar dengan masalah tersebut setiap hari. Saat ini sudah banyak talenta yang mengerti cara memecahkan masalah seperti inventori, gudang, pembayaran, pemasaran digital dan sebagainya.

Manusia adalah makhluk yang selalu belajar. Jika terpapar permasalahan yang sama setiap hari, maka kita makin ahli dalam mengatasi masalah tersebut. Google awalnya juga mesin cari sederhana, tetapi dengan banyak iterasi, kesempatan, dan modal bisa jadi seperti sekarang ini. Mungkin Indonesia belum sampai ke level pemodal ventura mendanai proyek-proyek eksperimental seperti di Amerika. Tetapi, kabar baiknya kita punya masalah yang mungkin hanya bisa diatasi orang yang hidup di Indonesia.

Demikian pula dengan e-commerce, dengan tercurahnya modal ke e-commercemaka terbuka kesempatan talenta di Indonesia untuk semakin paham, ahli, dan efektif tentang e-commerce. Logistik adalah permasalahan besar selanjutnya yang harus diatasi. Dengan tercurahnya modal ke Go-Jek saya harapkan terbuka kesempatan pengembang-pengembang di Indonesia untuk terpapar dengan permasalahan logistik. Permasalahan logistik ini bukan permasalahan sederhana, cukup kompleks. Yang tidak instan saja sudah berat, apalagi yang instan.

Masalah Logistik Adalah Masalah Algoritmik

Jika e-commerce domain masalahnya rata-rata bersifat CRUD (Create Read Update Delete) dan stateless, permasalahan dalam logistik, terutama yang instan adalah permasalahan yang stateful dan berat di algoritma. Masalah yang solusinya algoritmik harus bisa diselesaikan secara deterministik dan yang penting cepat. Berikut mungkin hal-hal yang perlu diperhatikan oleh pengembang jika mau terjun ke perusahaan digital yang mencoba mengatasi masalah transportasi dan logistik:

  • Proyeksi — Bumi itu bulat, tetapi dalam perhitungan jarak, mau tidak mau kita harus “mendatarkan” bumi terlepas Anda percaya atau tidak dengan teori flat earth. Garis lintang dan bujur tidak bisa digunakan untuk menghitung jarak kecuali diproyeksikan terlebih dahulu. Banyak sekali bentuk proyeksi ini, dan kita harus tau mana yang pas.
  • Teori Graf — Jika ketika kuliah, Anda pernah mempelajari tentang graf dan tree beserta berbagai macam algoritma graph traversal seperti BFS, DFS, Djikstra, dan A*, percayalah pengetahuan tentang algoritma tersebut sangat diperlukan dalam memecahkan masalah logistik. Lalu lintas dan perutean itu cara membuat abstraksi modelnya adalah dengan graf.
  • Aljabar Linier — Semua yang berhubungan dengan koordinat akan berurusan dengan aljabar linier sudah suatu keniscayaaan. Jadi buka-buka lagi jika masih punya buku aljabar linier yang berdebu di pojok ruangan.
  • Jaringan dan Protokol — Sudah saatnya pemrogram membuka diri kalaudi dunia ini yang namanya protokol tidak hanya HTTP dan tidak semuanya RESTful. Pemrogram harus mulai membuka diri bagaimana memakai protokol yang pas. HTTP mempunyai payload yang cukup besar. Payload yang besar akan cepat menghabiskan kuota pelanggan, apalagi harus mengirim posisi setiap menit.
  • Konkurensi — Dengan masalah yang stateful, pemrogram akan berhubungan dengan masalah konkurensi. Bagaimana mempertahankan dan mengatur state dan mengatasi kondisi seperti deadlock dan race condition.

Selain itu ada masalah-masalah di dunia ilmu komputer yang belum ada solusinya. Ya betul, Anda tidak salah baca. Ada beberapa permasalahan dalam logistik yang belum ada solusi algoritmiknya yang artinya harus memakai solusi non-deterministik maupun brute-force.

Satu permasalahan yang sangat menarik adalah Travelling Salesman Problem. Masalahnya cukup sederhana, jika kita punya misalnya 5 lokasi, bagaimana membuat urutan dari titik awal dan kembali lagi ke titik semua sehingga jarak yang ditempuh minimal. Semakin banyak titik kemungkinannya akan jadi (n-1)!. Artinya kalau menambah satu titik lagi naiknya kemungkinan yang harus dicoba jadi tambah banyak. Jika kita punya 5 lokasi, ada sekitar 24 kemungkinan, tetapi jika kita menambah satu lagi maka kemungkinannya akan naik jadi 120 demikian seterusnya.

Komik dari XKCD ini cukup menggambarkan masalah ini:

Guyonan XKCD tentang Travelling Salesman
Guyonan XKCD tentang Travelling Salesman

Jika meruntut ke Wikipedia kita dihadapkan ke kenyataan kompleksitas algoritma ini:

In the theory of computational complexity, the decision version of the TSP (where, given a length L, the task is to decide whether the graph has any tour shorter than L) belongs to the class of NP-complete problems. Thus, it is possible that the worst-case running time for any algorithm for the TSP increases superpolynomially (perhaps, specifically, exponentially) with the number of cities.

Banyak pemecahan masalah, tapi belum ada yang deterministik dan cepat. Jadi pemrogram yang biasa berpikir “ah ini gampang, besok pasti bisa” sebaiknya berpikir ulang jika dihadapkan dengan permasalahan TSP.

Pada akhirnya saya berharap dengan dipaparnya mereka dengan permasalahan di dunia nyata, kemampuan pemrogram di Indonesia terasah dalam mengatasi permasalahan-permasahan dalam bidang logistik. Semakin banyak yang bisa dan menularkan ilmunya ke timnya, semakin bagus. Semoga pendanaan bertriliun-triliun Go-Jek bisa membuka kesempatan yang mungkin akan jadi efek halo untuk usaha-usaha lainnya yang bergerak di bidang logistik.


Disclosure: artikel tamu ini telah dipublikasi ulang dengan penyuntingan dan izin dari Didiet Noor. Artikel ini pertama kali diterbitkan di halaman Medium-nya.

Didiet adalah seorang software engineer dan tech advocate. Ia bisa dikontak via @lynxluna.

Bootstrapping And Growing Your Tech Team

So you’re a technical founder of a young exciting startup. You’re expected to take technical role and build a team to build the product. So how we’d start?

The founding team

When you build a team, there’s one common pattern on founding team: they are focusing on speed and time to market. As a tech founder, you might find this at odd with code quality, and that is right. We always strive on confidence on every build. In ideal world every build should have unit tests, integration tests, stress tests and then delivered to customer, but in a lot of cases, it’s mutually exclusive with time to market. So how to tackle this issue?

Step 1: Define Your Product Team

The good thing about startups is team is usually small and communication is easy. During this good time, it’s important to define the role of the product team to cover every facet of product development lifecycle. I usually divide the team to 4 big chunks.

1 pcAshrWxuHJhXqvpLouWLQ

Every person needs to take or assume one of the role. Every product team that I’ve built or I helped to build usually consists of those four roles with different titles. Every single person on the startup that consider themselves as the product team needs to take one of the role. The roles are divided this way to give a clear ownership of every step and facet on product development. Let’s take a look:

  1. Product Owner is usually assumed by the guy that know the business process and rules on the product. In early stage, often this role usually taken by the CEO. This role owns the product features and the priority.
  2. Project Manager is the guy that focuses on getting things down. This role owns the timeline and resources.
  3. Developer is self explanatory. They code the product, they make dream comes true. This role owns the code and infrastructure.
  4. Quality Assurance is the gatekeeper. They must be the fiercest defender of the product quality.

This role division also serves as a guide for future career path. All four of them need to be equal, and nobody should serves in two roles in the same time, because the nature of division is to provide balance.

The reason I draw line over them is to illustrate the tug of war or tension that needs to be maintained. The team breaks apart if one party too push in or to push out. We need to maintain the strain just enough to make the team works.

Step 2 : Lay out process and tools

A product success chance can be increased by adhering process. A popular framework is agile processes such as scrum or kanban. Choose one and stick to it, if one does not work, switch and try. Attend a training or learn the video together with the team. Talk with other companies who do similar process. Although many people start to declare the demise of the agile. At the moment, it’s the only available process framework that have and still works.

As a technical founder, we’re also expected to lay out the engineering process because it’s your domain. You’re expected to know and do things like code review and automated build. If you lucky enough you may be able to create a continuous delivery/integration/deployment process.

The tools I usually use are as follows:

  1. JIRA Software — I use it to organise user stories and to know the visibility on the project.
  2. Test Rail — I use it for QA team to create test suites and test cases for our products.
  3. GitHub — Everybody knows it, it’s hands down the best place to place the code.
  4. Travis CI — it’s tied with GitHub, it provides easy automated build tools for your CI and CD needs.
  5. Fabric.io — as majority of the team I’m involved with is mobile team, fabric gives us flexible platform for distributing beta and getting crash logs.
  6. Instabug — for instant bug report, it also reports crashes. I use it for the beta testers.
  7. Amazon Web Services — a very popular cloud. I’ve tried many others too, but mostly I’m working with AWS.

Step 3 : plan the roadmap and educate your team

I’ve seen a startup that take the quote “move fast and break things” to the extreme. They deliver bad product that constantly breaks down. To avoid that, plan your product roadmap. Discuss with the whole team about it. The most important roadmap items for early stage startup is the first 3–6 months. For each milestone put a theme or common goal. For example in the first 3 months is MVP, the 3–9 months is the user acquisition, and so on. So people on your team aligned.

If you have sizeable team, focus on a high leverage activities such as mentoring and building a solid onboarding process for new hires. This will save a lot of time for building products. Aside of the technical materials needed to build the product such as iOS or Android training, spend some time and money to buy books like Clean Code.

The MVP Phase

Getting the product out of the door is hands down, the goal of an early stage startup, and speed is important. We may not have a luxury of writing unit and integration test in this stage. On early stage, most of the burden is usually shifted towards QA as the gatekeeper. Here, QA team need to be resilient and tough as more manual tests need to be done. Crashes and major bugs is pretty detrimental for an MVP. Minor bugs are somewhat okay because it can be fixed quickly. You may as well implement a continuous delivery system in this phase. Not doing so is anti pattern because CD is a high leverage activity on this phase regarding to speed and fast feedback. I somehow puzzled with contradicting excuse of not doing CD early on: because they have no time due to the speed requirement. You have no time to save time. Haha!

The User Acquisition Phase

This where the things shifted from speed to robustness. Pressure is in the dev team. Implement things that you had no chance to implement in the first three months. Write unit tests, write the tests that you haven’t written in the first 3 months, implement code review, refactor ruthlessly. We still deal with speed but robustness takes priority on user acquisition. Improve the QA test cases and automate what can be automated. We want to make sure we have high confidence on features delivered to the users on this phase. In this phase, there is usually business shift, changes here and there, new hires coming in and we still want to have high confidence on our build.

The “Next” Phase

Writing software product is never ending. The first two phases are usually the hardest. When you pass those phases, you usually already build a somewhat complete team. So the focus is shifted to scale. Scaling the product, scaling the team. The first 4 roles will expand. So in this phase, what you need is a leader of the pack or manager. Hire or promote managers, build a career path and training plan. But one thing to note, keep the organisation as flat as possible.

For the developers, it’s time to learn distributed system and architecture. You may start with a simple CRUD backend in the start, but overtime it’s going to be large. In this phase, think about the architecture, decide the parts we need to be refactored first and so on.

Conclusion

This is only one way of building a startup tech team. People mileage can vary. One thing about technical founder is to keep in mind that you need to strive for perfection. In many cases, I see tech team is neglected. So find a good founder that realise that tech team is as important as “the business guy”.


This article has been republished with editing and permission from Didiet Noor. Original source is from Medium.

Didiet is a software engineer and tech advocate. He can be contacted via Twitter @lynxluna.

Didiet Noor Tinggalkan Posisi Developer Evangelist di BlackBerry

Application Development Consultant and Developer Evangelist BlackBerry Muhammad Sumyandityo Noor resmi mengumumkan pengunduran dirinya dari perusahaan pembuat smartphone yang berbasis di Kanada tersebut per 30 Juni mendatang. Didiet Noor, begitu ia biasa dipanggil, memilih untuk mengambil waktu istirahat sepanjang Ramadhan ini di kota asalnya Yogyakarta.

Continue reading Didiet Noor Tinggalkan Posisi Developer Evangelist di BlackBerry

Registrasi BlackBerry 10 Jam Jakarta Telah Dibuka (Updated)

Didiet Noor, yang baru saja ditunjuk sebagai Developer Relations/Evangelist Research In Motion (RIM) hari ini melalui akun Twitter-nya mengumumkan bahwa registrasi BlackBerry 10 Jam Jakarta telah dibuka. Pengembang yang berminat untuk mengikuti acara ini dapat mendaftarkan diri melalui tautan yang ada pada halaman ini. Karena acara ini bersifat gratis dan terbatas ada baiknya registrasi segera dilakukan.

Seperti telah diberitakan sebelumnya, acara ini akan akan digelar pada tanggal 10 Juli mendatang. Yang baru saja diumumkan adalah bahwa acara ini akan digelar di JW Marriot Hotel, di Kawasan Mega Kuningan Jakarta.

Secara umum, BlackBerry 10 Jam World Tour digelar Reserach In Motion untuk memperkenalkan BlackBerry 10, sistem operasi terbaru BlackBerry kepada pengembang aplikasi di seluruh dunia. Diharapkan, dengan mengetahui seluk beluk tentang sistem operasi ini, banyak pengembang aplikasi akan tertarik untuk mengembangkan aplikasi untuk BlackBerry 10.

Continue reading Registrasi BlackBerry 10 Jam Jakarta Telah Dibuka (Updated)

Didiet Noor Bergabung ke RIM Sebagai Developer Relations/Evangelist untuk Indonesia

Muhammad Sumyandityo Noor atau yang lebih dikenal dengan nama Didiet, telah ditunjuk sebagai Developer Relations/Evangelist untuk RIM. Didiet sebelumnya adalah produser di Guava Games dan CTO Oneb1t yang berbasis di Yogyakarta. Peran yang akan dijalankan Didiet sebagai Developer Relations/Evangelist RIM adalah mengajak para developer mobile di Indonesia untuk bergabung dan mengembangkan aplikasi di platfrom terbaru RIM yang akan datang, BlackBerry 10. Walaupun Didiet masih menjadi pemegang saham di Guava Games dan Oneb1t Media, ia tidak lagi memegang peran aktif di dua perusahaan ini sejak ia mengundurkan diri untuk mengabdi secara penuh kepada RIM.

Pengembangan aplikasi BlackBerry terlihat cukup berkembang di Indonesia meskipun Android dan iOS bertumbuh sangat pesat di seluruh dunia. Angka terbaru yang dipublikasikan oleh Gartner menempatkan RIM pada posisi ke tujuh di antara produsen ponsel global dalam hal perangkat yang terjual, dengan kurang dari 10 juta unit di kuartal pertama tahun 2012. Setahun yang lalu, RIM menjual lebih dari 13 juta perangkat, yang berarti ada penurunan lebih dari 25 persen. Untung bagi RIM, developer Indonesia sepertinya tidak terpengaruh oleh laporan ini.

Continue reading Didiet Noor Bergabung ke RIM Sebagai Developer Relations/Evangelist untuk Indonesia

Didiet Noor Joins RIM As Developer Relations/Evangelist for Indonesia

Former producer at Jogjakarta based Guava Games and CTO of Oneb1t Media Muhammad Sumyandityo Noor, better known as Didiet, has been appointed RIM’s developer relations/evangelist for Indonesia. His responsibilities essentially is getting Indonesia’s mobile developers on board RIM’s upcoming platform, the BlackBerry 10. While he remains a shareholder at Guava Games and Oneb1t Media, he no longer holds an active role in either company as he has resigned to take up the full time role at RIM.

BlackBerry applications development has seen some serious uptake in Indonesia despite the platform’s growth being savaged across the world by the ever expanding Android and iOS. Recent figures published by Gartner placed RIM seventh among global phone makers in terms of units sold with less than 10 million units in the first quarter of 2012. A year ago RIM sold over 13 million devices which means it saw a drop of over 25 percent in sales. Fortunately for RIM, Indonesian developers seem immune to such reports.

Continue reading Didiet Noor Joins RIM As Developer Relations/Evangelist for Indonesia

Mengapa Developer Indonesia Masih Tertarik dengan PlayBook?

Research In Motion akhirnya meluncurkan tablet 7-inci mereka yang diberi nama PlayBook pada bulan April lalu setelah tertunda sejak 2010. Meskipun tablet ini ditujukan untuk pasar korporat, perangkat ini tidak dilengkapi dengan fasilitas yang sesuai dengan pasar tersebut. Tidak memiliki dukungan email, kalender, dan tidak ada fasilitas BlackBerry Messenger, kecuali ditambatkan ke sebuah ponsel BlackBerry.

Secara global PlayBook mengecewakan, karena dalam 3 kuartal, pengiriman perangkat ini hanya mencapai 850.000 unit, dan penjualannya sangat, sangat sedikit. RIM mengirimkan 500.000 unit PlayBook pada kuartal pertama penjualan, menurun menjadi 200.000 pada kuartal kedua, dan kemudian 150.000 pada kuartal terakhir tahun lalu. Jumlah ini adalah unit yang dikirimkan ke pengecer, bukan dijual kepada konsumen.

Continue reading Mengapa Developer Indonesia Masih Tertarik dengan PlayBook?

Why Are Indonesian Developers Still Interested in the PlayBook?

Research In Motion finally launched the 7-inch PlayBook tablet back in April last year after much delay since 2010. Though the tablet was aimed at the enterprise market, it shipped with none of the tools used in the field. It had no email support, no calendar, and no BlackBerry Messenger, unless tethered to a BlackBerry phone.

Globally, it was disappointing, having shipped only 850,000 units in three quarters and selling clearly much, much less. RIM shipped 500,000 PlayBooks in its first quarter of sales, dropping to 200,000 in the second, and then 150,000 in the last quarter of the year. Those are units shipped to retailers, not sold to consumers.

The company then put the PlayBooks through two fire sales, first at the end of last year when it halved the prices of each model, and then this month when it changed the prices to just $299 across all three models. It also failed to deliver 3G and WiMax versions of the device.

Despite those glaring failures, there are software developers who are still interested in creating applications for the PlayBook. At the BlackBerry developer conference in Singapore in early December, over a thousand attendees showed up and each one received a complimentary PlayBook.

Continue reading Why Are Indonesian Developers Still Interested in the PlayBook?