Development

Software Modification Cost

Dalam dunia IT, sering kita lihat perbedaan harga yang cukup signifikan antara vendor A dan vendor B dalam men-develop sebuah software. Ada beberapa faktor yang membedakan kualitas software yang dihasilkan dari vendor-vendor yang berbeda tersebut, seperti bug tracking, banyaknya bug, garansi support. Namun faktor yang akan dibahas di sini adalah seberapa mudah software yang sudah ada diubah / dimodifikasi.

Faktor kemudahan dalam mengubah software itu kita sebut saja sebagai software modification cost atau beban me-modifikasi software.

Bagaimana cara menghitung modification cost

Saat mendapatkan task untuk modifikasi, saya terbiasa untuk menghitung-hitung tingkat kesulitannya dan berapa waktu yang diperlukan. Pengalaman saya, waktu yang diperlukan untuk QA / testing adalah hampir 40-50 persen dari waktu development, bergantung dari kompleksitas dan bagusnya kode / arsitektur. Namun waktu untuk QA sering diacuhkan dan sering tidak dialokasikan.

Selain dari waktu yang diperlukan, setiap perubahan juga akan meningkatkan faktor resiko kesalahan, baik yang akan ditemukan dalam testing maupun tidak. Faktor resiko tersebut ada yang langsung berpengaruh ke finansial dan ada yang hanya mengesalkan user. Maka dari itu saya menganggap perhitungan modification cost sebagai:

development in hour + QA in hour + peningkatan resiko kesalahan

Bagaimana function / class mempengaruhi modification cost

Pertama, mari kita lihat potongan kode php berikut:

echo $isDone === true ? "yes" : "no";

Kode di atas mencetak tulisan “yes” bila variable $isDone bernilai true, dan no bila sebaliknya. Potongan kode di atas cukup sederhana, dan sering di copy-paste langsung di view. Semua terlihat baik dan indah.

Namun suatu hari, request untuk modifikasi datang. Tulisan yes dan no di atas perlu diubah menjadi ya dan tidak (dalam bahasa Indonesia). Seberapa sulit perubahan tersebut dilakukan? Katakan saja kode tersebut berada di 15 view yang berbeda. Maka modification cost menjadi 15 * n, di mana n adalah menit / detik untuk melakukan perubahan. Cost tersebut, belum dihitung / ditambah dengan kemungkinan adanya kode dalam view yang luput untuk diubah, atau perubahan salah sehingga menghasilkan syntax error.

Wrap in function

Sekarang untuk mengurangi modification cost tersebut, sang programmer membuat sebuah function untuk mencetak nilainya. Function tersebut di-define seperti berikut:

function boolToYesNo($value){
  return $isDone === true ? "yes" : "no";
}
echo boolToYesNo($isDone);

Bila ada request modifikasi seperti di atas, maka modification cost pada function tersebut bisa 15 kali lebih rendah dibandingkan dengan copy-paste kode di atas. Waktu yang diperlukan untuk QA dan tingkat kesalahan juga lebih rendah dari kode sebelumnya.

Lalu suatu hari, ada request modifikasi untuk mendukung multi-language. Lalu bila function di atas diubah untuk menerima kode bahasa yang dimaksud, maka kira-kira seperti berikut:

function boolToYesNo($value, $languagecode = "en"){
  if($languagecode == "en"){
    return $isDone === true ? "yes" : "no";
  }
  else if($languagecode == "id"){
    return $isDone === true ? "ya" : "tidak";
  }
}
echo boolToYesNo($isDone, $languagecode);

Modification cost-nya? Kembali sama seperti di awal, yaitu 15* menit / detik yang diperlukan + peningkatan resiko. Lalu bagaimana bila tulisan yang mau dicetak diawali dengan huruf besar (perfect case)? Modification cost nya tidak dapat ditekan. Maka dari itu sang programmer membuat class seperti berikut:

