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.
It's been surprising to me how much I've had to fight people on this issue in the past.
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.
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>
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.
This applies to everyone everywhere, and particularly positions that anyone with basic language and reasoning skills can fill (PMs, MBA types, etc)
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.
Aren't you being overly restrictive in scope here? Many executives are MBAs, but most MBAs are not executives.
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.
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"
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.
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.
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.
Keeping up with new technologies is essentially a proxy question for, "How much free time do you have that I might exploit later?"
It's quite common for things to generate or save money. Sadly, most engineers won't bother counting the results related to their work.
On other hand there tons of grey hairs who never shipped anything and are useless as new grads are.
Yup, this is the software industry boiled down to the basics.
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
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.
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 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.
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.