seminar at bizzy.co.id 22 feb 2016

Mengapa menggunakan framework?

Topik ini adalah salah satu bahasan yang cukup sering ditanyakan oleh programmer-programmer muda (saya belum tua tapi ya) yang baru akan memulai atau baru selesai memperlajari cara menggunakan framework. Sekedar flashback, penggunaan framework pada sekitar tahun 2005-an masih belum populer di Indonesia. Dan pada saat itu, konsep bahwa menggunakan framework menambahkan kode / size yang tidak perlu sangat mendominasi keputusan untuk mengarah ke scratch (tanpa framework).

Karena keterbatasan processing power dan kapasitas harddisk, sayapun pada saat itu juga mengarah untuk tidak menggunakan framework. Namun apa yang saya rasakah setelahnya adalah:

kalau kamu cukup mahir dan tidak menggunakan framework yang tersedia, kamu pasti akan membangun framework-mu sendiri

Mengapa demikian?

Susunan folder dan penempatan file

Untuk project berskala besar dengan tingkat kesulitan kompleks, susunan folder dan penempatan / pengelompokkan file menjadi suatu hal yang penting. Susunan file yang berantakan akan menyulitkan programmer-programmer lain untuk memahami kode, serta mengurangi kualitas dan meningkatkan resiko terjadinya bug.

Framework, pada umumnya sudah memiliki panduan untuk penempatan / pengelompokkan file-file dalam folder-folder tertentu. Standarisasi tersebut akan mempercepat programmer-programmer lain dalam memahami kode, atau mencari posisi kode yang menjalankan proses-proses tertentu. Contohnya folder config, constants, language dan sebagainya.

Bila tidak mengikuti / menggunakan framework yang tersedia secara umum, saya cukup yakin anda nanti akan membangun standar dan aturan pengelompokkan sendiri.

Arsitektur

Umumnya sebuah framework mengikuti susunan arsitektur tertentu. Misalnya pada php, umumnya framework-framework digunakan arsitektur MVC atau HMVC, karena paling cocok dalam server-client architecture. Bila menggunakan contoh lain, misalnya C# dan desktop, prism adalah framework MVVM untuk WPF.

Bagi programmer-programmer yang memahami manfaat arsitektur dalam pemograman, saya cukup yakin bila mereka tidak menggunakan framework yang tersedia, maka mereka akan membangun arsitektur yang mirip (misal dengan MVC).

Class Library

Project yang kompleks memerlukan banyak sekali operasi yang beragam. Namun tidak sedikit dari operasi tersebut yang mirip, berulang dan dapat dikelompokkan menjadi library / class library. Contohnya: logging, serialization, export to excel/csv, image manipulation dan masih banyak lagi.

Framework umumnya sudah memiliki cara sendiri / standar untuk meng-organize library-library tersebut. Contohnya pada laravel yang sudah menggunakan composer sebagai package manager, dan PSR4 untuk autoload class.

Common cases / operation

Mirip dengan class library, ada beberapa kasus / operasi yang umum dan sering ditemui dalam pengembangan applikasi. Contohnya bila dalam php adalah routing, login authentication, response type dan view templating. Umumnya framework sudah mendukung operasi-operasi tersebut.

Standar pengembangan, update dan komunitas

Keuntungan dari menggunakan framework yang tersedia, adalah framework tersebut sudah memiliki standar pengembangan (penempatan kode). Framework juga umumnya diupdate mengikuti teknologi terbaru, dan memiliki komunitas pengguna yang secara tidak langsung meningkatkan kualitas framework, dan mengurangi kemungkinan bug yang ada.

Kesimpulan

Banyak keuntungan yang didapat dengan menggunakan framework. Dan meskipun seseorang yang mahir tidak menggunakan framework yang sudah tersedia, cepat atau lambat applikasi yang dikembangkan akan mengarah dan pada akhirnya menghasilkan framework buatan sendiri.

skill

Saya programmer dengan skill tinggi, saya pasti bisa sukses

Apakah anda seorang programmer? Dan apakah anda berpikiran hanya dengan skill yang tinggi maka anda bisa sukses di dunia kerja / dunia bisnis? Tunggu dulu, ada beberapa faktor yang perlu diketahui sebelumnya.

Skill technical hanya menentukan separuh dari kesuksesan anda sebagai programmer

