|
Nemanja Trifunovic wrote: developers will spend most of their time fighting the architecture
I think that may be more indicative of a problem with the developers (lack of maturity and/or focus) vs. the architecture.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: I think that may be more indicative of a problem with the developers (lack of maturity and/or focus) vs. the architecture.
Sorry, but if as a developer, I spend most of my time trying to figure out what the heck the "architecture" is trying to accomplish and how to add a simple feature that a customer wants, I say the problem is with architecture, not with developers. If I need to edit various (often undocumented) XML files and (in case of .NET) insert attributes to add a simple control to a dialog, I say the problem is with the architecture. If I need to spend hours trying to figure out how to open a simple file, I say the problem is with the architecture, not developers.
I've seen that problem in at least three companies I worked at - all of them filled with smart people and relatively well organized.
utf8-cpp
modified on Wednesday, March 10, 2010 1:48 PM
|
|
|
|
|
You're right. I misread "fighting the architecture" as "fighting about the architecture". If the architecture forces you to go through hoops to implement something straightforward, that indeed smells like a poor architecture.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: If the architecture forces you to go through hoops to implement something straightforward, that indeed smells like a poor architecture.
The real problem is that I have yet to see a "good architecture"
|
|
|
|
|
You also dont want some astronaut doing architecture...
|
|
|
|
|
"making it up as you go along" is a form of architecting.
Even if I just whip off a "Hello world!" program, it is architected.
|
|
|
|
|
PIEBALDconsult wrote: "making it up as you go along" is a form of architecting design.
Even if I just whip off a "Hello world!" program, it is architected designed.
Now I feel better
|
|
|
|
|
First you decide what it is you want (design), then you work out the details (architect).
|
|
|
|
|
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.------------------<;,><-------------------
|
|
|
|