It's not cost-effective to maintain tomorrow's code today, when it's surplus to today's requirements. So, implement functionality only when you actually need it. Don't implement code just to accommodate something you (might) need in the future, nomatter how sure you are it will be needed. Focus on satisfying today's needs and forget about tomorrow's needs. This can feel counter-intuitive but remind yourself "you aren't gonna need it" [YAGNI]. Have courage and push your fears about tomorrow to the side. And have confidence in your ability to deal with tomorrow when it comes.
By focusing on only today's needs you write less code and that can only be a good thing in my mind. It's quicker to write less code, and coupled with a simple design and merciless refactoring, it keeps the implementation small and testable while reducing the opportunities for defects. Also, less code that is clean, self-documenting and communicates the intentions of the developer is easier to understand.
Focusing on today's needs also applies to the architecture. I favour evolving an architecture over Big Design Up Front [BDUF]. For the last 6 years I've worked on high-performance, high transaction rate enterprise systems and it took me a while to get comfortable with this approach. You need to understand the non-functional system characteristics you're aiming for and regularly assess the system against these criteria, evolving the architecture and optimising as you go. There's no doubt that this is seat-of-the-pants stuff and to pull it off you need courage, discipline and expert application of the Extreme Programming practices.
Previous Topic