Apakah benar begitu? Skill technical hanya menentukan separuh dair kesuksesan anda sebagai programmer? Lalu sisa separuhnya adalah faktor-faktor apa lagi?

Mungkin skill technical bisa menentukan lebih dari separuhnya (50%), tapi tidak akan melebihi 70-80% sebagai faktor penentu kesuksesan anda sebagai programmer. Faktor penentu sisanya didominasi oleh skill komunikasi dan negosiasi. Saya tidak akan membahas attitude di sini karena pada artikel ini, saya akan lebih fokus kepada skillset yang diperlukan.

Skill / kemampuan komunikasi

Sebagai pelajar dalam dunia IT dan pemograman, saya juga awalnya tidak tahu seberapa pentingnya kemampuan komunikasi dalam dunia pemograman. Namun setelah memasuki dunia kerja / organisasi, tampak jelas bagi saya seberapa penting, sering dan bergunanya kemampuan komunikasi dalam dunia pemograman. Bila dibandingkan dengan skill-skill non-technical lainnya, saya rasa skill komunikasi adalah yang paling berpengaruh dan bermanfaat dalam dunia pemograman.

Saat interview

Bahkan sebelum interview, kemampuan komunikasi anda akan sangat menentukan apakah anda akan mendapatkan panggilan interview atau tidak. Personal branding, desain CV yang bagus serta dapat menunjukkan skill-skill utama anda, sangat membantu anda dalam mendapatkan panggilan interview.

Pada saat interview, kemampuan komunikasi anda tentu akan lebih berpengaruh lagi. Bagaimana anda berkomunikasi tatap muka dengan orang-orang yang tidak mengenal anda, dan bagaimana anda mempersiapkan diri dengan penampilan terbaik tentu akan dipengaruhi oleh kemampuan komunikasi anda.

Komunikasi dengan atasan

Sebagai programmer, anda akan mendapat proyek / tugas dari atasan / team leader. Pada saat pemberian tugas tersebut, akan ada beberapa kondisi yang memerlukan skill komunikasi. Seperti bagaimana anda bertanya mengenai hal-hal yang tidak jelas dari tugas tersebut, atau mungkin saja ada beberapa ide terkait tugas tersebut yang bisa anda sampaikan. Kemampuan komunikasi anda akan sangat membantu dalam proses tersebut.

Selain itu, umumnya saat sebuah tugas / proyek selesai, sang programmer akan memberikan laporan kepada atasannya. Bagaimana cara menyusun laporan yang baik dan cepat dimengerti, sedikit banyak akan dibantu oleh kemampuan komunikasi anda.

Komunikasi dengan sesama programmer

“Program saya error”, “entah mengapa applikasi ini tidak jalan”, “kenapa datanya duplikat ya?”. Banyak sekali proses komunikasi yang akan terbentuk antar sesama programmer pada saat proyek dikerjakan. Contoh paling umum adalah saat anda perlu menanyakan proses detail dari module yang sebelumnya dikerjakan rekan programmer. Dan sebaliknya, saat anda ditanya oleh rekan anda terkait modul yang anda kerjakan sebelumnya. Sekali lagi, kemampuan komunikasi anda akan diuji di sini.

Komunikasi dengan user / non-technical

Ada beberapa perusahaan yang memerlukan anda untuk berhubungan langsung dengan user / pihak non-teknis. Di sinilah kemampuan komunikasi diuji. Bagaimana cara kita menjelaskan proses techincal kepada pihak-pihak non-technical, yang tidak mengerti istilah-istilah dalam dunia IT.

Skill negosiasi

Skill negosiasi / persuasi sangat diperlukan, terutama pada saat interview. Ya, tentu saja soal gaji dan benefit / tunjangan. Hanya dengan memiliki kemampuan negosiasi dan persuasi saja memungkinkan gaji anda bisa lebih tinggi dari standar dengan tunjangan yang lebih oke.

Selain untuk interview, skill negosiasi / persuasif akan berguna saat berdiskusi / berdebat mengenai kandidat-kandidat solusi untuk sebuah project. Contohnya, senior anda akan marah / tidak terima bila langsung dikatakan “solusi anda nggak akan jalan”. Namun bila diutarakan dengan lebih baik, misal “cara itu ada banyak request ke server kan? Apakah nggak akan membebani? Kalau misalnya begini … bagaimana?” tentu akan lebih mudah diterima dan mereka akan kurang resistif.

Dunia bisnis

