|
There are two mistakes to make here:
1. Assuming the initial plan is the final one
2. Skip making plans because they will change anyway
|
|
|
|
|
Agree with this. A recent project I was brought in on included a project that was broken down into 5 pieces, each formally created to represent a piece of functionality for the end product. Trouble was that during development, the business goals changed, and as a result, so did the functionality. Now we have functionality that overlaps across two or more of the formally defined pieces. So where does the new functionality fit? We could create more pieces, but then we would have even greater overlap. We could just randomly pick a place to put it, but then we complicate maintenance, because there is now more than one place to look if the code needs modification. As requirements change, as they inevitably do, the formal structure gets more archaic.
I think it's wiser to structure your project around a software development pattern than a set of requirements, because requirements change too often. One good example is ASP.NET MVC, where you have specific folders for Models, Controllers and Views, plus a well defined pattern for the URLs, which are a great indicator of where to look when code needs to be maintained.
|
|
|
|
|
I'm not sure why you were voted down - I like this one point you make especially:
Don't structure your software around requriements.
Still, I'm not sure "a development pattern" is sufficient for design - it sounds a bit general. In my opinion, a successful software project is about doing none of many things wrong - it can't be "saved" by doing one thing right.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
