Technical debt là một ẩn dụ đôi khi được dùng trong ngành công nghệ phần mềm (CNPM), và là ẩn dụ đúng nhất cho thực trạng CNPM Việt Nam hiện tại. Phát triển phần mềm cũng như mọi công việc kinh doanh khác, về bản chất giống việc vay nợ, tức hiệu suất sinh lời phải đủ để trả lãi và quay vòng vốn trong một khoảng thời gian nhất định. Dĩ nhiên các yếu tố kỹ thuật khó lòng có thể được định lượng như tiền bạc, nhưng theo một nghĩa nào đó, nếu tỉ lệ các vấn đề được giải quyết thấp hơn so với tỉ lệ các vấn đề phát sinh, thì điều đó có nghĩa là dự án đang “tăng trưởng âm”. Tuy mượn một thuật ngữ từ lĩnh vực kinh tế, song “nợ kỹ thuật” thuần túy đề cập các vấn đề kỹ thuật như được trình bày sau đây:

NỢ LOẠI I

Đây đơn thuần là sự yếu kém về khả năng kỹ thuật và khả năng hiểu biết làm chủ công nghệ. Sự yếu kém này gồm nhiều dạng:

Kỹ năng cơ bản: có lần một senior engineer có 6 năm kinh nghiệm hỏi tôi về một khai báo C++ như sau (nằm trong file .cpp):

Sau 1 phút xem xét vấn đề, tôi hiểu ngay là người này không biết cách khai báo “static member variable” trong một “C++ class”, anh ta nghĩ nó cũng giống Java, chỉ cần khai báo trong định nghĩa class (file .h) là đủ.

Khả năng am hiểu công nghệ: một lần khác, một technical manager trình bày với tôi về 3D, OpenGL… anh ta nói rất nhiều về các khái niệm, thuật ngữ, danh sách dài các API. Nhưng chỉ sau một vài câu hỏi, tôi biết ngay người này không hiểu cách thức hoạt động cơ bản của một 3D engine, chưa nói đến các chi tiết phức tạp của một 3D driver. Mãi 4 tháng sau đó, sau một quá trình mày mò, anh ta mới bắt đầu hiểu ra những yếu tố đơn giản như: các hàm vẽ 3D không làm việc cùng một cách như các hàm vẽ 2D.

Sự yếu kém của các coder Việt nam tập trung nhiều vào nhóm Nợ loại 1. Những kỹ năng cơ bản cần phải được đào tạo thật kỹ, không phải chỉ là lý thuyết mà còn là các kỹ thuật, kỹ xảo ứng dụng thực tế. Nó giống như một người nói về kiếm, dĩ nhiên anh ta có thể nói về các “kiếm chiêu”, “kiếm pháp” anh ta học (đọc) được ở đâu đó. Nhưng điều này hoàn toàn khác với chuyện anh ta có thể dùng kiếm để chiến thắng những đối thủ (dự án) khó khăn, sừng sỏ!

Yếu kém về kỹ năng cơ bản kéo dài thời gian thực hiện những feature nhỏ, làm không đúng cách khiến phải làm đi làm lại nhiều lần. Tôi đã thấy một người implement một UI’s button: đơn giản chỉ là vẽ một cái nút với 1 dòng text & image. Anh ta không thực sự hiểu nó làm việc như thế nào, anh ta copy code từ đâu đó. Có thể các bạn không tin nhưng đó là sự thật, cái button được sửa đi sửa lại suốt 6 tháng mà vẫn chưa hoạt động đúng!

Sự yếu kém trong hiểu biết công nghệ cơ bản dẫn đến nhiều hệ quả nghiêm trọng hơn: định hướng sai, không hiểu các yêu cầu hợp lý và không nhận ra những yêu cầu phi lý của khách hàng, phí phạm tài nguyên cho những bước đi sai lầm. Hậu quả nhẹ nhàng nhất là: chỉ giải quyết được vấn đề trong một số tình huống phiến diện, thiếu bài bản. Nhưng thường thì hậu quả không tốt đến thế: làm sai lệch các hiểu biết chung của dự án, sử dụng công cụ, công nghệ không đúng chỗ, đặt ra những mục tiêu không tưởng, không có thật.

NỢ LOẠI II

Là những quyết định sai lầm (về kỹ thuật hay quản lý) dưới các áp lực từ phía kinh doanh hoặc từ những độ đo, cách đánh giá không phản ánh sự thật, duy ý chí.

