Software Development Principles

 

A good software, in the developer POV, should satisfy below criteria:

* FUNCTIONAL (as specified, with reasonable resource) : of course, trivial assumption.

* REUSABLE : currently the most notable criteria, which is the father of OOP andRAD.

* EXTENSIBLE : the brother of “reusable”, in other words, it’s the good side of “flexible” (the bad side is “modifiable/shrinkable” which requires more efforts).

* RELIABLE : even when the software is run in non-specified conditions, it should not lead to system crash/hanging/exploitation, and should produce the most accurate result, while giving the user some warning/caution.

Hence, the pragmatic software development, after LOTS of failed projects, has proven some paradigms to achieve the above criteria in a predictable way. That’s why we have now programming philosophies, conventions, OOP, OOAD, principles, and also a bunch of design patterns.

And here are my notes about some useful development principles:

* KISS: Keep It Simple, Stupid (làm đơn giản thôi, ngớ ngẩn)
This is not only useful in software development, but also in a wide array of disciplines, such as animation, journalism, photography, engineering, and strategic planning. As Einstein’s maxim: “everything should be made as simple as possible, but no simpler.” .
Surprisingly, there are numerous so-called developers who forget this principle in serious development.

* DRW: Don’t Reinvent Wheels (đừng có phát minh lại cái bánh xe)
This is also a general principle for gaining solutions in shorter time. It is emphasized in software development in which the human cost, which is highest part of software TCO, is proportional to development time and maintenance efforts. If there is a good solution we can get, just take it instead of creating a new solution from scratch, that’s the economical way.

* DRY: Don’t Repeat Yourself (đừng lặp lại cái đã làm rồi)
This principle is about re-use, not about re-invent. Yet it is similar in the economical sense. When re-use some components, we should avoid duplicated information as much as possible, because duplication increases the difficulty of change, may decrease clarity, and leads to opportunities for inconsistency.

* YAGNI: You Ain’t Gonna Need It (còn lâu mới cần đến chức năng đó)
After some experience in programming, a developer usually impose himself on foreseeing unspecified usage and preparing for changing requests. Some even go further by adding functionality (without any request), which usually turns out to break the rate of process. Therefore a developer, though is encouraged to think out of the box, should only implement things when he actually need them, never when he just foresee that he need them.

Well, let’s call it a day.
Design principles and design patterns will be mentioned in next entries .

(^o^)