How do you know?

Everything I learned from that 16-month program of software engineering I attended can be summerized into one question: "how do you know?"

From beginning of the 16-month project, we have to answer this question for God knows how many times in public, under ruthless critics from software researchers and professors.

1. This is the problem our client needs us to solve. (How do you know?)


2. We will finish requirement elicitation in Nov. (How do you know?)


3. These are the requirements.(How do you know?)


4. This design could satisfy our customer's needs. (How do you know?)


5. Our team dynamics is good and improving. (How do you know?)


6. Our meetings are efficient. (How do you know?)


7. CMMI/Agile/Scrum/TSP process will lead us through this chaos. (How do you know?)


8. Our client is usually happy about our results. (How do you know?)


9. We spent too much overhead in meetings. (How do you know?)


10. The main risks are X, Y, and Z. (How do you know?)


11. Our estimation and plan makes sense. (How do you know?)


12. The quality of our software is good. (How do you know?)

One of the major goals of software engineering, not programming skill or computer science, is to provide evidence and tool for management.

Visibility is something we need but seldom have in a software project. Like my favorite professor always said: if you cannot tell where you are, a map is not going to help you much. If you don't know how far you are to the destination, how do you know when you are gonna finish?

Software architecture is another major pillar of software engineering. One important use of architecture is to facilitate requirement ellicitation and project management. We can talk about that later.

If you are also interested in these topics, please leave a message. At least I would know somebody is reading :-)