|
PIEBALDconsult wrote: then you work out the details (architect).
I think "Details" means "Development" not "Architecture"
Architct's role comes before Designer's role.foreach(Minute m in MyLife)
myExperience++;
|
|
|
|
|
I disagree; the general design (n-tier, etc.) comes first, then the details (language and technologies, etc.) are architected.
|
|
|
|
|
to a small degree i agree with you! but i take architecture as the different technology's that can be used together such as Desktop Apps with web services etc
|
|
|
|
|
PIEBALDconsult wrote: then you work out the details (architect
That's the wierdest definition of "architecting" I have ever seen. Architecting is usually higher level design - less focus on details and more on the big picture, at least that is the original meaning of the word in the world of building construction.
|
|
|
|
|
Not at all; architects are the ones who have to work out all the details after the broad strokes of the design are decided.
|
|
|
|
|
PIEBALDconsult wrote: Not at all; architects are the ones who have to work out all the details after the broad strokes of the design are decided.
[citation needed] 
utf8-cpp
modified on Wednesday, March 10, 2010 10:52 AM
|
|
|
|
|
Architects are the ones who have to be sure the elevator shafts and such line up, that the building will meet code, etc. 
|
|
|
|
|
I refer you to Wikipedia[^] (which may be wrong).
Software architecture is the plan for fulfilling non-functional requirements, while software design is the plan for fulfilling functional requirements. Each architectural decision should be traceable to a non-functional requirement.
I then looked up Non-Function requirements and found:
In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. e.g.
- Execution qualities, such as security and usability, which are observable at run time.
- Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system.
PIEBALDconsult wrote: First you decide what it is you want (design), then you work out the details (architect).
Maybe it should be:
First you decide what it is you want (customer request), then you work out the details (design) and remember to make the product secure, useable, maintainable etc. throughout that process (architect).
I want a house.
Room here, room there, stairs and a loft.
Without architectural skills you end up with the pipes from the toilet blocking access to the front door, and windows that don't shut properly. How many times do we get the software equivalent because we failed to consider architecture during the design phase?
|
|
|
|
|
The Man from U.N.C.L.E. wrote: Without architectural skills you end up with the pipes from the toilet blocking access to the front door
That's my point; the design (three-bedroom/two bath colonial) comes before the architecture -- which has to work out the details and make sure everything fits.
The software usage of the terms should follow the building usage; not reverse them.
|
|
|
|
|
|
Disagree.
If you are creating a fighter airplane, you must have a very well architect, but if you are creating a paper plane for your kid, you will pick a paper and start folding it to end with a perfect plane that will satisfy your kid, and you as wellforeach(Minute m in MyLife)
myExperience++;
modified on Monday, March 8, 2010 10:49 PM
|
|
|
|
|
In the paper plane example you are replacing design with previous experience.
(we all made paper airplanes once.)
|
|
|
|
|
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
