On Software Quality, Inspired by "超越" Auto Diagnostic Software

Done, finally done! Several late nights working until dawn. Here’s the final screenshot.

I wanted to write this as a technical post — about software architecture, design patterns, refactoring, extensibility, double-buffered drawing… But after coding finished, I lost the mood. First, I’m not good enough to preach to the world. Second, if I found a better design, I’d go back to coding without sleep.

This program is basically GDI drawing — BitBlt, LineTo, CreateSolidBrush — all things I’m comfortable with. No technical challenges. But different drawing means I spent more time on design. Used some patterns and OO thinking. Maybe this is what Professor Wan meant: code enough, and patterns come naturally.

I know many classmates working at software companies. They all say their software is terrible. A SAP China研究院 classmate said their product has tons of bugs. A Huawei engineer was blunter: “Multi-million yuan projects running on China Telecom’s network — code written like crap.”

In software companies, projects are bound by deadlines — pushed by bosses, PMs, and clients. Functionality comes first. Beautiful design, extensibility, OO — who cares? Imagine giving a client an incomplete program and saying: “The code style is excellent, well-commented, extensible, uses multiple design patterns and OO principles, managed with cutting-edge software engineering…” What would the client say? They’d rather have a program with bad design, messy code, some bugs, few comments, poor maintainability — but with all the required features implemented.

Maybe this is the dilemma of software companies and engineers. The heart wants to design and architect a perfect system. Reality drags you back by deadlines.