These are the things I add in when adding in a new usecase to a codename:
- Expansion of the acceptance criteria into small steps.
- Any clarifications to what we are making
- Anything I don't understand yet so i can chase up someone about it later
- As I read through the code I write up possible refactoring opertunties. (I find this a lot better than adding todos as you can skim though the list closer to the end and address things that matter most first. Often the code that seems silly at first has a decent reason to be that way with the full context knowen)
All of this helps me pull the right threads without having to switch context throughout the day
I have tried to point out that poorly implemented or non contructive security controls reduce system availability. As employes are not able to get to the information they need in a timely manner.
But it's been a dead end to many an argument. For some the underlying issue is a refusal to accept that product usability and security are not mutually exclusive and a difficult to use system just leeds to grey IT in the org.
The most odd reply I have received was pedantics on the definition of security availability, i.e.,
"Ensuring data and network resources are accessible to authorized users when needed"
Beacause it contains the word "authorized" any controls for authorisation can therefore never affect availability as they have to be authorized before we can consitter it an impediment to availability...
If anyone has a reply better than that's ridiculous, please help me
here
You're right it would be nice to see some more detail. Perhaps it requires sending a custom update when it reaches out via ssh or it does something wild like opening a reverse shell
What I still don't understand is how flight plans get approved?
In my mind they would only be approved once all involved countries review and process the plan. That way we don't need this ridiculous idea of failing safe on the whole uk airspace for a single error.
That day a single flight plan could have been rejected, perhaps just resubmitted and the bug quietly fixed in the background
If you make your application stateless and have it in a container then there are many managed services out there that can do this for you. For example, in AWS there is fargate and EKS.
Their deployment UI looks nice but this feels like they made their own wheel here in order to keep their In-place upgrade method over something such immutable infrastructure using pre-existing deployment systems.
I wonder if this was ruled out for some reason or perhaps for a large company with people dedicated to deploying this doesn't matter. One example, as they are on AWS autoscaling groups with prebuilt AMI's could have been used to roll new machines instead of copying files to the server.