Dalam dunia bisnis, lebih banyak lagi skill yang diperlukan selain skill-skill di atas. Contohnya seperti skill leadership / management, networking, kemampuan inovasi, desain dan marketing. Di sini, pengaruh kemampuan technical terhadap kesuksesan anda jadi lebih kecil dibandingkan dalam dunia kerja.

Kesimpulan

Walaupun programmer memiliki tugas utama untuk mengembangkan program, namun bukan berarti skill-skill lain tidak ikut ambil bagian dalam menentukan kesuksesan anda di dunia kerja. Terlebih lagi dalam dunia bisnis. Skill komunikasi dan negosiasi cukup berperan dalam membantu menentukan kesuksesan anda di dunia kerja.

Gaji programmer di Indonesia rendah, kok bisa?

Latar belakang

Selama saya beraktifitas dalam komunitas programmer dan berdiskusi dengan programmer2 lain, banyak muncul pertanyaan mengapa gaji programmer di Indonesia tergolong rendah bila dibandingkan dengan negara-negara lain. Saya pernah memberi beberapa jawaban yang kira-kira mampu menggambarkan sebab-akibat rendahnya gaji programmer di Indonesia. Pada kesempatan kali ini, saya mencoba merangkumnya dalam sebuah tullisan artikel dengan harapan lebih banyak orang yang dapat melihatnya dan mempermudah saya menjelaskan topik ini berulang kali.

Gaji programmer

Periode saat saya mulai berkarir di dunia pemograman adalah sekitar awal 2012. Saat itu kisaran gaji programmer entry level adalah di 3 juta rupiah hingga 4 juta rupiah. Saat ini di awal 2016, kisaran gaji programmer entry level juga tidak jauh berubah, sekitar di kisaran 4 juta rupiah.

Nilai ini tergolong rendah bila dibandingkan dengan negara2 tetangga seperti singapura dan malaysia. Apalagi dengan banyaknya berita tentang hebatnya jadi programmer dan beberapa kisah programmer yang sukses membuat kita merasa tingkatan gaji programmer di Indonesia tergolong rendah. Benarkah begitu?

Nilai tukar rupiah dan nilai biaya hidup

Salah satu penyebab rendahnya gaji programmer bila dibandingkan dengan negara-negara lain di level setingkat adalah karena rendahnya nilai tukar rupiah dibandingkan dengan mata uang asing. Selain itu, rendahnya nilai biaya hidup di Indonesia membuat perusahaan-perusahaan tidak terdesak untuk meningkatkan gaji programmer.

Masih dianutnya konsep tradisional career ladder di perusahaan

Career ladder yang masih dianut di Indonesia adalah yang masih bersifat tradisional. Jenjang karir tersebut berarti setelah diawali dari junior programmer, dilanjutkan dengan senior programmer dan masuk ke jenjang managerial. Sementara konsep career ladder modern memungkinkan seorang programmer untuk naik ke jenjang berikutnya sebagai spesialis (technical) dan professional, salah satunya sebagai enterprise architect.

Konsep tradisional ini membuat stereotype bahwa gaji manajemen / project manager lebih tinggi dari programmer, dan gaji programmer sekali lagi terlihat rendah.

Supply and demand

Bila kita teliti lagi, gaji-gaji tinggi programmer di luar negeri dikarenakan kebutuhan akan skill programming yang juga tinggi dan tanggung jawab yang juga tinggi. Katakan Microsoft, Google, Facebook dan juga Wordpress (promosi terselubung) memerlukan programmer dengan skill yang tinggi dan tanggung jawab yang besar. Di samping itu, perusahaan2 tersebut juga adalah perusahaan IT yang bersifat sebagai provider / enabler, yang mana pendapatannya lebih tinggi dan service-nya lebih diminati.

Berbeda dengan kondisi di Indonesia. Hinga tahun 2010, mayoritas programmer diperlukan untuk men-develop custom application di software house atau internal perusahaan. Programmer2 tersebut masih menggunakan teknologi yang di-provide oleh perusahaan2 dari luar negeri seperi microsoft, SAP, atau wordpress. Dan sistem yang dikembangkan sebagian besar hanya bersifat CRUD atau administration screen.

Sejak tahun 2010, banyak startup-startup digital muncul di Indonesia. Kebutuhan akan programmer dengan skill lebih tinggi meningkat. Namun tetap saja peningkatan tersebut belum maksimal karena Indonesia masih belum mencetak produk-produk digital yang bisa digunakan secara internasional. Dan juga, demand untuk embedded programming dan robotik juga masih rendah, membuat kisaran gaji programmer juga ikut rendah.

