Basic principles of software development
Each project I work on is fortuned for success thanks to seven (a lucky number, I hope you agree) basic and ideally working principles:
- Planning and feedback... in the name of an ideal hour!
- Priority of importance.
- From reasonable research to requirements and functions.
- Simplicity.
- Keeping communicative functionality of program code
- Step-by-step changes.
- Testing.
Planning and feedback... in the name of an ideal hour!
I appreciate my own efforts and pay respect to a man who is paying for it - a Client. That is why I think that a Client should pay only for time which was dedicated for his tasks only. As a professional, I can't and not willing to afford myself any delays and extorting more and more money. For the sake of my own development, I prefer the amount of money I receive to match the true result I achieve.
So, I have developed a special system of real and physical hours. Accepting any order, I schedule its length and time of completion basing only on ideal (pure) time, taking,in account only hours, minutes and seconds actually spent on project without any looks aside (there's only me, my PC and some additional materials). After the order is completed, I compare the length I counted on initially with the actual time it took me to accomplish the task. And each time values of real and physical hours become more and more compliant.
This approach ideally fits into the main formula of successful business relations: professionalism plus mutual respect.
Yes, I am an idealist!
Priority of importance.
Any kind of system is made for performing some functions, otherwise it would simply be senceless. All of these functions can be classified by their importance.
Some are conceptual and absolutely necessary for System's functioning.
Others play secondary roles: they simplify users' interaction with the System and their usage is quite regular.
And some are used very seldom. There are even those which are tranferred into a Trash can after a more closer look due to their needlessness.
From all of this, it's easy to guess another principle: the most important part of the work should always be done first. This allows my Client to start testing critical functionality of a System before its completion and decrease development risks.
From reasonable research to requirements and functions.
I believe in cause-and-effect relations taking place in our little world. According to my belief, any part of a System is based on a reason which defines a purpose and functionality of each element. Correct understanding of each reason leads to a proper realization. However, as in any cause-and-effect relations research for effective system building, all nuances should be carefully taken into account.
I assume (and would be agreed with) that it's much better to dedicate more amount of time for the task reasoning than later be surprised why the project made in full accordance with the specification fails to satisfy the actual Client's needs.
Simplicity.
Simplicity leads to convenience which is always pleasant to work with as an easy for understanding and accessible environment. For any system, convenience is one of its "golden" factors.
A simple interface allows users to get oriented easily inside the System, and a simplicity in realization (if we speak of technical solutions) allows a programmer to spend reasonable amount of time for System and its development.
So, in any case, a simplicity is indeed a great thing!
Keeping communicative functionality of program code.
Yes, a program code is a pointer for some machine action. But not only! It's also a tool for communication between developers of a System. And we can not afford forgetting about that. A compact and well-understandable program code is more safe than a complex and tangled one. An ideal code is not a script written on a "dead" language, it's a real "living" language spoken by programmers and understood by machines. No comments in this case! And this is another bright illustration for a simplicity principle.
Step-by-step changes.
Evolution is always more preferrable than revolution. At least, this idea is completely true in our, programming industry. So any kind of changes for the system should be done in small portions. Otherwise, a project can turn into an uncontrollable state (the same was as revolution) and a Client won't be able to check the project development and be involved into further decisions. I always try to produce stable intermediate versions using as narrow timeframes as possible and provide them to a Client.
Testing.
Testing is some kind of stability check. Every System requires a separate, adequate set of functional tests and automated unit tests. This set must match the complexity of a System and requirements to its predictability.
