Comment

Comment on All of Japan's Toyota Assembly Plants Shut Down for a Day Because Their Server Ran Out of Disk Space

In my own impression from the side of software engineering (i.e. the whole discipline rather than just “coding”) this kind of thing is pretty common:

Start with ad-hoc software development with lots of confusion, redundancy, inneficient “we’ll figure it out as when we get there” and so on.
To improve on this somebody really thinks things through and eventually a software development process emerges, something like Agile.
There are lots of good reasons for every part of this processes but naturally sometimes the conditions are not met and certain parts are not suitable for use: the whole process is not and can never be a one size fits all silver bullet because it’s way to complex and vast a discipline for that (if it wasn’t you wouldn’t need a process to do it with even the minimum of efficency).
However most people using it aren’t the “grand thinkers” of software engineering - software architect level types with tons of experience and who thus have seen quite a lot and know why certain elements of a process are as they are, and hence when to use them and when not to use them - and instead they’re run-of-the-mill, far more junior software designers and developers, as well as people from the management side of things trying to organise a tech-heavy process.

So you end up with what is an excellent process when used by people who know that each part tries to achieve, what’s the point of that and when is it actually applicable, being used by people who have no such experience and understanding of software development processes and just use it as one big recipe, blindly following it with no real understanding and hence often using it incorrectly.

For example, you see tons of situations where the short development cycles of Agile (aka sprints) and use cases are used without the crucial element which is actually envolving the end-users or stakeholders in the definition of the use cases, evaluation of results and even prioritization of what to do in the next sprint, so one of the crucial objectives of use cases - the discovery of the requirement details by interactive cycles with end-users where they quickly see some results and you use their feedback to fine-tune what gets done to match what they actually need (rather than the vague very high level idea they themselves have at the start of the project) is not at all achieve and instead they’re little more than small project milestones that in the old days would just be entries in Microsoft Manager or some tool like that.

This is IMHO the “problem” with any advanced systematic process in a complex domain: 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 (often because managers don’t even recognize the value of that experience until things unexpectedly blow up) or by actual managers whose experience might be vast but is actuallly in a parallel track that’s not really about dealing with the kinds of concerns technical concerns that the process is designed to account for.

source

Sort:hotnew top

RidcullyTheBrown@lemmy.world ⁨1⁩ ⁨year⁩ ago

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.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.

source
- Aceticon@lemmy.world ⁨1⁩ ⁨year⁩ ago
  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 concern, 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 of certain things outside their scope on at the level at which they work.
  
  So if you’re not at the level of even being aware of how project end users themselves have very vague and extremelly incomplete ideas of what they need as software to help the in their business process, then you can’t even begin to see not only what’s the point of certain practices around 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 snowballing into massive problems when long-development-cycle processes such as waterfall are used.
  
  source