Actually, I search to create a process integrated ISO9001 working method.

Criteria :
- easy to use,
- capability to integrate the continual changes in team work !

I have the image of what I want in my head.
I now know that my vision of seeing people working in future is quite nearly software building and expanding.

My question :
“…A practice that I will sometimes use in my code, is if I know I am going to be building it out in the future, is to build the class definitions and having them return true.”

Can you explain : “…having them return true.”

I assume it is related to iterative&integrated risk -control management when programming.

Thanks to share your information,
excellente fin de journée,
Annemarie

For instance, lets take the last personal project I worked on. Phase 1 included only core behavior, while I plan for an administration area in the future, I didn’t build any of it, rather built the components that I will be utilizing for certain sections. Phase 2 is building an administration area and refactoring the code to run off a more centralized area (right now data is simply cached from a third party in files rather than being extensible from a database perspective). Phase 3 is to build the features on top of what was previously there.

Rather, what I speak of is simply to stop over engineering certain aspects. I could have taken phase 2 and said, well it is necessary for the data to be stored in the database right away, when I have no clue of the marketability of the said product. It solves the task but doesn’t completely give all of the functionality that it could have. Meanwhile, the object oriented structure in place to allow modifying the data source with little to no extra effort. Which left an interface for building in the future.

It is both maintainable and extensible to build what I may need on top of the components already built. As developers we will be faced with the decision of what approach is going to be better (build for refactoring or build for abstraction).

My approach used to be yours, and try to build a semi-framework for every feature.. Later on I realized there was more work in maintaining the abstraction, while in a lot of cases it was unnecessary to begin with..

Writing maintainable code is very important, and design for change is too.. My moniker is now ‘build for refactoring’ instead of ‘build for abstraction’.