What you won't do however, is work insane hours to get something done because management changed scope or requirements at the last second but kept the deadline. The flavor of agile development that most shops seem to devolve to is one where management gets the part that they can update requirements based on new information, but deadlines are the same and costs need to constantly be cut.

My personal belief is that our industry tends towards less experienced workers because they put up with shit managers more and can be used to cover for their issues. It's anecodtal only, but I have never heard management decide that their deadlines we're improbable if not impossible when bugs get through. It's always just explained away with platitudes about code quality that suddenly dont matter when that requires more money or more time

Call me cynical, but I am always surprised when people sincerely appeal to "agile/scrum values" of team autonomy or whatever to contest management diktats because, like... isn't it totally predictable that that part will be ignored whenever it is inconvenient?

Agile is cargo cult. Customers are not agile to your fuckups. Competitors are not agile to your "scope creep". You know what is the current most agile company in software? Microsoft. You know why? Because no matter how much it fucked up its business is so huge and so vast that it did not matter. It makes money. But even Microsoft is starting to feel the need to deliver as otherwise it is going to become IBM or Xerox.

Agile is like dieting, simple but hard and requiring a lot of discipline. Very very few companies are any good at it but done well, it's a complete transformation.

I think it's more like a cult, where it's supposed to solve all your problems and any problem you identify with it just proves you aren't doing it right.

It is, at best, a different set of trade offs. What it has become is like you said, some sort of cult where management gets everything they want and don't have to pay any costs.

I've worked at two places where my tech lead at least recognized that if scope or requirements changed then deadlines changed. Now I am at a place where agile is just a word thrown at any problem and now we have things like being asked to integrate third party tools that we don't receive until a week before the deadline. My team stayed till 2 am and was back in at 9am the next day and _literally no one_ saw a problem because it's "agile" and that's what you do when your agile

I've been lucky enough to be on projects where it's done well (not scrum) and would never go back after working that way.

I've experienced "no methodology; just people kind of describing what they want and you make it up as you go along" and Scrum and I prefer the former, but I suppose it's possible that someone out there is doing Agile in a way that is better than the one I learned in a bunch of excruciatingly boring training sessions from consultants.

e: Actually I did Kanban too and that was OK, but that is a lot closer to the "no methodology" thing and anyway doesn't involve you making decisions like "oh, can't start working on that, because the sprint is almost over."

