[nofunsir]

Unit tests does not make Software Engineering. That's simply part of the development phase, which should be the smallest phase out of all the phases involved in REAL Software Engineering, which is rarely even done these days, outside of DO-178 (et al) monotony. The entire private-to-public industry has even polluted upper management in defense software engineering into accepting SCRUM as somehow more desirable than the ability to effectively plan your requirements and execute without deviation. Yes it's possible, and yes it's even plausible. SWE laziness turns Engineers into developers. Running some auto-documentation script or a generic non-official block diagram is not the same as a Civil PE creating blueprints for a house, let alone a mile long bridge or skyscraper.

[nerdponx]

As far as I understand the idea behind scrum it's not that you don't plan, it's that you significantly shorten the planning-implementation-review cycle.

[brobdingnagians]

Perhaps that is the ideal when it was laid out, but the reality of the common implementation is that planning is dispensed with. It gives some management a great excuse to look no further than the next jira ticket, if that.

The ideal implementation of a methodology is only relevant for a small number of management who would do well with almost any methodology because they will take initiative to improve whatever they are doing. The best methodology for wide adoption is the one that works okay for the largest number of management who struggle to take responsibility or initiative.

That is to say, the methodology that requires management to take responsibility in its "lowest energy state" is the best one for most people-- because they will migrate to the lowest energy state. If the "lowest energy state" allows management to do almost nothing, then they will. If the structure allows being clueless, a lot of managers will migrate to pointy haired Dilbert manager cluelessness.

With that said; I do agree with getting products to clients quickly, getting feedback quickly, and being "agile" in adapting to requirements; but having a good plan based on actual knowledge of the requirements is important. Any strict adherence to an extreme methodology is probably going to fail in edge cases, so having the judgement of when to apply which methodology is a characteristic of good management. You've got to know your domain, know your team, and use the right tool for the job.

[nerdponx]

> the reality of the common implementation is that planning is dispensed with. It gives some management a great excuse to look no further than the next jira ticket, if that.

Maybe I'm just lucky but I've never experienced this. If anything, the companies I've worked for didn't do anything particularly agile, and were often deliberately trying to change habits and workflows to be more agile. This often came down from engineering managers who wanted to know how the whole project was going to go the day it started, so they could report upwards with a delivery timeline.

[brobdingnagians]

I hear you. I feel like my personal experience has definitely influenced my view. I've seen management who want to have a timeline and a deadline from day 1, but don't want to put any effort into thinking out how they could allocate resources to make that happen or what was required of them. So they just ask someone else for a calendar and ask if someone's already made a ticket.

[nofunsir]

I've got a bridge to sell. It's made from watered-down concrete and comes with blueprints written on site. It was very important to get the implementation started asap to shorten the review cycle.

[nerdponx]

In a way, bridges are kind of agile. There are many stages of things like site selection, geological testing, architectural and engineering design decisions, computer simulations, traffic forecasting, etc. All of that happens in a feedback loop with the customer (eg some state DOT).

[zanellato19]

Nonsense. I know and talk to multiple Engineers all the time and they all envy our position of continuing to fix issues in the project.

Mechanical engineers having to work around other component failures all the time because their lead time is gigantic and no matter how much planning they do, failures still pop-up.

The idea that Software Engineering has more bugs is absurd. Electronic engineers, mechanical, electric, all face similar issues to what we face and normally don't have the capacity to deploy fixes as fast as we do because of real world constraints.

[nofunsir]

Not nonsense. Don't be reductive.

[zanellato19]

I think you are being reductive on your original comment. The idea of cycling planning and implementation is nothing new, and quite used on the other disciplines. Saying that agile is the problem is misguided and pointing to other engineering disciplines for "they do it better" is usually a sign that you don't talk to those engineers.

Of course we can plan things better, but implementation does inform planning and vice versa and denying that is denying reality.

[nofunsir]

I don't think this is productive, since you're so adamant [1] that "big C memory safe programs don't exist." I know for a fact they do. Most of the software you won't ever see. What do you think powers the most critical sytems in, say a fifth gen fighter, or the software that NSA relies on in their routers?

I'll give you a hint. It's neither rust- nor scrum-based. I'd rather change careers or retire than work another day doing scrum standups.

[1] https://news.ycombinator.com/item?id=45353150