The rules of a successful life stand over the rules of software project management.
1. The meaning of life is to be happy.
If you are not a psychopath (have social skills as compassion, empathy) you will also want others to be happy, to become happy.
Now the rules of software project management.
1. don’t waste your LIFETIME! ( it’s more precious than money! )
design/develop a project in such a way, (open source components) that you can reuse parts/all of it, in other projects (that maybe do not generate money but make this world a better place)
why?
because software projects tend to fail, are not in time and budget and then cancelled.
very often and therefore… your contractors/boss does not only lose it’s money, but
you wasted something MORE-VALUABLE-THAN-MONEY: YOUR LIFETIME!
No money in the world can bring you this back.
Example: When i got the order from my boss for a very risky project (a lot of competitors with more resources than us) i immediately started to work on a open-source basis for our project, that we can “fork” to use it in our commercial project.
this is the status quo: http://sourceforge.net/projects/gigalaunchde/?source=directory
2. Whenever you have a problem to solve, make an example project.
This will break complexity down into simple, understandable parts.
You can keep a workspace-project full of examples (in nameful folders like STRINGS, ARRAYS, LOOPS) as a reference, when you come across the same problem again, you can search your workspace instead of googlin around.
3. Avoiding Errors:
3.1. Simplicity – Keep everything as simple as possible, complexity will increase the amounts of errors.
If you can simplify an function, take the time to do it.
Do things right from the start.
3.2. Test-Documentation THIS IS CRUCIAL!
For every even simple interaction with your program, WRITE DOWN A TEST-DOCUMENTATION, that you can follow AFTER you changed something and BEFORE you release it to the public.
Example:
===== TEST DOKUMENTATION =====
==== register.php ====
ok 1. register without username -> should refuse registration
ok 2. register without password -> should refuse registration
ok 3. register without password confirmation -> should refuse registration
ok 3.1. password confirmation does not match password -> should refuse registration
ok 4. register without email -> should refuse registration
ok 5. register without firstname -> could be optional, but should refuse registration
ok 6. register without secondname -> could be optional, should refuse registration
ok 7. register same username twice -> refuse registration, display message "username is already registered"
ok 8. register with unique username -> registration successfull -> display message & redirect to registration_successfull.php
==== login.php ====
o 1. login with not existing username -> message "username or password wrong."
o 2. login with existing username, wrong password -> message "username or password wrong."
o 3. login with existing username, and correct password -> message "login successfull... you are logged in."
... creating session cookie.
... then redirecting to content.php
... content.php must check session cookie.
3.3. Linus Torvalds: “Functions should not be larger than one screen tall”.
Chapter 4: Functions
Functions should be short and sweet, and do just one thing. They should fit on one or
two screenfuls of text (the ISO/ANSI screen size is 80×24, as we all know), and do one
thing and do that well.
The maximum length of a function is inversely proportional to the complexity and
indentation level of that function. So, if you have a conceptually simple function that is
just one long (but simple) case-statement, where you have to do lots of small things for a
lot of different cases, it’s ok to have a longer function.
However, if you have a complex function, and you suspect that a less-than-gifted first-
year high-school student might not even understand what the function is all about, you
should adhere to the maximum limits all the more closely. Use helper functions with
descriptive names (you can ask the compiler to in-line them if you think it’s performance-
critical, and it will probably do a better job of it that you would have done).
Another measure of the function is the number of local variables. They shouldn’t exceed
5-10, or you’re doing something wrong. Re-think the function, and split it into smaller
pieces. A human brain can generally easily keep track of about 7 different things,
anything more and it gets confused. You know you’re brilliant, but maybe you’d like to
understand what you did 2 weeks from now.
download pdf: Linus Torvalds – linux coding style.pdf source: http://www.schedmd.com/slurmdocs/coding_style.pdf
/pictures/animations rather than endless text-deserts… the brain is optimized for visual operations (like your graphic card) not for boring, abstract massive mess of symbols (text)