Kanban is very much Agile. Scrum can be implemented in a variously heavy to lightweight way, though FWIW I found having leftover time at the end of a sprint that could only be used for non-business-facing work (e.g. improving the build system, refactoring of code that wasn't immediately being worked on) to be very valuable.

I guess the cynic in me finds it predictable that most Agile shops (at least IME) would be doing Scrum and not something like Kanban, even though it largely works against the supposed core values of Agile.

Yep Kanban is the way to go, focus on flow, small batch sizes, reducing waste of wait times and handovers. Look at cumulative flow and rightsize stories instead of fretting over estimation, points, burndown, and all that mini waterfall that scrum seems to entail. Takes most of the drama and hysteria out of delivery.

Ultimately it makes no difference whether you're doing "story points" or estimates in units of time. All that's going to happen is they'll be converted to units of time in a way you don't quite understand. It's just so naive to believe any of the Scrum promises.

It's why we always do rightsizing and never numerical estimates. You can calculate delivery dates by counting stories * average story time - very fast, very simple, and amusingly at least as accurate as detailed time estimates. Has an interesting side effect of tying scope to delivery. So if you want to reduce delivery time, it's clearly understood as under control of stakeholders and done by dropping stories. If you can't rightsize to a reasonably narrow range (we use 1-5 days) and have to estimate (e.g. sifting stories for prioritisation purposes), t-shirt sizing usually works ok and gives the required info without opening it to abuse.

As an overworking tryhard chronic cover-upper, this hits dishearteningly close to home.

Not many 20-something have the mental strength to insist on the dealine moving if such big change requests come in late. As a contractor you'd insist on the client to pay that extra work and time.

I totally agree that measuring productivity by the amount of working hours is ridiculous.

However, it is important to realize that you are not competing with the 20-somethings or the ones that are fresh out of college. You are competing with the ones that have already a good amount of experience (let's say 7-10 years) but are still in the beginning of their careers.

If they are minimally talented, they will probably produce code just as good as yours, yet they will probably (a) work for less money and (b) still be single and (c) more dedicated to work and (d) more tolerant of bullshit asks from the employer. Those are the ones that eventually fill positions as "Sr. Engineer" and crowd out the older ones.

which means you're competing for principal and architect level jobs, which are much more restricted.

> I totally agree that measuring productivity by the amount of working hours is ridiculous.

The alternative is P&L and boy grey beards don't want P&L based measurements

There are only two things that are measurable:

1. Time

2. P&L

P&L measurement would destroy majority of the old timers unless the old timers work the same little money fresh out of college people do.

I'm not attacking you here (and in fact I agree with you), but from a manager's perspective, I need one guy like you to design it in an architecture modeling tool and 8 young code monkeys to do all the boring work of building and testing it. You can do the code reviews to make sure they don't do stupid shit.

The thought is that a team of greyhairs never ships anything, and a team of youngsters ships garbage. But it's better to ship garbage than nothing, hence the bias.

I STRONGLY disagree.

My experience is that programmers who become "architects" and are only responsible for design and code review tend to go downhill in their skills. It SEEMS like an efficient way to use experienced people, but it is actually an anti-pattern. Their tendency is to develop ideas that sound good but don't work well in practice, and there is no direct way to correct the mistake. (Any time it doesn't work, the tendency is to blame the implementer. And there is usually enough to blame that their own contribution to the problem gets missed. You're less likely to miss the problem when YOU are trying to make the implementation work.)

In fact the problem is sufficiently bad that in interviews it is important to have people actually write code to show that they still can. When you get an "architect" who takes offense at the exercise, that's a non-hire. They might have been good 10 years ago, but they aren't worth hiring now.

This was something I'd sort of noticed, but didn't become conscious of until I worked at Google. There they were very conscious of the phenomena. Every programmer from the most junior to the most senior (for the record that would be Jeff Dean) writes code. If you're not willing to write code, you're not a hire.

That said, the exercise goes both ways. If I interview with an employer and I discover that they design things up front as UML diagrams, odds are that this won't be a workplace that I want much to do with. If I'm working in a job and they force me into an abstract architecture role like you describe, I'm going to quit and find a better job.

My title is "architect". I use scare quotes because I agree with what you wrote and I dislike being associated with the type of people and the jobs that make it true. I, also, only work at places where the interview is sufficiently technical and there are no separate design-only roles.

It's been surprising to me how much I've had to fight people on this issue in the past.

I agree with you.

The thing is, software architecture kind of the same job as coding. So what the "architects" you describe really do is equivalent to writing code on a piece of paper. That is, doing one of the most mentally demanding jobs imaginable, but without the tooling to protect them from their own confusion. No surprise then, that it later turns out the architecture doesn't make sense. Without a tool like a compiler to call you on your bullshit, it's too easy to start engaging in fuzzy thinking, and the longer you're not exposed to such practical verification, the more your thoughts will become fuzzy.

<three letter hat on>

1. All of you are overhead.

2. Customer is the profit.

3. Now how do I get (2) to be higher than (1) before we run out of money?

</three letter hat off>

I mean; that’s fine. I wouldn’t want that job either — it’s why I got an MBA, got out of the tech side and now actually have power over hires/fires and product direction. But unless you’re directly bringing revenue in the door, you are a cost item to be cut. As soon as they can find someone cheaper, they will.

Don't worry, I'm OK.

Lots of companies are smart enough to figure out that it is cheaper to hire competent people than to accept the boneheaded mistakes that the cheapest warm body would make.

Besides, the ones that don't figure it out are no fun to work at. Who wants to be on the side that's bound to lose in the long run?

I just wish that they did less collateral damage on their way down.

> As soon as they can find someone cheaper, they will.

This applies to everyone everywhere, and particularly positions that anyone with basic language and reasoning skills can fill (PMs, MBA types, etc)

Naw, the MBA jobs are all about personal brand and networking. When you make the rules, they tend to benefit you.

> MBA jobs are all about personal brand and networking

No disagreement there. Just in my experience those jobs are either the first or second to go when things get tough - often because there's an MBA somewhere near the top who recognizes how replaceable all the rest are.

Yeah, but these jobs also often have contracts with severance packages. Executives (VP and above) are typically hired under fixed contracts that make it very expensive to get rid of them. You can demand these things if you have specialized knowledge, credentials, and relationships.

> Executives (VP and above)

Aren't you being overly restrictive in scope here? Many executives are MBAs, but most MBAs are not executives.

True; but stalling out in middle management is never the reason people get an MBA.

Waiting tables in Hollywood is never the reason people take up acting, and yet so it goes.

Anecdotally, I know several full time top 10 grads who aren't exactly on the fast track to the c-suite, and I assume this is even more true for the broader pool of MBAs.

Can we just be honest?

Us older folks won't build things we know doesn't work against synthetic deadlines, then work overtime to fix what we knew wasn't going to work in the first place, while taking the blame politically.

Engineering has in my lifetime become "unwinnable." I'm either not "a team player" or "being negative" for planning for reasonable failure scenarios. Then politically I still take the heat when they happen.

This is not a quixotic aspect of engineering, it is a design feature at bad employers. "Heads I win, tails you lose"

Engineers aren't blameless, here. In fact they're at least as much the problem as "bad employers". Constantly seeking to use the latest shiny tech toy whether it's appropriate or not (e.g. "Big Data" tools to run stuff on a few GB of data) is a thing, especially in the Bay Area. It leads to a bunch of people with a small amount of shallow experience in a large number of soon-to-be-deprecated technologies. Few want to do the hard work of actual engineering.

Also, that the product is 10% better/more stable/whatever frequently does not translate into even a 10% increase in sales. So it's not worth it (from the business' perspective) to invest in that quality. Pick some other arbitrary point (e.g. 20% better/20% boost in sales, etc.), right down to some threshold whereby the company simply doesn't even have a product that can be demonstrated.

> Also, that the product is 10% better/more stable/whatever frequently does not translate into even a 10% increase in sales. So it's not worth it (from the business' perspective) to invest in that quality.

