|
I guess it boils down to how you define "architecture" and "architect" in a software context.
One definition from Dino Esposito is essentially "making decisions up front about stuff that is difficult to change later."
So I guess if you subscribe to that school of thought, any app where changes are trivial has no need for (drumroll) "ARCHITECTURE"
|
|
|
|
|
Well in large projects, changing the architecture will likely be very difficult. In very small ones, it may be rather easy. But both projects go through the same process.
|
|
|
|
|
Because some clients asking software/application with in a month or below that, in that situation i need to go straight on development with existing projects references(if exists, otherwise i need to do things) due to less time, otherwise competitor will pick that one.
|
|
|
|
|
|
Disagree. Some of our customers don't think about requirements until we have delivered something. I even had one turn up with a PHOTOGRAPH of someone else's product and demand a cheaper version (we did deliver it and they are still happy with it). But really they do know roughly what they want, and if we don't want to have yet another endless project we have to document it first and get their signatures on it.
Though yes, as a rule, we know what they want and we know what we want to build, and it's building on things we have done before, so we could just bumble ahead like we used to do. But most documents can be created by copy and paste from the previous project, so it is possible to do one in a week, even if there's a TBD in places. We have specs for documents, and most are available in template form.
I personally like to write down what I want to do to get it clear in my head. Usually I can write the contents list of the design document and create the classes on the screen at the same time. We have tried out these clever systems for creating code from the document, but I find it a bit inflexible, because I might suddenly see that class A belongs over there and that class B is actually an instance of class C. The requirements from our sales dept are often incomplete and ambiguous, so there is a lot of fine tuning going on. Some colleagues keep all this in their heads, but I am not clever enough for that, I have to write it down.
Often we work on legacy software, and if the documents were written afterwards instead of in parallel, then they are usually a bit thin and we curse our ancestors.------------------<;,><-------------------
|
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
