[riprowan]

> As a coder it is important to understand that most problems in technology are not solved with more code, but less. That you will generate less code at 50 should be seen as a benefit.

This is precisely my argument as a generalist.

I may not write code as fast or even as elegantly as I once did, but I'm much, much better at "seeing around corners" to avoid problems, and I'm much more likely to "build the right thing" due to my very broad but not deep technical base. I do not fall into the trap of "when all you have is a hammer everything looks like a nail."

> there is very little that's happened in the last 30 years that is genuinely new

This is true, but try to convince your 20something peer group of it. They are all convinced that their technical skills are revolutionary.

I studied waterfall systems engineering in 1998. But at the same time they also taught "RAD" iterative waterfall, or the precursor to Agile. I ran with RAD, and made it mine, so I've been doing something very similar to "Agile" for two decades. However, I still think that Gannt charts and top-down planning have value.

Showing that shit to the wrong 20something developer is a great way to be excommunicated.

[webmaven]

> However, I still think that Gannt charts and top-down planning have value.

Of course they do. What you're seeing is a backlash to the way GANTT charts have been misapplied to projects that are less well defined, and to managers that ask for estimates and then are unpleasantly surprised when an estimate isn't entirely accurate.

Anyway, if you want to provide the same sort of value but present it in a different format, consider using a network diagram or a user story map[1].

[0] https://www.quora.com/What-are-the-best-alternatives-to-usin...

[1] https://www.scrumalliance.org/community/articles/2013/august...

[riprowan]

> What you're seeing is a backlash to the way GANTT charts have been misapplied to projects that are less well defined, and to managers that ask for estimates and then are unpleasantly surprised when an estimate isn't entirely accurate.

You think I don't know this?

I think you missed the point :(

(As an aside, in my experience, network diagrams and user-story maps pale in comparison to Gantt charts, as they do not effectively communicate timeline expectations IMO.)

[webmaven]

> they do not effectively communicate timeline expectations

Of course, that is in part by design.

If you are delivering solution X that is just an instance of iteration Y of system Z with a few customer-specific tweaks, Agile methods will work just fine in combination with GANTT charts, and teams that are engaged regularly in that sort of work aren't too likely to object.

However, as soon as a task is a known unknown (that is, a well characterized problem with an understood though as-yet nonexistent solution) requiring new code that isn't just a variation on familar themes (ie. whatever is the equivalent of a CRUD web application for your industry), you start having to deal with uncertainty and risk (which humans are very bad at reasoning about). GANTT charts can make things worse because they foster a false sense of control (padding time estimates by x% for example feels like it helps, for example). And if anything in your critical path is a known unknown, your timeline expectations, however consensus-driven and reasonable as they may be, are likely to get smashed to smithereens, and all a GANTT chart is going to do is tell you when your carefully constructed schedule is starting to slip.

Throw unknown unkowns into the mix (from "we haven't yet figured out how to solve this" all the way to "are we even solving the right problem"), and timelines become entirely fictional.

I am not aware of any chart format that incorporates this sort of risk and uncertainty well (FogBugz for example, which incorporates probability and risk based on an estimator's past track record, basically just sticks that data into a chart's tooltips)

Now, if you are willing to mitigate these risks by basing your timeline around deadlines for handoffs with the understanding that what gets handed off is "best effort working system in available time" (in which case continuous integration/delivery is your best friend) that's a different matter, but that just isn't how most projects are concieved or managed. Yet.

BTW, related to all this is the conflict between feature-based and time-based approaches to software releases.

[jballanc]

Right, my only quibble with your previous comment was the notion that being 50 in tech means migrating to a management role. I think that advice is slowly (hopefully) becoming outdated as there is more recognition that software engineers have more value than just the SLOC/day they produce.

[riprowan]

Ah, I see. I agree. I think "management" includes lots of quasi-technical roles, in which people and project leadership are the core skills, with one's technical base serving as a platform for managing others with highly focused technical skill sets. Hopefully you are also right that these jobs are increasingly in demand.