little thoughts

you can have a very nice plan, but terrible piece of codes.

you can have the only documentation as the codes...

or you can do fast iterations, so that we (software engineers) help the user visualise what they want. Show them immediately quick and dirty prototype. Be ready to throw them away. This helps to converge to a commonality point.

quotes

if i dont look good, i dont think you will looked very good too...

but if i looked good, i am sure you will also looked good.

if the team dont look good, i dont looked good.

if the team looked good, we will look good too...


stakeholder...
decision maker...
middle man...
my client...
my team mates aka internal customer ...

environmental ideas

replace bend pipes with straight pipes

throttle server fans

increases air con temperature

a pot that reduces heat wastes. (invented in taiwan)

| |
| |
| |----| |
+---|fire|---+

encapsulate and fully cover the flame...

random words

The only documentation is code...

if I dont look good, you probably wouldnt looked very good too...

codes should be free...

Scolding generates bad karma. explain why not, what is the implications. 1st time let it off, subsequently then take discplinary actions.

the more you restrict, the more precious it becomes.

the more you give, the less it becomes a critical issue.

improper handover is sad, it means 2 person messed up as a professional.

a little quote

A failed project doesnt look good on anyone. it brings out the worst in everybody.

agility and software engineering is 2 different process for different kind of constraints projects. Cheap, fast, quality triangle? cheap but heavy design doc with long turn around time doesnt go togother with fast. quality, writing JUnit codes will turn up 50% of the project time.

know who are the stake holders... are they the decision maker?

just a little thought...

to know and to abuse is 2 different things ...