it is argued again and again.
What I think is, each component is so thin and simple that can be easily put together as a whole. They can be tested very easy and a so-call state of art software is like a tool you can extend in any way you want.
Any time it will argue about the implementation is not enough oriented design, a bit slower or the design is too complicated.
To me, it is a matter of methodology and personal preference.I understand each method will always have its advantage and drawback.
But the golden principle must be remembered is, as a programmer, you must deliver correctness, easy maintenance and enough performance in time! Otherwise, rubbish...
So at the design stage, we should focus:
1. how to make sure it is 99% correctness after delivered?
Always ask: Requirements are well understood?anything missing? Enough resource to Test? Easy to Test?
2. How to make it easy to maintain?
Each part is easy to understand? Easy to divide? Easy to put them together like a tool? What is the potential extension for future development? Requirements and Features are apparent enough? Well organized or have a layer concept(Look at the army or a big company how they are organized)?
3.good enough performance
What is the estimated and required performance in normal transaction? Do you understand the algorithm? Do you know the performance stat or try for each operation(assignment, function call, virtual call..)? What is the bottle neck? If want to talk about performance, please provide the stat data before discussion.
4. deliver in time
Have you break down the requirement detail enough how to implement in your mind? If cannot, please continue. It is the basis of project scope estimation. Try to use your experience, or FPA(Function Point Analysis, somebody suggests but I don't pratice) to estimate the time. Find a good tool to help you to consider the factor of holiday or effort percentage. OpenProj may be a free and good enough choice. If project progress falls behind the schedule, can you notice it in advance? Can you control? If cannot, ask yourself why cannot and what is the reason of that. Keep on communication and let the stakeholder know the status in time. Nobody will like to be surprised finally!
So, I don't care how it is implemented if all the above are satisfied.
What I think is, each component is so thin and simple that can be easily put together as a whole. They can be tested very easy and a so-call state of art software is like a tool you can extend in any way you want.
Any time it will argue about the implementation is not enough oriented design, a bit slower or the design is too complicated.
To me, it is a matter of methodology and personal preference.I understand each method will always have its advantage and drawback.
But the golden principle must be remembered is, as a programmer, you must deliver correctness, easy maintenance and enough performance in time! Otherwise, rubbish...
So at the design stage, we should focus:
1. how to make sure it is 99% correctness after delivered?
Always ask: Requirements are well understood?anything missing? Enough resource to Test? Easy to Test?
2. How to make it easy to maintain?
Each part is easy to understand? Easy to divide? Easy to put them together like a tool? What is the potential extension for future development? Requirements and Features are apparent enough? Well organized or have a layer concept(Look at the army or a big company how they are organized)?
3.good enough performance
What is the estimated and required performance in normal transaction? Do you understand the algorithm? Do you know the performance stat or try for each operation(assignment, function call, virtual call..)? What is the bottle neck? If want to talk about performance, please provide the stat data before discussion.
4. deliver in time
Have you break down the requirement detail enough how to implement in your mind? If cannot, please continue. It is the basis of project scope estimation. Try to use your experience, or FPA(Function Point Analysis, somebody suggests but I don't pratice) to estimate the time. Find a good tool to help you to consider the factor of holiday or effort percentage. OpenProj may be a free and good enough choice. If project progress falls behind the schedule, can you notice it in advance? Can you control? If cannot, ask yourself why cannot and what is the reason of that. Keep on communication and let the stakeholder know the status in time. Nobody will like to be surprised finally!
So, I don't care how it is implemented if all the above are satisfied.
No comments:
Post a Comment