Re: Re: Best way to 'add modules' to web app?

[Anonymous Monk]

Uh.. what?!

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.

[IlyaM]

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, [e-mail]
CTO IPonWEB (UK) Ltd
Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net
Personal website - http://martynov.org

[chunlou]

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.

[chromatic]

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.

[Aighearach]

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

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

[chromatic]

Exactly. Don't guess. Know.

[Anonymous Monk]

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!)

[adrianh]

Can you give an example of where this happens?

In my experience a well-factored program means that you always have a codebase that is flexible enough to accept new features simply. However large.

There is also the advantage of avoiding the overhead of infrastructure until you need it, which means you have a smaller simpler codebase that is faster to develop and maintain.