Thursday, December 01, 2005

Completing the design

The simple concept of refactoring has helped me allot. I have the tendency of not being able to start implementing before I think I have the design all figured out. This is something I think I got imprinted in school through all the "bugs-found vs. development-phase" graphs, and perhaps it is in my character as well :) Now I just tell myself: "this might not be perfect, but I will just refactor it later", and it does wonders for my throughput :)

I have in fact turned quite against completing the design before coding. In particular, I think that one should not try to guess how a particular class might be used in the future, e.g., by adding numerous accessor functions no one uses but need to be maintained and unit tested.

4 comments:

Anonymous said...

"... I have in fact turned quite against completing the design before coding. ..."

I think this must be qualified with what kind of design you are talking about. If you are talking about low-level class design I think this can be true. However if applied to architectural design or interfaces to other systems or components I think nothing can replace BUF (Big Upfront Design).

Anonymous said...

Last anonymouse comment was by Finnur J.

Ari said...

Yes, there is always some up-front-design. But what I have come to believe that it should be kept as small as possible, erring on the side of too small :)

Ari said...

I ran into a interesting entry on "Seven Habits of Highly Effective Programmers", there Philip Chu says "This is not to say that design is unnecessary. But after a certain point, design is just speculation. Design validated with implementation, and better to do that early and continuously than late and, well, too late." I thought his comment was interesting in this context.