Teknik Borç - Technical Debt

Teknik Borç Nedir
Açıklaması şöyle. Yazılımın yaşamasını zorlaştıran engeller anlamına gelir. Maintainability yazısına bakabilirsiniz.

In simple words, technical debt is the bad engineering practice used intentionally or unintentionally while developing software which leads to adding up of complications to the existing code base which impacts overall maintainability and quality of the code. There could be innumerable reasons for such practices at the team or organizational level.

Teknik Borç Nasıl Ortaya Çıkar
Öncelikle teknik borç her zaman olacaktır. Çünkü bir yazılımı yaparken ilk başta her şeyi göremeyiz. Dolayısıyla bir sistem mutlaka bir miktar borç ile gelir. Açıklaması şöyle.

Imagine, you want to start a manufacturing business. In order to make money, you need machines. But in order to buy machines, you need money! How do you solve this dilemma? The answer is: you take out a loan, use that money to buy machines, use those machines to make money, use that money to pay back the loan.

In your case, you have similar problem: in order to implement the system, you need a design. But in order to know whether the design is good, you need to implement the system.

How do you solve this? You take on Technical Debt. You design the system as good as you can with the knowledge you have right now. Then you implement it. Now, you see some problems with the design.

This difference in knowledge between what you learned about the design while implementing it, and what you knew when you started the design, that is the loan you took. That is your Technical Debt.

And just like real debt, if you don't pay it down, it will accrue interest, and slow you down. So, you need to refactor your system, and the basic idea of refactoring is to make your system look like as if you had known from the beginning what the best design would be.

That is the fundamental idea behind Technical Debt, and the fundamental idea behind Refactoring.

Burada kötü olan şey borcun olması değil, borcun ödenmemesidir. Açıklaması şöyle.

Technical Debt is something that accumulates over a period and at some point, it could render an application unviable to maintain. It is like a time bomb which if not diffused soon could cause serious customer repercussions and financial damages to an organization.

Teknik Borç Ölçülebilir Mi ?

Açıklaması şöyle.

There are numerous tools that help to measure and track tech debt. Technical debt calculation is based on different technical debt metrics such as code complexity, code duplication, test coverage, coding rules violations and lack of documentation.

Belki şu ölçümler de faydalı olabilir

- Lead time: the average amount of time it takes from the time code is checked in to the version control system to the point in time where it is deployed to production (lower is better);

- Deployment frequency: the number of times deploys to production occur in a time period (higher is better);

- Mean time to restore (MTTR): how long it takes to resolve or rollback an error in production (lower is better);

- Change fail percentage: what percentage of changes to production (software releases and configuration changes) fail (lower is better).

Teknik Borç Ölçümü İçin Kullanılan Mean Time to Restore İçin Eleştiriler

Açıklaması şöyle

“Mean time to X” is a common term used to describe how long, on average, a particular milestone takes to achieve in incident response. There’s mean time to detect, acknowledge, mitigate, etc. And then there’s the elusive “mean time to recover,” also known as “MTTR.”  

MTTR, a hotly debated acronym and concept, measures how long it takes to resolve an incident on average. The problem with MTTR, though, is that it doesn’t matter.

MTTR is an excruciatingly flawed metric that relies on comparing fundamentally different incidents with different contributing factors to measure whether a team improves its incident response. It’s like putting together a Volkswagen Jetta, a BMW M5, and a Lamborghini on a race track and saying the average of cars is 80mph an hour. The brutal reality is that incidents will always vary in how long they take to resolve, so attempting to average different incidents of varying severities across a complex system will yield a number that has a high degree of variance as well.

Mean Time to Restore Yerine Mean Time to Retro

Buradaki amaç insan hafızasının çabuk unutmasından dolayı, sıkıntı çözümlendikten sonra mümkün olduğunca çabuk bir Retro düzenlemek. Açıklaması şöyle

The formula to calculate mean time to retro is almost as simple as they come:

1. Note when you officially resolved the incident (resolution timestamp)

2. Note when you have a completed retrospective (publish timestamp)

3. Subtract the resolution time from the retro completed time to get the duration of how long the “retro gap” was

Teknik Borç Emareleri
- Geliştirme Hızının Yavaşlaması. @Vincent Déniel'e ait bir karikatür şöyle :)

- Yeni özelliklerin sürekli yeni hatalara yol açması
- Sürekli performans problemleri ve yazılımın göçmesi

gibi maddeler sıralanabilir

Sebepleri
- Geliştirme Ekibinin
- Ürün Sahibinin,
- Kurumun
veya bunların karışımının yüzünden Teknik Borç oluşabilir.

Yani sadece geliştirme ekibinin çözmesi gereken bir engel değildir. Açıklaması şöyle.

