The travel eSIMs are a bit different. My Orange plan covers Turkey and the UK, which I specifically wanted, and probably Switzerland as well. For my wife, I needed to get a “world” plan that covered Turkey, otherwise the Europe plan would have covered the UK.
But that’s an important point. The travel plans are NOT the same as regular plans in some ways.
I would have a couple years ago. In a flash. We replaced our phones a while back specifically to have eSIMs. It truth, considering the cost of Canadian roaming plans the phones have already paid for themselves.
Both of our old phones were single SIM, so using a local SIM would mean disconnecting our Canadian numbers which would put us out of touch with people back home. Which means that this card wouldn’t have work for us either.
I was at the point of looking at buying a portable WiFi hot-spot, when I found out about eSIMs. So we went that route.
I have an Orange eSIM with a France number that I have kept alive by reactivating it at least once every 6 months. It’s good for all Europe, without roaming charges, so that’s easy to do. Having the same number all the time is convenient, but more importantly I have gone through the hassle of providing passport info to Orange, which is a government requirement if you want a number for more than a couple of weeks. I think that’s an EU thing.
The local number is good for calling hotels and for making restaurant reservations. Just having that is a game changer.
For my wife’s we don’t need a number, so I just use Nomad for her data only eSIM, and get a new one each time. The cost is about $12-15, and you get whatever carrier you get, but the service has been good so far no I keep using Nomad.
We can text each other using WhatsApp, and you can even use WhatsApp for voice calls. The sound quality is acceptable.
We bought phones that support eSIM because we do a lot of travelling. Canadian mobile companies charge usurious rates for roaming: $15/day! Times two phones. I can get 2 weeks of data only for Europe for about $11 total on an eSIM. With voice it goes up to about $25. Total.
It has changed our lives when we travel.
It’s just as much a sport as figure skating or synchronised swimming.
You mean “flavour”, right? Another small but important difference.
I think it’s a bit more than that. I think that the idea is that you simplify the problem so that the rubber duck could understand it. Or at least reformulate it in order to communicate it clearly.
It’s the simplification, reformulation or reorganisation that helps to get the breakthrough.
Just thinking out loud isn’t quite the same thing.
Why not? He’s an amazing speaker and he comes across as extremely thoughtful and intelligent.
It goes really well with YAGNI. Also DRY without YAGNI is a recipe for premature over-architecting.
This is also one of the main benefits of TDD. There was a really good video that I can’t find again of a demonstration of how TDD leads you to different solutions than you thought you use when you started. Because you code exclusively for one single requirement at a time, adding or changing just enough code to meet each new requirement without breaking the earlier tests. The design then evolves.
I’ve always heard of your “post-architecture” referred to as “evolutionary design”.
In a way, this question itself is very “un-agile”. Agile should be always forward-looking, “What can we do next?”, “What can we get done in this short period of time?”, “What should we do next?”.
OK, so you found a possible “defect” in your system. Is it a defect, or did someone slide in a requirements change 3 months ago?
This reminds me of playing chess. Sometimes a player will make their move when their opponent is distracted. The opponent hears, “Your turn”, and they look at the board. “Which piece did you move?”. The first player just shrugs.
The point is that you shouldn’t need to know which piece just moved. Every chess position is a “state” of its own, and your best move should depend on going forward from that state, not knowing how the board changed recently.
It’s the same thing here. You have a situation. Does it really matter how, when, who or why it happened? It shouldn’t, and here’s why:
Just because it’s a defect (if it is) doesn’t automatically mean that correcting it moves to the top of your “to do” list.
It’s going to take some non-zero amount of time to change it back to blue. And when you’re doing that, you’re not doing something else. There is always an opportunity cost to doing bug fixes and you shouldn’t treat them in an ad-hoc way. Should you be spending that time, and who gets to decide if you do? It’s not your decision. It’s the PO’s decision to make.
Maybe the PO doesn’t care about the colour. Maybe they do care, but not if it means some other feature gets delayed. Maybe it’s the most important aspect of the whole system, and there’s no way you can launch with it green. So you cancel the current Sprint and start a new one dedicated to fixing this defect! Maybe they regret asking for it to be blue, and now they’re happy that it’s now green.
If it was me, I’d get a quick T-shirt size estimate on the work required to change it back to blue, then put it in the Product Backlog to be reviewed with the PO. Maybe have a quick chat with the PO, or send a memo about it. Maybe the PO will need to check with their SME to see if anyone remembers asking for it to be changed to green. Maybe not. In any event, it either makes its way into a Sprint Backlog or it doesn’t.
Also, if you’re doing Agile right, then your clients are getting constant, hands-on, experience with your system as it is being developed. To go 100 days without some kind of “release” that they can play with and give you feedback is an anti-pattern. If you are giving them the latest version every week or two and after almost three months they haven’t noticed that the footer is green, then it’s probably not important.
On to the actual question. Jira is a potential sand trap of administrative complexity. The answer is usually to keep everything smaller. Smaller features, and smaller Sprints. Smaller teams. A team of 5 or 6, working in one week Sprints, can only do so much per Sprint. If your fundamental unit of work - a story, or a feature, or a ticket - is set to take something like 1/2 day and forms the basis of your Sprint Backlog, then each programmer on the team can do at most 10 SB items (in a perfect world). Depending on the composition of your teams, you’re probably going to have only about 3-4 programmers - which means 30-40 tickets per Sprint Backlog. And that’s a blue-sky number that’s practically impossible in a world with meetings. A team of 5 or 6 is going to complete closer to 20 Sprint Backlog items in 1 week Sprint in the real world.
The point being that 14 Sprints is your 100 days and each Sprint has about 20 easy-to-understand items in it. Whatever your management tools, it’s a failure if you can’t locate those 280 features in a matter of seconds. And it should be easy to eliminate 270 of them as not possible places where the change happened just from the description.
And when those SB items are small, as they should be, it’s not an onerous task to document inside them the requirements that they are supposed to meet.
When you have 1 month Sprints with tickets that take 2 weeks to complete, then everything becomes a nightmare. It becomes a nightmare because it’s virtually impossible to impose some kind of consistent organizational structure internally on free-form stuff that big. But it’s almost trivial to do it with tiny tickets.
And the other thing that happens with big tickets is that there’s tons of stuff that programmers do without thinking about it too much. If you’ve got two weeks to finish something, then there’s a ton of latitude to over-reach and the time estimate was just a wild guess anyways. If you have 3 hours to do something, then you’re going to make sure that what you need to do is clearly laid out - and then you have to stick to it or you won’t get done in time.
Did somebody “fix” the inconsistent footer colour while doing some huge, 2 week, ticket? Good luck finding out. But that’s not going to happen with tiny, well documented tickets.
I always thought of “Briton” in that last sense, while “Brit” has the meaning of anyone living in the UK (almost). But that’s from an outsider’s perspective.
As my English cousin corrected me, though, “I’m English, ‘British’ could be anything!”. She wasn’t, of course, talking about the difference between English and Welsh, or Scots.
Technically, he would have three drives and only two drives of data. So he could move 1/3 of the data off each of the two drives onto the third and then start off with RAID 5 across the remaining 1/3 of each drive.
As a Canadian driving around the UK I always found these signs strange. When passing one we would raise our fists in the air and shout, “End road work…end road work everywhere!!!”.
It amused us.
Grandma’s on the roof and we can’t get her down…???
There’s two kinds of issues: instance and pattern. The first time or two, it’s instance. You deal with those with specificity. Something like, “I would prefer not to talk about this subject with you, please stop”.
If it persists, then it’s a pattern problem. You deal with the pattern, not the instance. “I’ve asked you not to talk about subjects like this in the pant, but you haven’t stopped. This makes me feel like you don’t respect my boundaries and it’s making it difficult for me to work with you. Why are you doing this to me?”.
You can escalate from there, and this might involve management involvement but at least you’ll have the clarity of having made the situation clear before it gets there.
Honestly though, unless the coworker is actually deranged, they’ll be mortified when they find out they are making you uncomfortable and they’ll stop right away.
I think that a good starting place to explain the concept to people would be to describe a Travesty Generator. I remember playing with one of those back in the 1980’s. If you fed it a snippet of Shakespeare, what it churned out sounded remarkably like Shakespeare, even if it created brand “new” words.
The results were goofy, but fun because it still almost made sense.
The most disappointing source text I ever put in was TS Eliot. The output was just about as much rubbish as the original text.
I’m not buying that. Slavery has been a staple of civilizations all through history. There’s no universal law of nature that any being has any right to life, freedom or self-determination.
The “moral fabric” isn’t some universal constant either. It too is a function of society. In the U.S., for instance, in 1776 there was no moral problem with slavery. Time went by and morality in the country evolved such that slavery, for many, was no longer acceptable. But it wasn’t that the moral fabric of U.S. society was violated in 1776, it was just different in 1776.
Who knows, in another 100 years people might consider something that is normal today to be some huge violation of something that should be a human right.
Except, that many black folk in the US did not have a right to life or self determination at the beginning. So even these “inherent” rights aren’t so inherent until society agrees to grant/create them.
I think there might be a better way to deliver “ballistic missiles to Russia”.