Stereotype bahwa skill programmer Indonesia rendah

Masih berkaitan dengan supply and demand, rendahnya demand untuk programmer dengan skill tinggi membuat programmer2 dengan skill yang tinggi untuk mencari pekerjaan di luar negeri. Pencarian kerja di luar negeri dilakukan dengan harapan untuk mendapatkan gaji yang lebih tinggi dari kisaran gaji-gaji di Indonesia.

Kondisi tersebut mengakibatkan munculnya pandangan bahwa programmer-programmer di Indonesia memiliki skill yang lebih rendah dari programmer-programmer dari luar negeri. Maka saat startup-startup / perusahaan baru ingin menempatkan programmer di posisi strategis, maka dipilihlah mereka-mereka yang berasal dari luar.

Sulit menilai programmer dengan skill tinggi

Dari kacamata non-teknis, sulit membedakan programmer dengan skill tinggi atau programmer dengan skill rendah. Dengan anggapan bahwa semua programmer (katakan yang bisa bahasa pemograman php) memiliki skill yang sama, maka memilih programmer-programmer yang setuju dengan gaji rendah adalah logis.

Rendahnya dukungan pemerintah / institusi resmi di Indonesia

Partisipasi pemerintah dan institusi-institusi di Indonesia tegolong cukup rendah dalam bidang IT. Rendahnya partisipasi itu membuat perusahaan-perusahaan, terutama yang menengah di Indonesia menjadi antipati terhadap investasi dalam bidang IT. Mereka jadi beranggapan bahwa investasi IT tidak menghasilkan, mahal dan beresiko tinggi. Ditambah lagi dengan banyaknya transaksi / dokumen di Indonesia yang lebih diutamakan secara manual, makin membentuk anggapan perusahaan-perusahaan tersebut.

Kesimpulan

Terbentuknya tingkat gaji programmer yang rendah diakibatkan banyak faktor yang cukup kompleks, dengan berbagai pihak yang ikut bertanggung jawab di dalamnya.

I’ve found a bug! Who to blame?

Despite that blame culture serve no benefit to the company, many companies still have this culture. Moreover, it is stupider to put a blame for bugs happened in software. Simply said, that’s because bugs happen, and the possibility of a bug is close to infinite.

Many times, many parties responsible for bugs in production

Let’s say that we use the following SDLC: requirement, analysis, design, develop, test, implement, maintenance. Now let’s see which responsibility can be held in each phases for each parties.

Requirement

The requirement given by user is ambiguous, has multiple meaning or the worst, he/she is wrong when giving the requirement. Next, the meeting PIC (person in charge) is doing mistake during passing the requirement through the analyst and programmer.

Analysis

The analyst doing a mistake during interpreting the user requirement. The analyst is mistaken during communicating the analysis and requirement through the programmer.

Development

Many-many things can happen during development. Wrong logic condition, wrong parameter assignment, etc. In short, the code is wrong.

Testing

The test case is very lacking compared to the complexity of the project and environment deployed. The case is testing wrong things. The test case resulting in false positive.

Implementation

Incorrect publish parameter. Incorrect deployment tools configuration. Production environment not tested beforehand. Production environment (OS, etc) is different with testing environment, and the code has environment-dependencies. Worse if the publishing done manually.

Maintenance

Internal support team inserting data with format that is not tested (whitespace characters). Some script being executed without tested. No change management for software correction, which causing the developers can directly push file to server. Some maintenance activity (backup, index rebuilding) causing anomaly and incorrect results. User trying to break the system.User input data with unsupported format.

Other causes

Requirement change mid-development. Some requirement break / not compatible with other requirement. Development time being shortened to meet earlier shipping date. Natural disaster causing loss in development time, but no schedule adjustment.

Bugs caused by many factors

Despite code / logic error, many other things can cause bug to an application. For example:

  • compiler / interpreter error – very rare cases though
  • flawed server configuration / installation
  • OS-level bug
  • Bug caused by different configuration in different environment
  • Error caused by cosmic rays
  • Y2k error – year 2000 problem
  • Network-related error
  • Incorrect data / format
  • Not-printable characters input

And there are many-many more.

Conclusion – now, who I can blame for that?