Here is the core of the problem, and it's more of an incompatibility of goals than errors of one of the parties. Businesses want to make money. They usually don't give a flying fuck about what their product is or does beyond the point it gets sold. Does it waste users' time and piss them off? They paid us, which means they value it, so everything is ok.

Engineers, on the other hand, tend to care about what value the product actually provides to their users. So they would rather invest effort in making the product better for the users, instead of making it better for sales team to sell.

I don't really see the way out of this conflict. The engineers are right, but the businesses are right too - it's the business that pays and suffers (some of) the consequences, so it's the business that gets to tell engineers what to do, and not the other way around. If CEO is making a stupid decision, that's on CEO.

The way I see actually useful software gets done, it's outside or on the side of a business, not within it.

Good point about incompatible goals. One way out is to align the value as perceived by users with the value as perceived by engineers. If users aren't willing to pay for reliability/security/etc. then it's rational for management to devalue those properties.

I'm not optimistic that this will happen. Anecdotally, I expound to acquaintances the risks of unprotected PII or questionably-secured home security apps, but convenience seems to outweigh such concerns.

Regulation is one approach to solve asymmetric information transactions. I don't see how that could be applied in general to software quality, but it could target the cases that have severe or widespread effects.

The value the product actually provides to users is the viral coefficient. Lots of companies value growth. Find one.

Growth has been completely gamed already. Just look at most startups.

I agree, but this is essentially a tragedy of the commons problem being exploited by management.

Keeping up with new technologies is essentially a proxy question for, "How much free time do you have that I might exploit later?"

Ok, but his specific complaint was that planning for reasonable failure scenarios makes you labeled not "a team player" or "being negative". And I have seen this happen, it is true problem. Someone else refactoring badly does not cancel that systemic problem out.

>>> Also, that the product is 10% better/more stable/whatever frequently does not translate into even a 10% increase in sales.

It's quite common for things to generate or save money. Sadly, most engineers won't bother counting the results related to their work.

You hire wrong grey hairs, most new people never shipped anything. Person with 10-20 years experience probably shipped a TON of stuff. This is the key thing to look when hiring, people who shipped things and like to ship things.

On other hand there tons of grey hairs who never shipped anything and are useless as new grads are.

> But it's better to ship garbage than nothing

Yup, this is the software industry boiled down to the basics.

well i think this is certainly the problem--ie, now "garbage" looks justified

but those aren't really the two alternatives, are they--ie, crap code or nothing?

it might be in the very short terim (ie, by this friday)

