|
|
Of late, I've had mostly smaller projects. I get the needs (usually the real ones!) and just start to go.
Having been doing this for years, there are mental bookmarks of things that will be needed and provision is made (are these what are called stubs?) for their later attachment. It's not a patchwork, and actually affords a degree of structural consistency.
How much does one project really differ from another, when looked at from the point of view of evolutionary changes in needs.
So maybe, for myself and others, the framework is already well planned from experience, force-of-habit, and even instinct - without the formality of writing it out."The difference between genius and stupidity is that genius has its limits." - Albert Einstein
| "As far as we know, our computer has never had an undetected error." - Weisert
| "It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
|
|
|
|
|
|
If you can see a clear, maintainable way of implementing a small project, then the formal software architecture phase can be omitted. Larger projects can't do with out it.
|
|
|
|
|
ZTransform wrote: If you can see a clear, maintainable way...
...then you have already defined the architecture. If you are creating a simple CRUD app and you decide to use SQL Server, C#, Linq 2 SQL, and WPF, then you have already made many architectural choices whether you realized it or not.
Some people argue that an architecture is always defined; even in methodologies that, supposedly, try to avoid them.Josh Fischer
|
|
|
|
|
Yes, I agree. Even at that, you can have a working application that fufills a business need successfully even though the design looks like crap. I'm not in favor of that, but have seen it more times than not.
|
|
|
|
|
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.
|
|
|
|
|