Comments by "TheEvertw" (@TheEvertw) on "Thriving Technologist" channel.

Something I would add is that a great Software Architect takes a risk-driven approach to coding, i.e. he will be aware of the technical and other risks surrounding a project and try to nail the biggest risks down first. That means that he will do performance and scalability tests early in the project if that is expected to be an issue, or mock-up user interfaces to verify their design with actual users, or make a proof-of-concept, design-space exploration, etc, etc, etc. In systems design, he will be aware that the plans other teams make have risks in them and help them nail their risks as quickly as possible. For example by mocking a robot's control software so that it can be put through a realistic movement scenario early on in prototyping. A colleague of mine did that to find that a vacuum pump was under-dimensioned, something that would have put the project back several months had it been discovered later on. (note that "he will make" usually means: "he/she will let the team make")
14
The USA is REALLY messed if they reward people who exude unwarranted self-confidence, instead of those who are truly skilled. That is how you end up with a Trump as President. I am sorry, but I can not blame good developers for being passed over. I will squarely blame an abusive management culture. Managers who pass over good people in favour of posers do not deserve good developers. Pass over good people and they walk away. I know this video is not about politics, but you point out the same flaw that is destroying you politically: preferring optics over substance. And in case you Amuricans are too thick to realise this, the rest of the world thinks Trump is a joke. A dangerous joke, but a joke nonetheless. And we are laughing at you for the 50% still supporting this joke and thinking he is suitable for anything else but prison.
1
This is important, but not an Architecture job per se. More like a Lead Developer / Senior Developer. But if there is no-one else who will push back, the Architect definitely should.
1
True if the re-formatting is done by an automated tool. If the re-formatting is done manually, that is refactoring and should be done gradually each time a part of the code is touched for regular development. That would mean there is a mix of reformatting and new functionality.
1
@brettmurphy7588 every serious project should have either a precommit check on coding guidelines, or an automatic reformatting step. If you add it late in the project, that means a single commit to update code according to the (new) guidelines, which means there is no reason not to do it.
1
The USA workers need to understand that if you don't get paid for the hours, you won't do the work. Overwork is a tactic whereby managers cut pay -- by hiring to few people to do the work and expecting them to do the work anyway.
1
Disagree with estimating unexpected meetings. You can not estimate the unexpected. This is why in estimating, you should not estimate in hours but in fuzzy sizes. As in Small, Medium, Large, Huge. Or the vague numbers in the Fibonacci sequence (1, 2, 3, 5, 8, 13) used in Scrum Poker. Or "Function Points". Managers can track progress and learn from that how quickly the team handles each type of task on average. Any other form of estimating creates false expectations.
1
While I agree with your advice to refactor incrementally, I don't agree with hiding refactoring or technical debt from management. It is a sign of a dysfunctional management - developers relationship. Managers are also responsible for technical debt, and need to manage it as well as new functionality. From the way you present it, it seems that technical debt is only the responsibility of coders, as in "Bad Coder!". Most technical debt is the result of getting to know the problem space better, and could not have been prevented. That makes it a shared problem, not something for which coders should be blamed.
1
@HealthyDev "Technical Debt" is a vague concept, which was invented to explain a source of unexpected delays to managers, and give them tools to manage that. If architecture merely evolves, I would classify the backlog in keeping up as "technical debt", to be addressed as new functionality is put on the new designs. During development, implementing new features should reduce technical debt, not increase it. Radical architecture changes require custom approaches, which may including putting a project on hold while the ramifications are analyzed & the project is re-organized.
1