|
But is this realization not a step further already? Many times I personally think that more of these epiphanies should be shared, as our own frame of thought guides and limits us immensely. Being made aware that something might be hindering our communication could already be enough to push us to notice and improve upon it.
|
|
|
|
|
It exists merely to distinct between a junior.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: It exists merely to distinct between a junior.
You are correct. But it is too bad (and probably a part of the entire problem) that there isn't a good measurable way to distinguish between a junior and another role.
A lot of this is laziness on companies' part. They never attempt to describe why someone is an "architect" versus a junior.
I worked for a guy who was an architect at a large mortgage bank.
I was a lowly Software Developer and had to use an API that he created to wrap some things up in C#.
I found some problems and started asking him why he did it that way. I explained how it failed and that he was using the underlying C# API actually incorrectly.
He said, "I copy-pasted that code from somewhere else." He never tested it, of course, because An Architect doesn't do that!!! 
At this point I had 10 years of Software Dev experience and had started using C# & .NET when it pre-released (2000 or so). I had been using C# for 5 years at this point.
I asked him, "how long have you been using C#?"
Architect : Oh about 6 months
Me: How long have you been an Architect on the project?
Architect: I used to be a mortgage guy. I took a class in C# and started doing development. Then about 3 months ago they made me an Architect.
This is how the term Architect has become entirely meaningless.
|
|
|
|
|
Architect is certainly meaningless in that bank. Maybe he was a forex trader who blew up his account but knew where the bank had buried the bodies, so they had no choice but to move him into a senior software role. 
|
|
|
|
|
raddevus wrote: But it is too bad (and probably a part of the entire problem) that there isn't a good measurable way to distinguish between a junior and another role.
There is, it's called experience. Not something you can learn your CV bot 
raddevus wrote: They never attempt to describe why someone is an "architect" versus a junior.
It isn't. They no care, they want the cheapest that gets the job done. So a junior with 20 years of experience in .NET Core.
raddevus wrote: I asked him, "how long have you been using C#?"
Since C# 2.0; before that, I was a Delphi wizard and took out a company by accident.
raddevus wrote: This is how the term Architect has become entirely meaningless.
Even with my experience, if they ask for an architect I first ask about scope to make sure it is doable. If it ain't, I advise to hire someone "better".
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
If the failure rate is 70+ percent, and has been most of the time, it's not appalling, it's a standard.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
If you were to remove the title, someone else would be doing the same thing, just under a different title.
From my own experience, someone keeping a bird's eye view of all the TECHNICAL stuff involved (so no, product managers don't count) can be a huge gain for a complex software project. By "complex" I mean anything from "it actually consists of 3 entirely separate pieces of software, working together through different physical interfaces" to "regulatory requirements are another thing to keep track of, lest you'll be unable to sell that thing".
|
|
|
|
|
After 25 years in the industry, I've finally attained the title software architect. I'm one of two in the organization of 35 developers (single product).
In this organization, it is my job as architect to look at the big picture of software design; what is good for the application five years from now. We are an agile shop and, at least in our flavor of agile, while it has a lot of good going for it, it also encourages tunnel vision. The average developer is focused on delivering today's story without too much attention to how that implementation fits into the overall software product or the future of the software product. That's where a software architect comes in.
I'm guiding the future implementation (the "how", not the "what") to a common set of design goals. I wish every developer had some architecture chops (not all developers are created equal though). But, even if they did, someone has to make the design decisions that effect the entire application. In my designs, I usually always give a sample implementation though. I do some UML if appropriate, but more important is the design documents, presentations, and samples I provide.
|
|
|
|
|
The book sounds pretty dubious, but recently I've been exposed to architects and builders in the context of a real building.
Architects deal with such matters as how space is used, or how to make a space so that it can support various kinds of uses. They're aware of dimensions, of materials, of light, of acoustics, of cost, of functions, of aesthetic, of legal boundaries, of stakeholders, of how people interact with spaces, and all that sort of thing. Ultimately they are great at devising trade-offs and their knowledge is extensive.
Builders however, when told to build a wall right there, are thinking about quantities of materials, where to get them from, of how things will joined, of angles and frames and cladding and hinges, the order of operations, whether the stuff will fit through the door on the way in, and who's going to hold that while another person fastens it.
It's actually quite amazing watching how they are so complementary yet also quite ignorant of the domain of the other specialist. Yet somehow the building gets done.
That co-operation is partly facilitated by a drawing, and partly through them each each talking to the same stakeholders. But wait, there is another specialist too! The draftsman makes a drawing, and he/she is actually very selective in what each drawing is 'about' and 'for' and therefore what it includes or excludes. A set of drawings is typically needed to establish context, indicate dimensions/boundaries/locations, label space usage. These drawings will each focus on different features/aspects of the building.
One of the most marvellous books I ever read that I felt got close to this 'plan' is now out of print (last time I looked): "Problem Frames" by Michael Jackson (no, not that Michael Jackson). It conceives of domains and machines connected by phenomena, and explicitly describes the software task as "configured this machine to ...". So when writing a browser app, it would very specifically call out the user browser (or the mobile device, if warranted) as a machine in which the programmer needed to produce some effect, in order to satisfy some requirement.
Anyhow, if we're going look to architecture/building as a model for getting complex projects done, we need something like this is needed to fulfil the role of the 'plan', and the Problem Frames book is a good start.
|
|
|
|
|
The book sounds pretty dubious, but recently I've been exposed to architects and builders in the context of a real building.
Architects deal with such matters as how space is used, or how to make a space so that it can support various kinds of uses. They're aware of dimensions, of materials, of light, of acoustics, of cost, of functions, of aesthetic, of legal boundaries, of stakeholders, of how people interact with spaces, and all that sort of thing. Ultimately they are great at devising trade-offs and their knowledge is extensive.
Builders however, when told to build a wall right there, are thinking about quantities of materials, where to get them from, of how things will joined, of angles and frames and cladding and hinges, the order of operations, whether the stuff will fit through the door on the way in, and who's going to hold that while another person fastens it.
It's actually quite amazing watching how they are so complementary yet also quite ignorant of the domain of the other specialist. Yet somehow the building gets done.
That co-operation is partly facilitated by a drawing, and partly through them each each talking to the same stakeholders. But wait, there is another specialist too! The draftsman makes a drawing, and he/she is actually very selective in what each drawing is 'about' and 'for' and therefore what it includes or excludes. A set of drawings is typically needed to establish context, indicate dimensions/boundaries/locations, label space usage. These drawings will each focus on different features/aspects of the building.
One of the most marvellous books I ever read that I felt got close to this 'plan' is now out of print (last time I looked): "Problem Frames" by Michael Jackson (no, not that Michael Jackson). It conceives of domains and machines connected by phenomena, and explicitly describes the software task as "configured this machine to ...". So when writing a browser app, it would very specifically call out the user browser (or the mobile device, if warranted) as a machine in which the programmer needed to produce some effect, in order to satisfy some requirement.
Anyhow, if we're going look to architecture/building as a model for getting complex projects done, we need something like this is needed to fulfil the role of the 'plan', and the Problem Frames book is a good start.
|
|
|
|
|
Titles, in general, are meaningless crap. Either a person is skilled in some area(s) of development or they're not.
Often, those people who have titles like 'architect' or 'senior' are also the most skilled. But, it's not infrequent that it's someone who's just been around the organization for a long time, regardless of level of skill.
|
|
|
|
|
Software as an Engineering discipline is dubious.
Unlike many physical engineering projects, like building a road or house, software is very very fragile.
That includes if you do error handling. If 1 part of a process is unable to work, the whole process in unable to finish.
But in a house, the whole house standing up does not rely on all the bricks. A well engineered house can still stand up if a number of bricks fail.
Also the person interacting in with said house is able to self mitigate issues. If 1 stair failed, you can step over it.
Then you have many oversight and defined government requirements which software does not have (in most countries, I hear Canada you need an actual certificate to call yourself Software Engineer.)
Contrast most software with how HTML is so very forgiving. Missing one end tag, it will still figure something out to show the user.
Javascript - missing bracket, nope its wrong.
python script forgiving
java/c# compilers - nope, you need semi-colon despite that it could figure out that new line and variable declare was started.
Bridges - redundancy of support is not equal to duplicating a website so if one server down the other picks up. That would be having multiple bridges.
Software Architect is least of the job titles of issue.
|
|
|
|
|
Quote: the author likens Software Development & Design to the realm of Artistic Endeavour.
Sounds like baloney meant to appear to make some new idea to sell the book that contains it.
"Architect" and "engineer" come from the construction industry. Architecture is a science that also involves art. Art can design a building on the outside, but without the science, the building won't stand. Architects work with engineers to make sure the building as a whole works and is safe.
That analogy works perfect for building software - "virtual" buildings. The mistake is in thinking that these are separate jobs requiring separate people, as it is in construction. There are rare occasions when the workload justifies separate people, but for the most part, they are roles in which a senior-level person should be proficient. Use the architecture role to manage requirements, design the application, often without regard for the particular tech stack to be used. Use the UI/UX engineer role to improve the architectural UI design. Use the QA engineer role to define the core of the testing. Use the software engineer role to design the workflow, interfaces, and objects across the n-tiers that are needed. Use the agile manager role to manage how agile is implemented. Use the PM role in your coordination with the non-technical "stakeholders". And take on the programmer role to help out with the coding since hands-on experience benefits every other role.
All those roles should be expected in a senior-level professional in the software industry.
|
|
|
|
|
|
I was thinking about:
Quote: When Black Friday comes
I'll stand down by the door
And catch the gray men when they
Dive from the fourteenth floor
|
|
|
|
|
|
|
You mean a reboot of the planet earth? 
Sorry for the 'laugh'  ....
|
|
|
|
|
Humans: "Hey! Let's keep partying until we suck every last drop out of this planet."
Mother Nature: "Last orders gentlemen." 
|
|
|
|
|
Mother nature will win sooner or later I think. With or without us 
|
|
|
|
|
0x01AA wrote: Mother nature will win sooner or later I think. With or without us
Specially without us.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Makes sense 
|
|
|
|
|
The weird thing is that it's not "persistence" or "cunning" at all: the sheer number of new hosts - us - means it breeds like crazy, and that means it mutates like crazy.
To knock it down to the level of flu or even a cold, all we have to do is reduce the number of hosts to an absolute minimum - that's what vaccines, lockdowns, masks, handwashing is all about ... get it down to that and it mutates more slowly because it breeds more slowly and the impression of cunning vanishes.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Only to emphasize again (for everybody who feels to be save because of vac): If you are vaccinated you can still be the host. Vaccination is only an -important- part of many measures that you mentioned.
|
|
|
|
|
And being unvaccinated is just prolonging the disruption ... somewhat antisocial I feel.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