It’s best to not blame anyone for bugs / error happened in a software. Entire team / company should take responsibility for the error (even user as well). What you need to do is, to find the root cause, fix the software and find a way so the same mistake / error won’t happen in the future.

A standard mouse, good for teaching though

Important factor when giving lesson

I get the idea for this article after reading Testivus on Test Coverage story. In this story, three programmers asked Testivus about proper percentage of test coverage. Testivus gives three different answer and every answer depends on skill level / knowledge and attitude of the programmer. The same can be applied to every lesson that you, or anyone when teaching.

Example

Let’s take a situation, where you are teaching newcomers about programming. First, you teach them about variable, data type then if-else, function and so on. You will try to arrange the topics and course material as easy and as non-technical as possible. Later on after several meeting, you can move to deeper and more technical topic.

Absolutely you won’t mention about interface, clean code, architecture, dependency injection, CQRS or any advanced-level topics during the first course. They don’t know what those topics are about. They won’t get anything beneficial from those topics. It is same as a programmer attending a seminar about newly founded medicine which can cure cancer, presented by researchers targeting senior doctors.

You don’t teach any advanced topics during first course for newcomers

Why so

Man 1: hey, YYMM’s stock is on golden cross today!
Man 2: Have you see the 60 days MACD? It haven’t touch the support yet!

Are you an investor? Or have you do stock once or twice? If you do, then you will know what the conversation above is about. Assuming that you don’t know anything about stock, what is your reaction when I tell you to buy a stock because it’s on golden cross today? What knowledge do you get from that?

Nothing. You don’t even know what a stock is about. You don’t even know about the stock basics yet. The basics is included as: stock unit, how to buy it, how to sell, how the price is formed, open/close/high/low price, closed market, closed time buy, etc. After that you need to learn about resistant and support, then graph, then you are approaching the more advanced concept such as fair value and reading quarterly financial statement.

Now let’s say that you already learned the basic, then suddenly you attend a seminar led by George Soros about how to do a 3 months projection of a stock value based on current financial statement. I guarantee that you either be confused and get nothing, or at max you only get the minimum value from it.

Now let’s say that instead of that seminar, you attend a local financial institute seminar about how to do cut loss and planning for cut loss. You already know the basics and that topic is not too far from the basic. You will understand what the seminar is about and get full benefit / knowledge from it.

When attending a wrong course, you will be confused and get nothing. However when attending a right one, you will understand it and get full benefit

The case in IT / Programming

“How to build an e-commerce with PHP, mysql and laravel for beginner”. When I ask for suggestion about what topic should I bring for newcomer, many colleague suggested that topic. Then as usual, I spend 15-30 minutes explaining why it doesn’t work. Every time.

This is also the basis for my decision to use javascript as programming language for newcomer. Weakly typed, interpreted, support procedural and multiplatform. They don’t need to do variable declaration, initialization, type casting (conversion still exists, though), directly run the code without compilation, and no need to learn about object oriented or classes and the likes. With this, I can teach how programming works and they can immediately learn about the concept of programming.

The software requirement is negligible. With a programmed environment, for example this jsfiddle: https://jsfiddle.net/fendy3002/1embueho/, someone can begin programming anywhere anytime. So far I only find one weakness and that is to receive input from user, you will need to learn html first. That’s some big sidetracking I must say.

I use javascript as programming language for newcomer because it is weakly typed, interpreted, support procedural and multiplatform

Conclusion

To ensure that the topic you bring in a course can be learned effectively and beneficial, you need to know the skill / knowledge level of said attendance.

 

Context Switching – what works for me

Context Switching

This article is a follow up to Pawel Brodzinski’s good article about context switching. On short note, let’s say that context switching happens when we are doing one project, then switching to another project. The tasks, information, data, code (context) are changing.

Context switching is not without cost, it consume brain power and usually need time for one developer to catch up to working condition after switching. So it is generally bad. However Brodzinski already mentioned the Zeigarnik Effect.

Our brains remember much better tasks that we haven’t finished and also have intrusive thoughts about that thing.

So we got 2 contradict situation. One where our brain is doing better when we are multitasking (switching context) and that the context switching / multitasking is costly. Let’s just say that the amount of multitask one can do will yield into diminishing return at one point. So how do we know the peak point of context switching’s benefit? Trial and error. The solution below works for me, and maybe also works for you.

My Solution

Limit to two tasks

