Attributes Classes Interfaces And Types
Attributes Classes Interfaces And TypesAttributesClassesInterfacesAndTypes are not my concern. Not yet. Wish I know more though. Meanwhile AgreementAlignmentPoliciesAndRelationships are TheBigIssues.
But I still claim to be a part-time SoftwareArchitect, because ArchitectsPlayGolf, in the RelationshipManagement sense.
InformationTechnologyFrameworks, JavaAndDotNet, SecurityManagement, SoaIsNightSky etc are in my scope, and coding is not.
This page was intended to discuss with people that there are different types of SoftwareArchitects doing different things. Some ArchitectsPlayGolf, some ArchitectsPlayGod?, and some ArchitectsJustPlay. EricHodges responded, and most of the page had been a dialogue with him. Unfortunately with WikiTechnology here anyone can respond, and therefore the page is getting more messy than it necessary.
If so, then this page is poorly named. I'm loath to suggest such a long name, but ArchitectureIsNotAboutAttributesClassesInterfacesAndTypes? perhaps better catches the meaning. There must be a shorter way to name this concept... <I accept some architects, and in some situations, do value the skills and insights related to a DeepKnowledge? of xxxxxxx. It is named as such as a response to GangstaGeeks attitude toward less technical-detail focussed individuals. -- dl>
Complete non-sense, ArchitectsPlayGolf and ArchitectsJustPlay are OrganizationalAntiPatterns?. If you think that attributes classes, interfaces andn types are not your concerns, then you shouldn't be "architect". If you are in charge of picking up tools and technologoies, find your best developer, and ask for professional advice. Do not assume that if you can google for buzz-words, read expensive "industry reports" filled with trivialities at best, and more often than not with wrong information, then you have some kind of competence on judging the merits of technologies as they may apply (or not apply) to a software project.
Now the extraordinarily funny MetaAntiPattern? at work here is that the so-called "architect", not only applies anti-patterns in his parochial business environment, but wants to promote them urbis et orbis as "patterns" on a site like c2 (which is by programmers and for programmers). And in the process he deploys CollaborationAntiPatterns? and even those he tries to promote as CollaborationPatterns.
The resolution to making room for this viewpoint is quite easy: DavidLiuOnArchitecture?, DavidLiuOnArchitects?, because this is a fringe view that you have not put the least of efforts to back it up with reasonable premises, arguments and rational discourse. -- CostinCozianu
And then there are software architects who wonder how anyone can call themselves a software architect without using the architectures they design and the tools they select. See repeat this (something similar in ArchitectsJustPlay).
See repeat what?
I've never understood what someone could do with tools like JavaAndDotNet if AttributesClassesInterfacesAndTypes were not their concern. How do you use them? -- EricHodges
The statement at the top is probably an extreme form of rhetorics.
There is already a business endorsed ApplicationArchitecture? in place, and some funding prioritization to make the transition (from here to there). Assume there is already senior (perhaps board level) support for the aquisition (and implementation) of an EnterpriseResourcePlanning package. There need to be exercises to examine what specific functions to acquire and implement. The "Golf playing" include the networking with peers in other companies, to understand what and how things might work, what level of user participation is needed when, whether you need interim technologies / solutions. Inhouse people, architects included, just do not have all the required knowledge of solutions and their limitations.
This is also the stage the architectural team need to work with "delivery areas" (application and enduser) to agree on resource and schedules. A proposal is needed for signoff, to obtain reaffirmation of the business commitment, and to start dependent processes which can include partnering and tendering.
There may be some consideration of AttributesClassesInterfacesAndTypes, but these are probably limited, and pale in size compare to policies, contracts, agreements, services, etc.
Are you arguing in favor of a class of software developer composed of people who don't actually devlop software, but make decisions about which tool sets actual developers will use without having first used them? If so, how do members of this class of "developers" learn about the tool sets? Read magazines? And why would anyone who has to write code trust their decisions? -- EH
CollaborationStartsWithaQuestion?
But the above can become an OverextendedArgument.
"From above" ...If so, how do members of this class of "developers" learn about the tool sets? Read magazines? And why would anyone who has to write code trust their decisions?
I suggest it is time you provide some insights to the excellent question above, as to how things might work instead. And it would be better if the scenarios are realistic.
I asked the question for you to answer. The obvious alternative is to refuse to call people who don't develop software "software developers". Programmers should pick their tool sets based on first-hand experience, not marketing or journalism. I wouldn't buy a car based on the recommendation of someone who didn't know how to drive. -- EricHodges
It is time people who value this community to reassess whether their behavior can be construed as HostileStudent, HostileTeacher or similar agressive manners. If I recall correctly when I asked you information on EJB, in the Costin challenge KB case, you were not nearly as enthusiastic about providing assistance. I will soon be responding to DaveVoorhis on his question and in Costin's words "put in the shoes of WikiReader", how annoying the questioning tactics were used. You are much better for now, and I acknowledge it is a "valid" viewpoint not to buy cars from recommendation of people who do not know how to drive. We can continue a yes/no argument like CC and RK is having now, but would you not consider ToFightEvilWorkOnTheGood could be better for the community.
Huh?
Earlier I said the following and still feel this is how things work in reality. Programmers do not pick tools. Programmers apply tools the best they can, based on software dictated to them by much higher up. The higher ups get their ideas from conferences, presentations (vendor), visits (other companies, vendor labs), their business colleagues who want products only one vendor can provide, paid consultancy studies etc. I am qualified to say the above because I have worked in various medium to large companies for many years. Inhouse technical staff are often snowed by vendor heavies sent in at product demo (proof of concept, etc) time. This has nothing to do with my personal view, nor the view of any other people, whether this is how things should work. So I keep focused on "what is realistic now and in near future", and talk to people sitting around me (and they all happen to write code, for different platforms).
I assure you that programmers pick their tools. I've picked every tool I've ever learned, and it's been 15 years since someone "higher up" tried to tell me which tools to use. I have also worked in various medium to large (5,000 to 100,000 employee) companies for many years. But I'm still a bit confused about how you learn about tool sets. The people sitting around you write code, so they must be programmers, correct? But programmers "do not pick tools", so they are using tools "dictated" to them by non-programmers, also correct? If so, why do you trust their judgement about tool sets? And how do you know their assessment is accurate? -- EricHodges
This is one of those rare moments where you tried harder than me to explain viewpoint. What do you mean "how I learn about tool sets". The first tool I used was Fortran decades ago. The first tool I use at work is Apl, decades ago and none of the programmer types there made the choice of tools. And when I came to participate in the evaluation of tools there were lots of constraints put on our team by all stakeholders, and that was only proper. Now please tell me what do you mean by your 100,000 employee firm go about letting programmers choose their tools. Is it possible you worked for a consultancy selected by a 100,000 employee firm to do software evaluation.
I'm not asking about the tools you've used. I'm asking about the tools you say you don't use. How do you learn about a tool without using it? From everything you've said it sounds like you trust the knowledge of others. From your actions on this wiki it seems like you want us to research tools for you. Why not get your hands dirty and use these tools yourself? Then you can come back and tell us what you think.
I was one of the 100,000 employees. That employer let me pick my tools. I was not a consultant. I was an employee.
-- EricHodges
In my experience, the degree to which a developer gets to choose his or her own tools depends on the project, the company policy, and the seniority of the developer. If some combination of these results in a developer (or a set thereof) not being free to choose his or her own tools, it is typical for the toolset to be chosen by some technically astute body, with at least some, and frequently all, input from other programmers. The reason for this is simple -- the average non-technical manager is more than aware that he or she isn't qualified to recommend one programming language over another, and is likely to face resistance from the developers and/or look stupid and incompetent if he or she makes an uninformed and/or unpleasant choice. I'm sure there are organisations where such decisions are made over golf games by non-technical people, but I've never done any work for one, and it sounds as dysfunctional as letting a committee of non-drivers choose your next car. But then again, that view may reflect the fact that I've mainly worked with relatively small companies that valued the opinions of their programmers, and for individual departments in large companies that were granted the flexibility to make language and platform decisions for themselves. In other words, this may come down to a difference in corporate culture, where DavidLiu works in one type of culture and EricHodges works in another. -- DaveVoorhis
You are welcome to move this discussion to any page you like. -- EH
CollaborationIsNotOnePersonDoingAllTheWork
Who suggested it was?
ok I created JavaBusinessIntegration, a topic very foreign to me. If with your extensive EJB knowledge you feel it does not have a future. Say so and quote references. If you think it is wrong, make corrections. If you think it is hopeless, rewrite it. I created that page not because I am compelled to tackle anything that come into the press, it is due to "unavoidable" professional interest in news and developments in ServiceOrientedArchitecture.
This reply seems like a non sequitur. No one here suggested that collaboration was one person doing all the work. Why did you put that link here?
To EH 1 of 3: Link to Coll... and/or JBI page? The "Collaboration..." link was put here because our esteemed XoYnKi creator does not seem to be much motivated in creating basic information for people wanting to know more about the JavaPlatform. And when he does take interest in a subject (e.g. his ears perk up when there is perceived blasphemy about CriticalItSurvivalSkills for SoftwareArchitect) he demands lots of timely interaction. My point is that:
to EH 3 of 3: At this moment I have taken TheCostinChallenge? and requested him (a few times) to tackle and improve pages using DisagreeByAdding mechanism. He does criticises many people here, and it is painful to see his energy wasted on negative contributions. Given his SoftwareArchitect and EJB claim of knowledge he could have improved content on SOA to the benefit of all. If and when he does take up the challenge, I may be able to show him his own gaps of knowledge in WhatIsSoa, or learn from him instead. At this moment the WhatIsSoa remain technically flawed as a summary. I chose SOA because it is important, it is not a Microsoft monopoly. When we have better replacement, then we can clean up all the other "messy SOA stuff" lying around. Is that not better instead? -- DavidLiu
"Unfortunately with WikiTechnology here anyone can respond, and therefore the page is getting more messy than it necessary."
If you don't want anyone to respond, don't use wiki. That isn't an "unfortunate" aspect of wiki technology, it's the key principle. -- EH
You are right. So I will remember this page as a WorkInProgress and hopefully we can have a better sharing of views on What is ProgrammingInTheLarge.
EditText of this page
(last edited November 23, 2005)
or FindPage with title or text search