Quality

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.

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.

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.

Custom apps IT Solution vs Product Developer

Last night I was being interviewed at one IT solution. The interview goes normal, with questions technically and personally. However I feel that the topic of question is different from the last time I had interview (around 2 weeks ago). Long story short, this interview asks more about technical skills and ability of using tools, while at the last interview the topic is leaning more to design, architecture, security and performance.

Custom IT solution is doing the hard work

I’m sorry to say and if this phrase is very harsh to you, but if you are working at custom IT solution, it means that you are being expected to do hard works. The client does not expecting you a good quality product. They expect you to work under their order and develop what they want. You are being valued by how hard you work, not by the product you produced (well the product also being valued, but not as much as your hard work).

I may sound narrow minded, but that is what happen in majority of custom IT Solution companies. Maybe not all (if any), but at least most of them do like that, at least at my country. And no, I don’t say that the practice is bad, or delivered bad-quality product is a sin for those company. It is just a nature of the company, enhanced by clueless leader about IT world. Moreover, the business nature of custom IT solution tend to bring the company into that path.

Faster delivery = more revenue

It is true for all IT solution that faster delivery = more revenue, because faster delivery means more project to handle and it means more income. However the way they do to improve delivery time is wrong. Usually they cut testing time and encourage overtime (worse, unpaid). It resulting in fast, low quality product. Fast, cheap, good, pick two. Usually they pick the fast and cheap one.

Less self improvement

Self improvement (better design, better framework, better developed component, code review, test units, etc) is third priority inside those company. Product delivery takes number one, while customer support takes second. It is because self improvement is seen as expense (manpower and time) and has invisible/indirect benefit. Training and conference does not fall into self improvement though, because it is tightly required to development. Try to learn kaizen.

Even if the company apply self-improvement, it will be driven and handled from top levels, rendering your involvement useless.

Bad documentation

Because you can support and train the customer directly in such big time span (morning to night), it makes documentation less required. Moreover writing a good documentation, and update it every changes will require big effort.

No idea will bloom

Any sprouting idea won’t bloom. Because everything is made by customer request, the company does not need good, fresh idea. They just need a good worker and constructor. Moreover, idea will be seen as hindrance, costly and too much effort to apply.

What about product developer?

If the company developed a product and live by it, the mind set will be different. I don’t say all product developer like that, but at least the successful one does.

Higher quality = more revenue & less cost

Am I drunk that I write something like that? No, I’m not drunk. In product developer company, higher quality product will increase customer satisfaction, resulting in good testimony and recommendation, then resulting in increased sales, means more revenue.

But isn’t higher quality means longer development time and higher cost? Why it can become less cost? It is indeed higher in short time period. However because you will maintain the product for long time (years, at least), fewer bugs and good administration system will help you cutting the cost. The longer the product being maintained, the higher the cost is saved.

Documentation!

A good product must have a good manual, and documented. The better the documentation is, the lesser effort needed to support the customer. It may not apply in all case, but at least some are. The more customer using this product, the more documentation is needed.

Idea!

Idea is everything for the lifetime of the product. A stagnant product lack of new features will become obsolete, and lose competition with new products. The terms is coined as product lifecycle. A good idea from the company member has higher chance to be applied.

Conclusion

The business flow of custom IT solution and product developer is different. Their revenue source and cost is also different. How they are managing the development and support is following each business process. A custom IT solution focus more on development time, while product developer focus more into quality. Not every company in each type follow the same rules, There is also custom IT solution who focus on quality, and product developer who focus on development time.

Quality : Project Manager – Decision Maker

This is an extended / deep down session for Quality : Project Manager series.

Decision Maker, why a project manager (or to be precise, all manager) need it. This session applied to almost all manager-level, while in this article, I write project manager as representation.

Most of the time, a project manager must lead their subordinates to face problems and tasks. There are almost infinite solutions that can be taken to do those problems and tasks. A project manager must make decisions about those solutions and choose the best one. Making a good decisions is another discussion and problem out there, able to make one or not at all is the problem here.

An indecisive manager is bad manager. If in your company have manager with this quality, fire them immediately. They bring more harm than good.

A decision, after being made by the manager, will be executed by the staff or his/her subordinates. Now if the manager does not make the decision, what can go wrong?

The Decision Making Will be Done at Lower Level

The lower level I mean here is supervisor level or even staff level. I can imagine that almost all the time, those indecisive manager will only order their subordinates to solve the problem, without giving directions or clear instruction for those orders.

Those unclear instructions will resulting in more decisions that their subordinates must make. More indecisive the manager and unclear the order is, the more decisions that the subordinate must make. Then what? Is it bad? Before I continue, I want to emphasize that when the decision is made at supervisor / staff level, the decision will be split into smaller decisions, and more people that will make the decisions.

More People Making Decision = More Unaligned the Overall Action

Let’s say that we have a naval ship, frigate class (well, I like the Golden Age of Piracy theme) with 80 crews, one captain and 10 masters (supervisor levels). The captain is given a task to exterminate the notorious pirates at Tortuga (Pirates of Carribean, ahoy!). He will set sail from Port Royal.