For me, multi tasking comes with responsibility and pressure. More tasks assigned to you, more pressure and responsibility you hold. Which is why I think assigning two tasks at the same time is the best. Three is okay, but the third one must have very low priority over the other. More than three will cause queue time.

One long-running task and one short-running task

I experienced good performance when I am assigned with one project / task which is long-running (long deadline), and another which can be completed shortly / soon. That way, I can focus my work to the long duration one, then switch to the short-duration one when I get problems / stuck or simply bored.

Why not both short-duration or both long-duration tasks? I must say the mental effect comes here. A feel of achievement from clearing one task can help you boost your moods and performance. The mood boost will help when working the other one. That can only be achieved by doing two different-duration tasks.

Can focus the long duration work, then switch to the short-duration work when get problems

One higher priority and another lower priority task

Similar with before, this way I can focus the work with the higher priority one then switch to lower one when stuck. When both tasks are high priority, and you will feel very pressured. Otherwise, when both tasks are low priority, you will feel lazy / loose.

Do I feel the performance gain?

Yes it is. I don’t know whether it’s the same case with the other. However when I am stuck with a case/problem or need a long time analysis, usually I tried to distract myself from the task (usually by browsing which ended in seeing many cat pictures), or changing to other tasks. After some time, I will switch back to the problem with zero cache or memory in my mind about it, and thinking it from the start with different approach.

This way, when I have multiple tasks, I can distract myself with that other task, while both unconsciously thinking about the problem and forgetting the current not-working solution about the problem.

When I am stuck, I tried to distract myself and come back later with new approach

Conclusion

Two task, with both varies between priority and duration benefits me the most from context switching.

I’ve just realized that my web app is not keyboard friendly. How’s yours?

Visual FoxPro!

Today I’ve met a senior programmer. He used visual foxpro for his latest ERP system. Honestly I’m amazed with what kind of features that foxpro can provide and how good they are. Foxpro, really? That old not-popular programming language? Maybe that’s what you have in mind. But honestly, you’ll be amazed by how good Foxpro interact with database objects. Moreover, how fast the database is! Though it haven’t being tested over 50 users though.

I’m amazed at the features of foxpro!

So? Do we all move to foxpro all together? No, foxpro is good, but not in every aspect. One of the reason is that application structure is very tightly coupled with the data object, which is good for administrative tools but not for the other. I’m not using foxpro, so I can’t give more reason, and that topic is not what I want to discuss now.

It’s a desktop app!

I just want to shared that the visual foxpro that has been developed is desktop app. I must admit that no matter how good you are at web programming, you can’t defeat the UI functionality and keyboard-friendly functionality of desktop apps. There isn’t even safe cross browser hotkey that can be used in web. While in app, you can easily navigate using arrows, tabs, function keys (I’m pointing at you, F1-F12!), page up page down, control + keys, etc. Not to mention the responsiveness, and the functionality of one-page application (nah, ajax can’t even compete with it).

Web apps won’t win against desktop in UI and keyboard functionality

Man, I missed the desktop-based development time of my university time.

But that’s it. Desktop integrated system is losing popularity over year, as better web environment is emerging such as web socket, html5, css3, etc. But I must say that web apps will never beat desktop apps for transaction-intensive activities. No POS (point of sales) in hypermarkets using it.

Hypermarket using web-based POS? How slow will it be?

Do you imagine integrating barcode scanner with web apps? Do you imagine using mouse to choose which payment method? What will happen if they need to wait for respond after submitting, waiting for the payment change? That won’t do. We must back to our very first factor of application development: requirement. If they require it, then it must be done.

The very first factor of application development: requirement

So, we back to desktop app?

Yes for that particular activities. But how many of those transaction-intensive activities are there? There won’t be many of that kind transaction in today’s business. More often we need flexibility and portability more than keyboard shortcut. Let’s say reports, approvals, notes, attachments, all of them are better cross-browsers and portable. Employee self service (reimbursement, leave) is better online. Marketing will be more awesome online, since it can directly communicate to media via links and connections.

Of course we must ignore web-specialized features such as online trading, blog and social media though.

reports, approvals, notes, attachments, reimbursement, leave is better online

Conclusion

We go back to the very first rule of application development: requirement. If it is required to have intensive-transaction application or embedded devices (printer, barcode scanner), then use desktop. If not, then it’s better web since it’s easier to access and easier to maintain and publish. So, compare and plan before deciding the approach!