Tuesday, August 21, 2007

Requirement. Freeze. Don't move!!

I believe that many people understand that requirement should be freeze and don't be changed during implementation phrase. However, how many people willing do it or could follow this rule? I think it is a good open question.

As many books mentioned, we should not change the requirement during implementation phrase since the cost for changing will be much higher that change it under requirement capturing or analysis phrase.

For the big changes such as adding a new modules, I think many companies have the proper procedure to handle it. But for the minor changes, people will easily ignore the risk and accept the change. Actually, this is the hidden problem to make the system unstable.

Of course, to modify this minor change won't affect the system and it also could make the system better.. But what happen if we continue to do these minor changes under different times? Many people will continue to accept these changes but the fact is, 10 variances will create over 10 x 10 times variances and make the system difficult to maintain. People are easily skip to re-think these 10 variances at same time since it is not under the ANALYSIS phrase.

One of the key point for project management is to make sure everything are under control, if we create so many variances, how could we manage the project properly?

Therefore, please think carefully before accept the change. We need to improve the PM and system architecture and let them to decide even add a field or disable a button.

As I mentioned in this article, disable one button won't make much impact to the system but if we do many of these changes, the system will suffer finally.

Thursday, August 16, 2007

Early Binding !?

(Because of my poor English and this document is quite technical, you may have difficulty to fully understand it. If you really don't understand, please leave comment and I will try to explain in more detail)

Nowadays, many development tools (e.g. NET) always claims that they have many feasibility to provide the early binding. Actually, early binding could benefit the system that minimize problem occurred during the runtime since some typo problem (e.g. RecordSet("CustomerID") but typed RecordSet("CutomerIE")) could be captured during the development phase. That's why the trend of all development will try to switch to early binding approach. And that's why something called LINQ and Hibernate modules are built to direct link the DB and create the appropriate entity object with strong typed fields.

However, this approach is still not mature to handle the UI. If the outlook of the UI is dynamic and could be changed during the runtime, we couldn't located that control during the design phase. We only could build some mechanism to detect (e.g. Findcontrol function in .NET) the control. This may increase the risk of the system since we couldn't predict what happen in the runtime (e.g. What happen if the control is expected under that status but couldn't found). We may capture wrong control and doing wrong action during runtime.

Actually, I think this problem could be solved if the framework could help to identify all control's ID during design time, no matter it is visible or invisible during runtime, and store these information in the framework. Therefore, we could locate all the controls while in the development phase to help us to build a better solution.

"FindControl" is a powerful function to handle some tough UI logics. However, it is still better don't over use this function to minimize the risk. I still would suggest try to use some earlier binding solution if possible.

Tuesday, August 14, 2007

No prototyping 2 !!!

Just got the feedback from Edward and I would like to clarify something about no prototyping. Actually, what I suggest is to use other tools (use case, data flow, etc..) to let the user to think in a deeper way to gather the better requirement. Prototyping is also a tools but I would suggest to gather the requirements from different aspect before using prototyping. However, this lead to the user need to take more responsibility and more effort during the design phase. But how to persuade the user to take more responsibility? This is related to the environmental factor and your company culture and it is another issues...

Sunday, August 12, 2007

No prototyping !!!

This is my first time to setup the blog and would like to share what my experience for software system development. My experience may not 100% follow the standards but it is just what I thought based on my experience.

Ok. let's start now..

Today, I would like to say about prototyping. From this topic, you may think that how could develop a system without prototyping. Yes, it is quite difficult without prototyping but what I said is try to minimize the dependency to rely on Prototyping. In terms of presentation, prototyping is easy to present the "real" system to user. However, it will limit the user's mindset because everything is setup. What they do is just follow the screen flow, the field shown in the screen. It may hidden some important function such as interaction with other modules, intergration...
When we discuss with user on the prototyping, user just focus on Screen, not real situation..

From my opinion, it is better to use the UML tools to build up the diagrams (such as use-case, sequential diagram..) and discuss with user but no prototyping at same time. Actually, it is a tough job for user to imagine the system without a "real thing" but it still better to convince them to follow it. It is because this is the only method to make the user think the system in the detail, not just based on the screen to determine what they need.

Honestly, this approach takes longer time during design phrase but minimize the risk under the implementation. As I mentioned earlier, this approach will let both developers and user understand what the system will done but not just a imagination. Prototyping makes things looks "real". However, it looks real only..