A malfunction that shut down all of Toyota Motor's assembly plants in Japan for about a day last week occurred because some servers used to process parts orders became unavailable after maintenance procedures, the company said.
it’s excellent in the hands of those who have enough experience and understanding of concerns at all levels to use it but they’re generally either used by people without that experience
You’re just saying that skilled people can do stuff better than unskilled people. This is hardly a software engineering issue. It is common in all aspects of life
The difference with software engineering is that the field is still relatively young enough to not have figured out a working model or sets of working models (unlike farming, for example, or finance).This field is realistically 30 years old during which it continuously evolves and redefines itself so it’s still not going to produce good working models.
Agile, since you picked on it, is very difficult to implement because it specifically relies on engineering figuring out how to work and how to deliver. It’s really not a model at all. It’s just a set of guidelines meant to create the environment in which the figuring out happens. It’s no wonder that it only works when people have the ability to figure it out.
I’m not saying whatever you’re trying to put in my mouth.
In very very VERY simple terms:
A software engineer with half the experience of somebody at a technical architecture level isn’t half as capable a technical architect- such a person is pretty much totally incapable in that domain.
Experience isn’t linear, it’s a sequence of unlocking and filling up of experience in domains which are linked but have separate concerns, with broader and broader scopes that go way beyond the mere coding, and this non-linerarity happens because it takes a while before people merelly become aware of the implications at the level at which they work of certain things outside their scope of work.
So if you’re not at the level of even being aware of how the end users of a software being developed themselves have very vague and extremelly incomplete ideas of what they need as software to help the in their own business process, then you can’t even begin to see not only what’s the point of certain practices around things like use cases, but even the entire need and suitability of Agile versus other development processes in a specific project and environment, so you’re not at all qualified to decide which parts of that to do and which not to do in the specific situation of your specific project, or even if Agile is the right choice.
People who don’t even know about the forms of requirements gathering in different environments can’t even begin to evaluate the suitability for their environment of a Process such as Agile which was designed mostly to address the “fast changing requirements” project situations, which are the product of various weakness in requirements gathering and/or fast changing business needs, which at the development side snowball into massive problems when long-development-cycle processes such as waterfall are used (for example when supposedly “done projects” do not produced something that matches stakeholder needs, hence end up having to be “fixed” so late in the process that it massivelly disrupts the software at a design and even architectural level, introducing massive weaknesses in the code base and code spaghettization, hence bugs and maintenability nightmares).
You’re just saying that skilled people can do stuff better than unskilled people. This is hardly a software engineering issue. It is common in all aspects of life
The difference with software engineering is that the field is still relatively young enough to not have figured out a working model or sets of working models (unlike farming, for example, or finance).This field is realistically 30 years old during which it continuously evolves and redefines itself so it’s still not going to produce good working models.
Agile, since you picked on it, is very difficult to implement because it specifically relies on engineering figuring out how to work and how to deliver. It’s really not a model at all. It’s just a set of guidelines meant to create the environment in which the figuring out happens. It’s no wonder that it only works when people have the ability to figure it out.
I’m not saying whatever you’re trying to put in my mouth.
In very very VERY simple terms: A software engineer with half the experience of somebody at a technical architecture level isn’t half as capable a technical architect- such a person is pretty much totally incapable in that domain.
Experience isn’t linear, it’s a sequence of unlocking and filling up of experience in domains which are linked but have separate concerns, with broader and broader scopes that go way beyond the mere coding, and this non-linerarity happens because it takes a while before people merelly become aware of the implications at the level at which they work of certain things outside their scope of work.
So if you’re not at the level of even being aware of how the end users of a software being developed themselves have very vague and extremelly incomplete ideas of what they need as software to help the in their own business process, then you can’t even begin to see not only what’s the point of certain practices around things like use cases, but even the entire need and suitability of Agile versus other development processes in a specific project and environment, so you’re not at all qualified to decide which parts of that to do and which not to do in the specific situation of your specific project, or even if Agile is the right choice.
People who don’t even know about the forms of requirements gathering in different environments can’t even begin to evaluate the suitability for their environment of a Process such as Agile which was designed mostly to address the “fast changing requirements” project situations, which are the product of various weakness in requirements gathering and/or fast changing business needs, which at the development side snowball into massive problems when long-development-cycle processes such as waterfall are used (for example when supposedly “done projects” do not produced something that matches stakeholder needs, hence end up having to be “fixed” so late in the process that it massivelly disrupts the software at a design and even architectural level, introducing massive weaknesses in the code base and code spaghettization, hence bugs and maintenability nightmares).