class BoolToYesNo{
  public function __construct($context = NULL){
    $this->context = (object)array_merge(["languagecode" => "en"], (array)$context);
    $this->languages = [
      "en" => [true => "yes", false => "no"],
      "id" => [true => "ya", false => "tidak"]
    ];
  }
  private $context;
  private $languages;
  public function print($value, $options = NULL){
    $options = (object)array_merge((array)$options, ["case" => "lower"]);
    if($options->case == "upper"){ return strtoupper($this->languages[$this->context->languagecode][$value]); }
    else if($options->case == "lower"){ return $this->languages[$this->context->languagecode][$value]; }
  }
}

Wah untuk mencetak yes dan no saja kodenya rumit begitu. Bila menghitung development cost di awal, sangat tinggi. Namun modification cost-nya sangat rendah.

Conclusion

Mengurangi software modification cost tidak mudah, dan umumnya ada trade-off (pertukaran) antara initial development time dengan modification cost. Pengalaman dalam pemograman dan requirement yang semakin jelas di awal dapat membantu mengurangi software modification cost.

Sedikit banyak, topik ini juga menyangkut dalam technical debt.

skill

Saya programmer dengan skill tinggi, saya pasti bisa sukses – Part 2

Sebelumnya dalam artikel dengan judul yang sama, saya pernah menjelaskan bagaimana soft skill-soft skill di luar programming, terutama yang berkaitan dengan organisasi dan komunikasi, dapat membawa manfaat tambahan bagi programmer. Kali ini, saya akan coba membahas situasi-situasi yang ternyata kebalikannya, di mana soft skill tidak terlalu bermanfaat bagi programmer.

Startup / perusahaan kecil dengan CEO dan CTO yang kuat

Startup / perusahaan kecil umumnya didirikan oleh 2 founder, yaitu CEO (Chief Executive Officer) dan CTO (Chief Technology Officer). Untuk beberapa startup yang foundernya cuma sendiri, biasanya memegang peran ganda, yaitu CEO dan CTO secara bersamaan.

CEO mengurus semua aspek bisnis non-technical, seperti requirement, marketing, funding, networking, mencari client dan aspek-aspek bisnis non-technical IT (seperti merekrut driver di gojek). Sementara CTO mengurus semua aspek technical IT, seperti server, arsitektur, bahasa pemograman, framework dan lainnya.

CEO yang berpengalaman akan dapat men-handle aspek-aspek non-technical IT, terutama yang berurusan dengan user / client. Untuk hal-hal technical IT yang memerlukan keterlibatan user, maka CTO dapat me-handle nya. Karena sudah di-handle oleh CEO dan CTO, maka programmer hanya perlu mengerjakan requirement dan mengikuti arahan dari CTO (atau project manager bila ada).

Karena perusahaan kecil tidak mampu mempekerjakan banyak karyawan, maka semakin tinggi skill programmer dan analisanya, maka semakin diminati. Soft skill yang diperlukan hanya komunikasi umum (sehari-hari) dan sedikit kemampuan analisis, agar dapat memahami requirement dan arahan. Karena kemungkinan bagi programmer untuk berhubungan dengan user kecil, maka skill negosiasi dan komunikasi yang tinggi tidak terlalu bermanfaat.

Developing non-business application

Menurut saya, applikasi dapat dibagi menjadi 2 dari aspek penggunaan. Pertama adalah tools. yang fungsi applikasinya lebih umum, dapat digunakan oleh lebih banyak user, dan tidak terlalu terikat pada bisnis tertentu. Contohnya seperti photoshop, notepad bahkan database oracle. Sementara applikasi lainnya adalah implementation, di mana penggunaannya spesifik untuk satu unit bisnis tertentu, dan sangat erat dengan proses bisnis si pengguna. Contohnya applikasi POS, accounting, dll. Tentu saja applikasi tidak dapat dibedakan seperti hitam dan putih. Bisa saja sebuah applikasi memiliki karakteristik keduanya. Contohnya seperti cloud accounting.