Một ví dụ nhỏ: sau khi định hướng, khung ứng dụng được dựng lên trên nền một “3D test driver”. Bản thân driver là một “school project” có cải tiến chút ít, bản thân ứng dụng được viết trên một số giả định về các khả năng mà driver và hardware có thể cung cấp. Sau khi test, ứng dụng không đạt yêu cầu, và do đó quyết định optimization được đưa ra: chúng ta biết việc này ảnh hưởng đến kiến trúc cơ bản và lâu dài của software nhưng trước hết nó phải pass được 1 số measures nhất định!

Dĩ nhiên người có kinh nghiệm sẽ hiểu ngay là các độ đo đặt không đúng chỗ: driver và application mới chỉ là những code đơn giản, khó lòng có thể optimize nhiều, hardware 2D cũ hoàn toàn không đáp ứng, thậm chí là không tương thích dù là trong concept với các yêu cầu 3D mới. Và cũng không khó khăn để nhận ra: dường như với tác giả cái “3D driver” này, đây mới là lần đầu tiên ông ta thử nghiệm các kỹ thuật 3D, dĩ nhiên các concepts “bài bản” vừa học được đều rất đẹp cho đến khi người ta biết rằng 1 “real world project” hoàn toàn khác 1 “school project”.

KẾT LUẬN

Những món nợ kỹ thuật dù lớn, dù nhỏ đều góp phần ảnh hưởng tới hiệu suất và sự thành bại của dự án. Tất cả đều có chung nguyên nhân: chất lượng nguồn nhân lực! Các thành viên cần phải được chuẩn bị (kiến thức & kinh nghiệm) cho vấn đề mình đang giải quyết, từ khâu design đến coding, cho đến các scopes & milestones của dự án. Trong một dự án nhiều người, nhiều giai đoạn, tất cả những món nợ này được tích lũy theo cấp số nhân: sửa sai trên những code sai của những định hướng sai… và kết quả là lãi mẹ đẻ lãi con và nợ trở thành không trả nổi.

Over the years in our software community, I’ve seen a lot of dogmas, myths and lies that spread like ‘cholera’. That only reflects the fact that many programmers just repeat like parrots what they ‘learned’ from school, news, books… without their own justification, and to some extent, reflect their lacking of experiences. A good engineer should, at least, have some abilities to judge the pros and cons, weak points and strong points, when to use, and when not to use a method, a language or a technology.

Design first, then code!

The principle is, in general, not wrong. However, pragmatically, a software’s final structure, architecture… is not achievable as product of an immediate thought or a single design cycle. In most cases, the “first design” is certainly not the correct one. It’s not in a deterministic process that we can build software, complex product would always requires a lot of trial and fail. And from my experiences, good designs are sustainable solutions after a tedious process of experiments to eliminate wrong directions. We need coders of strong analysis and experimental skills rather than the “evangelic designers”!

Where are the documents?

We are going to make clear distinction: do we need coders who really understand what they are doing, or we just need some paper to present to customers? In countless cases did I see that coders do not understanding what they are doing: they don’t understand a feature, they don’t know how to archive that, they are unable to judge the pros and cons, they just mechanically copy and paste code from somewhere. Documents only provide rough, general views on the matters. If you’re going to mention about a static-web-page project, I would agree that document is something. But if you’re mentioning system programming, it’s the code that is the document!

Poor skills and wrong knowledges

This is simply put: countless! Just to name a few:

Poor skills: once, a coder being asked to fix a “null pointer exception”. What he did is adding a “if (pointer != NULL)” line into the code. It’s not fixing, it’s just hiding, fixing is find out why the pointer is NULL, not prevent it from being executed! Another time, another coder, getting frustrated under a crash situation, place a “try… catch” around the buggy code segment. This is again, not fixing, with this way of hiding, we’re just going to accumulate faultinesses until the software crashes silently for no reasons!

Object oriented programming rules: OOP is more beautiful in theory than in practice. OOP provides a nice way for modeling, but it come at costs: bloating code. It is not until the project grows above 1M LOC that OOP become a burden, that we would need to do the “functional decomposition” optimization tasks. It’s the execution (functional) tree that decides performance, not the inheritance tree that obscures runtime characteristics!

Design pattern rules: this is again, not true! I agree that patterns reflect some good coding practices, but software could never be built from the so call “patterns” (there hasn’t been any such proven process). I really don’t understand what is a “singleton” if it’s essentially (in C/C++ syntax) a static variable, I also don’t understand what we need from a “factory” if it’s essentially a “switch… case” structure!?

Management myths

Managers tend to forget what they’d learned when they were coders. There’re lots of myths in software management, just some examples:

• Software people is of a same type and the same background.

• We already have a book that’s full of standards and procedures for building software. That provide out people with everything they need to know!

• If we get behind schedule, we can add more programmers and catch up.

• Project requirements continually change, but change can be easily accommodated because software is flexible.