but over any other span of time, the choice is more like:

ship crap code in 30 day, followed by 50% of the team's resources spent bug fixing (which can often be cleverly disguised as new features) for the next 90 days

OR

ship high quality code in 45 days

Sadly, it's hard to convince people that doing things right is better than doing them wrong, but quicker.

That customer needs this code on the 1st, that is a hard and fast deadline! So shit is churned out, and handed over on the 1st. Then, three or four 1sts later, the customer finally gets their shit together and deploys it, and, voila, it is shit. And the cycle continues, as the scramble ensues to patch the shit by the 15th with yet more shit. And you end up like the little Dutch boy at the dike, except instead of fingers you're using hotfixes made of excrement.

> You can do the code reviews to make sure they don't do stupid shit.

This does not work. Your code monkeys will get demotivated fast and wont be able to learn anyway. The one architect guy will because increasingly out of touch and his code review will become pointless red tape fast.

> The thought is that a team of greyhairs never ships anything, and a team of youngsters ships garbage. But it's better to ship garbage than nothing, hence the bias.

Why would greyhairs never ships anything? I dont get it. My experience was that young people need more supervision to not get demotivated and to actually finish it. (on average)

I seem to recall an episode of the A16Z podcast where Adrian Cockcroft of Netflix explained they were top heavy on senior engineers when they began moving to microservices. Didn’t seem to slow them down but I could be misremembering.

They only hire senior engineers.

I don't know what that really means though. People who are smart, hard working, and get the right jobs can get a senior title in 5-6 years at the big companies.

I know someone hired at Netflix who is belligerent, inexperienced, and lazy. He is a senior engineer there. Titles don’t really matter much at the end of the day.

Indeed! Over time I've become more and more aware (and proud) of the things I left out. As a young programmer, I would be far more proud of the things I included.

The shipped project is one branch of an extremely large tree of possibilities which a younger, less experienced programmer would have taken a very long time to explore and discard (which I know for certain because I was that programmer).

It's weird how that works... I try to avoid unneeded complexity as much as possible for as long as possible... and when I do need complexity, I try to make it as easy to use as possible, so that it's less in your face on reuse.

I'm consistently amazed at how much of a pain in the ass things tend to get when people try to build solutions in their early 20's, vs 30's and now in my 40's. Not to mention how much my viewpoint has changed in the past 20+ years in software.

I'm pretty happy when I can remove a bunch of dead/unused code trees, commented out swaths of crap, and refactor portions of a codebase into 1/5 the size.

I rewrote a 900 line class today by writing one generic function that encapsulated a pile of common logic that the monstrosity had copied and pasted with slight changes over, and over, and over, and over, ad nauseum, and wound up with less than 100 lines of code. What a glorious day.

Indeed. When you see some of the waste that goes on - whole projects going in the wrong direction and having to be largely reworked. And the people in charge will never admit they made an error in how they set up teams, and that it's the 'greyhairs' getting involved and rescuing projects over and over again.

If we assume this is all 100% true...there's still no way to be sure during an interview.

There's plenty of shitty older devs. And if they're old enough they're a protected class which will make things very awkward if you hit a shitty one. And with the newer generations, there are plenty of 18 years old that will run circle against more experience devs, nevermind mid 20 ones. There's of course plenty of crappy ones too. So all things equal, but with a different salary, which one do you pick if you're a naive hiring manager?

Fortunately I now work for a company where this is a non-issue. While we definitely hire a ton of new grads, we'll never say no to older/more senior candidates (and sure could use more). Which is good, because I'm getting dangerously close to my 40s.

>It's about producing working code

I propose that working code is necessary, but not sufficient.

maybe they discriminate because you call the designs of other people shoddy.

I'm only being half snarky. Large chunks of these threads end up as people bashing young people for being idiots for various reasons.

I do believe that discrimination is an issue, but you also just don't need that many seniors. If you have a couple to make sure designs are reasonable, catch mistakes, and mentor the junior people then that seems pretty sufficient.

If you have 5 seniors and a junior you get stuff done, but the junior person quits because they don't see any point in sticking around on a team where they aren't being challenged because someone more senior always gets to do it. Someone else will give them the challenge they want. I'm moving on right now exactly because of this.

> maybe they discriminate because you call the designs of other people shoddy.

I'm primarily calling my designs shoddy when I had only a few years of experience.