Imagine that the captain say to the sailing master (navigator) and other masters like this: “we need to exterminate the pirates at Tortuga”. How will the masters do their job? Each of them will have different plans in mind. For example: the boatswine want to direct the ship 100 km (~62 miles) from Tortuga for restocking, while the quartermaster want the ship to port nearer to Tortuga so they can gain information about said pirates, and sailing master now begin to wonder whether the weather is good for sailing.

It will be worse if the sailing master said this to the navigation crew: “we will go to Tortuga to exterminate some pirates”. Among dozens of sailor crews, there will be some that want to sail to the west, and some to the northwest, and they won’t make much progress.

What is the Result from Unaligned Action

Now that the crews are confused. That can resulted in delayed actions due to need of plan reconciliation between masters and crews. That delayed actions costs supply, money, and threaten the mission. It will be worse later when the preparation is not good, the supply is badly managed, they run into bad weathers, they are ambushed by pirates in the trip, etc. That can costs them live and the success rate for mission is significantly lower.

What if?

Now only if the captain said something like this: “We need to exterminate pirates at Tortuga. in one week, we will set sail to port X, 100 km (~62 miles) from Tortuga. We will take the northwest route, a safest one that passed Y bay. We want to minimize the encounter with pirate during the trip. From there, after 3 days of resupply, we will continue to move to port K, 5 km (~3 miles) from Tortuga. We will use one week for resupply, learn the weather, topography and gathering information about the pirates. Then after deciding which attacking strategy we will use, we attack them”.

We can see from the second instruction that the captain give very clear instruction to the crews. Now the crews know what they need to do and each master can make plans to support the original plans made by captain. Immediately after, they can discuss between each other master about the more in-depth technical plan, then later being completed as masterplan, that will be used as guidance for the mission. Each masters can handle their own team and each teams can act according to plan. The success rate for mission is significantly higher.

The same decision is also needed when encounter with emergency situation, such as sudden bad weather and ambushed by pirates. If the captain is indecisive with his decision, the entire crew will be in chaos.

Conclusion

Indecisive manager can threaten the success rate of a task / mission. Usually even though the task is completed, it will costs more time and financially as well. A clear decision and instruction will resulting in more responsive subordinate and increasing mission success rate. As a note, a manager that like to change decision that his/her has made is not different that the indecisive one. The master plan that has been discussed before can change, resulting in extra cost for subordinates to re-align with the new plan.

Quality : Project Manager

This will become a first part of Quality series, a series where I will talk about quality about something (in information technology world) from my point of view. I try to be as objective as I can but cannot denied that this series will have many subjective aspects from me.

Now I’d like to talk about quality of a project manager.

Long story short, I have worked under some project managers. However I only have worked with 2 project managers for a long time, and the others are short-terms. The last and current project manager that I’ve worked with for a long term is Mr. Ivan Kristanto (well, his name is better in English). He is the one that makes me want to discuss about a quality of project manager. And within my qualification, he is a good one in my opinion.

Let’s see what can my point of view details about the quality of a project manager.

Decision Maker

They need to make decisions for many aspects. If they are inconsistent / indecisive, it will only bring troubles for their subordinates.

Good Communicator

Hey need to communicate their plan, strategy and design. To do so they need to have a good communication skill so they can describe those things very well and their subordinates can understand what they mean.

Technical Knowledge

If the company has a solutions architect, this criteria placed for them. However most of the time, project manager is also same with solutions architect itself.

A project manager need to know the current technology and their technical use. The technical knowledge needed to be possessed by project manager does not means the deep down technical details that programmers know. It should only be about the general technical knowledge like web services, batch processing, scheduled job, etc. With these knowledge in their hands, they can decide which approach / design that will be the best for the system.

Projects Knowledge

A project manager is responsible about the project that they are taking charge. They not need to understand the project deep down to technical programming details, It is more into the business flows and rules.Because they are responsible to make plans for changing the project, they need to know what impact will be happen when the change request being applied, is it compatible with the current process, will there need any data conversion, etc. When things get out of control from original planning, the project manager will always be one who will be asked for help. If they don’t know the flow of project deep down, all of us are gonna get into trouble.

Workforce Knowledge

Project managers should know how good their workforce are. With knowing how good their workforce, they can make more accurate plans and schedule. They can also know whether one task can be done with their workforce or not. As well as the quality delivered.

Test Supervisor

In order to ensure a change will break or cause problem in other places, the change should be tested. Usually, there should be several test cases that must be passed to ensure the quality of the change. The responsibility for whether a change will cause problem or break is placed on project manager, so it is logical if the responsible to supervise or review the test results are held by project manager.

Scheduling Ability

They need to make yearly planning and milestones. If things go south, usually they need to re-adjust some of the plan so that the change will not become very different with current plan. Without this ability, the company cannot decide clear goals and at the same time will bring much overworks onto the developer.

Budgeting Ability

I don’t know much about how important for a project manager to manage budget. However, as we all know, they are responsible to handle the upcoming projects, workforce and timeline, as well as the hardware and licenses required. So a direct requirement or not, a project manager will need budgeting ability as well.

Conclusion

Rather than having strong technical skill at computer programming, they need more abilities at the soft side and management skill, while still maintaining their general knowledge about technology. Moreover they also need to understand which projects that they are responsible to, and understand the flow of it.