With the name ‘technical’ debt, it is often perceived that reducing technical debt is the sole responsibility of the developers. Of course, developers play a key role in refactoring code and reducing technical debt. But refactoring is not always restricted to only the code. Many other groups have to play their related roles to enable refactoring and reduction of technical debt.

Geliştirme Ekibinin Hataları
1. Kaçınılmaz Yanlış Tasarım
Açıklaması şöyle.

Your design turned out to be flawed and you can’t add new features quickly and easily but it wasn’t your fault or decision. In this case, we’re talking about accidental or unavoidable tech debt.

Bu başlığa  Logical Debt tanımını eklemek te mümkün. Çözülmesi gereken problem (business problem) tam olarak tanımlanmıyor veya tanımlanamıyor. Bu durumda geliştirme ekibi yazılımı bir sürü genel geçer servisi bir araya getirerek her durum ve senaryoyu yerine getirmeye çalışan bir şey halinde tasarlıyor.

2. Bilerek Hızlı Kodlama
Açıklaması şöyle.

The second type of technical debt is deliberate debt that appears as a result of a well-considered decision. Even if the team understands that there is a right way to write the code and the fast way to write the code it may go with the second one. Often. it makes sense – as in the case with startups aimed at delivering their products to market very quickly to outpace their competitors.

Faydalı geliştirme kurallarından ödün verme, eğer şirket kültürü haline gelirse teknik borcu ödemek imkansız bile olabilir. Açıklaması şöyle

Speaking from the experience of a company whose main workforce was external consultants, the good practice devs simply leave or become disenfranchised bad practice devs. The (initial) bad practice devs stick around. This perpetuates the imbalance of the bad practice devs having seniority over the good practice devs.

At this point, bad practice has become an endemic company culture. It is reinforced from all sides (including the sales department in case of dev companies), and any good practice suggestion that pops up is often drowned out by the popular support for bad practice, combined with management's intolerance for longer deadlines.

Burada kodun çürümesi kavramı (code rot) da benzer şeyler söylüyor. Açıklaması şöyle.

As software developers, we are non-stop fighting the never ending recurring battle against "code rot". Code rot often implies that our Program Manager asks us for a feature, and we sneak in an additional "if" statement in one method, and a couple of "while" statements in another method, and our program manager is pleased with the effect. Slowly over time of course, the effect this approach has on our code, is less cohesion, clarity, and readability, in our classes, methods, and modules - And our code slowly mutates over time to become "a big ball of mud", until it reaches that point where it's no longer possible to maintain.

3. Yetersiz Tecrübe

Açıklaması şöyle.

Finally, the third type of tech debt refers to situations when developers didn’t have enough skills or experience to follow the best specific practice that leads to really bad code. The bad code can also appear when developers didn’t take enough time and effort to understand the system they are working with, miss things or vice versa perform too many changes.

Teknik Borcu Ödememe Riskini Alma

Bazen şirketler teknik borcu ödememe riskini alırlar. Açıklaması şöyle

It‘s a question of risk management:

...

In other words, with large legacy spaghetti code bases, refactoring creates a high risk of breaking something that worked before, and the impact of this risk cannot be reduced with automated tests. The significant risk of refactoring simply outweighs refactoring benefits in this case.

Mesela kodun kırılgan olduğunu herkes bilir, refactoring için yeterince unit test yoktur. O zaman kodu elleme denilir. Aslında şirket yeterlince şanslıysa, bu koda gerçekten ya hiç dokunulmaz ya da çok az dokunulur. Yani risk alınır. Açıklaması şöyle. 

The code isn't covered by unit tests, and it's too brittle to refactor without unit tests to cover it, so instead of doing it the right way and spending the money to write unit tests and refactor, the companies simply say "Do not touch it." It's not necessarily a bad strategy; if the code works, and it's never touched again, then it's never going to break, is it? (fingers crossed).

Risk almaya iten bir diğer konuysa, teknik borcu ödemenin maliyetini ölçememek. Açıklaması şöyle

One reason is it's really difficult to measure the loss of productivity the messy code is causing, and difficult to estimate the work it will take to clean it properly and fix any regressions.

Teknik Borcu Gizlice Ödeme

Bazen Teknik Borç ödeme işlemini geliştirme ekibi maalesef gizli gizli yapmak zorunda kalıyor. Açıklaması şöyle.

1. If you work in a company that doesn't place any value in paying down technical debt, you may have no choice but to do unticketed work.

2. Stakeholders are generally not qualified to make decisions about this kind of work.

3. Include unticketed work as part of your ticket estimation process.

Diğer Bazı Fikirler

- Geliştirme Ekibi kodu sürekli bulduğundan daha temiz bir halde bırakırsa iyi olur. Örneğin bir kütüphane sürümünü yükseltmek bile teknik borç ödeme olarak kabul edilebilir.

- Ürün Sahibi çok sık fikir değiştirmemelidir
- Kurum, zaman baskısını kontrol altında tutabilmelidir.