Archived Another day, another Intel CPU security hole: Lazy State (zdnet.com)
submitted ago by fluxusp
Posted by: fluxusp
Posting time: 2.5 years ago on
Last edit time: never edited.
Archived on: 9/14/2018 10:00:00 AM
Views: 131
SCP: 23
24 upvotes, 1 downvotes (96% upvoted it)
Archived Another day, another Intel CPU security hole: Lazy State (zdnet.com)
submitted ago by fluxusp
view the rest of the comments →
[–] 13042607? 0 points 3 points 3 points (+3|-0) ago
It basically comes to this, you have fixed deadlines every 2-3 weeks. The other issue that you work in a team and everyone in the team is equal.
The short cycle means that you never can have a well out thought design. If a but gets discovered then any fixes gets moved to another time. Could be the next sprint or 2 sprints further or even months. They just ship half tested and backed code to production. If users complain then we will fix it, if they don't then keep it.
The other issue is that since you act as a team, no one in the team will do any effort to create high quality code/product. Being a leader in the team is not accepted since everyone should be equal. Political Correctness is more important than to created good products.
What happens is what you see on a wide scale, systematic erosion of good quality products that gets fixed before it gets released. Only when they get caught with their pants down, and enough users revolt they will fix the issue.
(For the record my current team is one of the best SCRUM teams that I have worked for, my explanation here does not represent them! But the last 10 years I have been in multiple different SCRUM teams)
The idea of SCRUM is that bad developers gets elevated to better developers because the better ones will coach them. The hard reality is that a lot of developers simply does not have the mental capacity to reach the level of good developers. It is an impossible goal, so the SCRUM master will slow down the good developer to the level of the other team members. The best developer will probably say screw you to the team and leave. So you end up with the worst developers in the end. No one notices that the team is now under-performing than it should be.
How to solve?
Agility how real agile developers work. Not this over abstracted way that has no basis in reality.
What do real agile developers do?
Solutions
What has this to do with CPU's? Because they have a programmable microcode that in case they fuck it up they can fix it later on. This is the problem, no motivation to create good products in the first place.
[–] FroggyHunter ago
Thank you for your detailed and concise reply. To see if I understood your points, I tried to sum them up:
Do determine goals to meet, but do not set arbitrary time constraints. Move on when the goal is fulfilled and not beforehand.
I'm not really sure what the second bullet point is about, could you perhaps explain it in another way?
Keep your code flexible, even in later stages of a project. Orient yourself on what your superiors or clients wanted changed in the past as a baseline of which code needs to be changeable at a later date.
Know your current state of mind, be aware of your proneness to make errors in this state and choose an appropriate task to work on.
This point is another one I didn't quite grasp the meaning of. Could you elaborate on "taking responsibility"?
Shape your life outside of your job after your work, well in advance. This includes putting more or less effort into your outside life depending on how focused you need to be.
[–] 13043165? 0 points 3 points 3 points (+3|-0) ago
Maybe of interest I have 30+ years of programming experience. I lost count but worked in small companies of 3 people to the biggest companies. My range goes from scientific programming to building mailing server software that can process mails at massive scale and where you could pull the power cable without losing any mail.
I also worked with 100+ maybe even 200+ other developers. My work covers critical systems to very complex large scale systems.
Around 2000 I tried Extreme Programming where 2 developers were sitting behind one PC and keyboard.
Yes fuzzy deadlines. Dead line are good but they should be movable. The difference between success or failure can be mere minutes. The reason why all my SCRUM tasks succeed is because I only take those that I can guarantee to complete. I won't touch one that is destined to fail.
Years before I get a problem to solve, I already observe how a company functions, how the business works, how It works,.... I am going to try to predict what I will needed in the future and already start to create code that may be needed for the future. Stupid stuff like a class to measure time easily. Small parts where I experiment with that could become something I need quickly. Just like Rembrandt would have a notebook and drag quick stuff that he may later use in a master-peace)
I worked in a small company, I got burned by inheriting a project by an expert that failed at a client. So I ended up with weeks of support an no way to solve it. My code evolved to make sure that my first release will be spot on with zero defects.
I have a winners mentality. I don't want to win against my team members I don't care if they are better or worse, but I want to win the deadline with zero defects or bugs. So the mentality is to get the maximum I can get out of my body like a top athlete.
Some of my software runs on very critical systems. I take great responsibility to get the code right so that people or equipment do not get damaged. I once worked at industrial software where a fault in my code could blow up the company. Safety of people, reliability, security and privacy is important for me. However when you are in a SCRUM team it is easy to relies on the others to fix your bad code.
By reordering my social live dynamically I get the best productivity for the least stress and the best social life.
The issue I have is that this whole SCRUM madness is killing any productivity and causes enormous stress that should never been there in the first place. It is destroying my and the other team members health. However I have learned ho to deal with the kind of stress the others don't and will burn-out.