I've never planned more than a few features ahead without having to revise the plan heavily. Instead, I prefer code that I can change easily. This is exactly how I avoid rewriting.

When I program, I continually ask myself two questions. The first question is does this work as I need it to work? and the second is is this as simple as I can make it right now?. My goal is provably working software that's as simple as possible.

Simple is a loaded term, but I mean that my code should only be as complex as necessary to pass the tests. Part of that comes with experience. Part of that comes as I recognize more and more patterns in my code. Since I have oodles of tests, it's reasonably cheap to continue to simplify.

Because I work in small steps, adding one feature at a time, always testing and always simplifying, I'm confident that I'll always be able to add new features relatively inexpensively. It's also nice to say, "I'm done already? I can't think of any more tests to write. The feature works. I wrote far less code than I thought I would need."

I guess there's different between planning based on what you know for sure you need and planning for contingencies. It's too hard and impractical to try to tackle all potential contingencies--not that you shouldn't plan at all, just make sure you know correctly your priority.

That's possibly the worst advice. NOT planning for expanding is a good way to have to rewrite your software later. Granted, it doesn't have to be overly-normalized, but my God... If you need to expand later, you better plan for it now.

If you know your message board needs to interpolate with say, several clients, then doing somethign like SOAP or the ilkes will be required before hand. If you need it to do RSS feeds, better not making it too disorganized, otherwise, you'll have to litterally punch it in later on.

chromatic is obviously advocating YAGNI approach to solve design problems. In short the idea is that you split your development process in short iterations: in each iteration you select functionality to implement, then you design the system in the simpliest possible way to pass functional tests. While doing it you religiosly refactor code to remove code smells (i.e. code dublication, too big methods and subs, etc). In my experience it is actually very efficient approach which at the end produces more high quality and more flexible code compared with water fall style development process when you try to design everything from the begining. Too often initial assumptions became wrong assumptions, functional requirements change and end result becomes big ball of mud.

Word of warning though. If you try to develop using YAGNI way then TDD is a must, constant refactoring is a must. If you don't follow these practices you'd better stick with waterfall way or result will be a disaster. In a sence waterfall is simplier model though less effective.

--
Ilya Martynov, ilya@iponweb.net
CTO IPonWEB (UK) Ltd
Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
Personal website - http://martynov.org

It might be useful to emphasize that the "testing" during the iterations could have two parts. One is the testing against functional (or technical) spec, as mentioned. Another against user req, which involves account manager, client, point of contact or whomever.

It would be good to know that while you're hacking the code, your marketing folks have changed the "name" of the product from Performance Appraisal to Goal Management... so that you won't be surprised two months later, the marketing material given to clients doesn't sound quite the same as the spec you've built your app on.

In other words, a challenge of planning and its implementation is that your target is moving.

What if you guess wrong? You'll still have to rewrite.

I'd rather add ten features to a system that's well-tested and regularly refactored than one system that has been completely planned from the beginning. I'd bet that it's also much cheaper to change the first system than the second.

I much prefer software that's so simple you can change it than software that's so flexible you don't have to change it — because someone always has to change it and that's usually me.

What if you guess wrong? You'll still have to rewrite.

I recommend against "guessing" as your design methodology.
--
Snazzy tagline here

Until your softare gets so bloody huge, you can't refactor quickly. Chances are, if you add expansionability (is that a real word), then you'll have something in place that itself can be refactored with much ease. You won't have to hack in expansionability. (two times!)