Sebagai programmer, semakin applikasi yang di-develop ke arah tools, maka semakin sedikit soft skill yang dibutuhkan. Begitu pula sebaliknya, semakin applikasi yang di develop mengarah ke implementation, maka semakin banyak soft skill yang dibutuhkan. Hal ini karena programmer mengembangkan applikasi yang langsung di-request oleh user, maka keterlibatan user dalam pengembangan menjadi lebih tinggi. Semakin applikasi yang di-develop mengarah ke tools, maka teknologi yang diperlukan dan kompleksitasnya akan semakin tinggi (lebih tinggi dari implementation), sehingga daripada soft skill, skill technical yang tinggi jauh lebih diperlukan.

Kesimpulan

Dalam beberapa kondisi, soft skill akan sangat membantu programmer di dunia kerja dan meraih sukses. Namun dalam kondisi lainnya, skill technical dari programmer dapat menjadi satu-satunya parameter penentu keberhasilan seseorang. Mengetahui ini, maka programmer dapat menentukan langkah-langkah yang dapat diambil untuk mengembangkan diri dan karir.

Agile manifesto

Agile is dead! Really?

Dave Thomas, one among the founders of agile manifesto says so in his post blog, “Agile is Dead (Long Live Agility)“. And lately I have seen a blog post “Agile is Dead, Long Live Continuous Delivery“. Is agile really die and need to be changed? Is Continuous Delivery a replacement of agile?

Background

In his blog post, Dave Thomas indeed say that the word “agile” need to be killed down. But why? That’s because the word “agile” and the “agile” concept has been misguided and become a tool, a process and being industrialized. As Dave said in his blog post:

Once the Manifesto became popular, the word agile became a magnet for anyone with points to espouse, hours to bill, or products to sell. It became a marketing term, coopted to improve sales in the same way that words such as eco and natural are. A word that is abused in this way becomes useless—it stops having meaning as it transitions into a brand.

Get it? The current “agile” is swayed from it’s original meaning and objective. It has become “marketing term”.

Agile is guidance, not methodology

Let’s see what we have at agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The first point itself state that agile is not a methodology. The first point of manifesto states that you need to prefer to individuals and interactions over process and tools. If the agile you know focus to methodology and process, it already violates the first manifesto. Agile is just a guidance, to help you (and the team / company) to find the best process and tools for your development activity.

Even scrum, one of the most popular agile adaptation is still only a guidance or development framework. As stated,

“Langkah pertama yang perlu dilakukan untuk dapat memahami apa itu Scrum adalah dengan tidak mengaitkannya dengan sebuah metodologi apa pun juga karena Scrum hanya sebuah kerangka kerja dalam mengembangkan produk kompleks seperti software.” – Partogi, Joshua (2015) Manajemen Modern dengan Scrum, Yogyakarta, penerbit ANDI.

As translated: the first step that need to be done to able to understand what is Scrum is to not connect it with any methodology because Scrum is only a framework to develop complex product like software.

The marketing term agile / scrum

Today’s agile / scrum meaning varies and very misleading. The most popular misleading scrum is that it has “morning meeting” and “no documentation”. “If we have morning meeting, we already do agile”. It’s very misleading. The sole focus to process is already swayed away from agile manifesto.

Now let’s say that in your company you have one PM that manage 3 teams. Each team is doing project in different area. How can you do morning meeting with those setup? Evening e-mail daily reporting is enough for project tracking with those setup.

Continuous delivery is the next agile!

First, continuous delivery is not directly contradict with agile. Agile does not state that you need to develop a non-ready program. Moreover, agile state that you need to “responding to change over following a plan”, in which more or less is aligned with continuous delivery. And as stated above, agile is a guidance, not a methodology. We can say that continuous delivery is a more advanced implementation for agile.

Then it is the next agile! Hold on. As stated in agile manifesto, individuals and interactions over processes and tools, you cannot directly implement continuous delivery (CD) and hoping for everything to work well. You still need to consider the capability of team, servers, workflows, division, business decision. And the most important, the kind of software you make. CD relies heavily on good QA, test unit and continuous integration infrastructure. If you don’t have those matured, it’s risky to implement it.

Conclusion

Agile is not dead. It’s just that the term “agile” itself has swayed from it’s original meaning. It is a guidance and not methodology. It’s implementation may be evolved and improved. Continuous delivery is a good methodology and can align well with agile.