Previous cycles were fueled by retail, with an industry trying to legitimize itself.
This cycle is about max extraction and fraud - Legitimized by the presidential family cashing out billions in meme coins, insider trading and forks of existing protocols.
Hacks have also been hitting hard. North Korea has stolen 500m this year alone and 2b last year.
So… no thriving. On the opposite. Dying is a more appropriate word at this time. Some would call this an opportunity. I see more pain ahead.
No wonder Coinbase is laying off people with the excuse of AI. The reality is that volume is zero. At this stage only me and a bunch of other retail weirdos keep on buying bitcoin paycheck by paycheck…
IMO there's actually an opposite effect going on: Retail was never the main driver behind crypto pricing. Think of it like this: If every US adult purchased $1000 in BTC, that purchase would represent a level of volume that BTC, otherwise & at today's historically low volume, takes about 5 days to clear. BTC volume is too high to be explained by retail.
Crypto volume comes from institutional liquidity, not retail. All of that liquidity has moved from crypto to AI. It turns out that the liquidity wasn't actually interested in the technology or the philosophy; they were interested in outsized ROI. Think of BTC not as a currency, but as a share of stock in the crypto technology sector.
I used to have the 20$ plan, upgraded to max, they were going to charge me 86$ for max minus pro plan.
Credit card didn’t get through, pro plan got insta cancelled, had to pay for full max plan. Clearly a billing bug on their side. If the credit card when upgrading a plan doesn’t come through, don’t destroy the existing plan.
I talked to the chat bot; i got a ticket number, a human will come back to me. That was three months ago. Never got refunded. Nobody emailed me.
I ended cancelling the max plan, it expired yesterday. This plus the constant degradation of the service despite having 30B revenue first quarter this year.
A company that has so much money, and cannot care less about their users…
They will have to do much better if they want to get me back.
Technically not but the devil is in the details. Having to reinstall the app every 7 days and a limit of one app doesn’t even pass the bare minimum.
Jolla has a prelaunch campaign, decent phones for 200€. I might just as well grab one. Sick of having a phone which is more expensive than my laptop but I can barely use.
Wait, I can download and run iOS on my own hardware? Not that I have tried, but I always thought Apples whole schtick was you were only allowed to run their software on their latest X revisions of their hardware?
Codex limits are weird, I can’t barely use up all the limits of the basic subscription.
Switched to Claude max just because I can combine both. I can say since the weekend, I only have had problems. When it works it’s great. But I am seriously thinking to just cancelling this experiment.
Yes. My wife’s mother keeps buying crap in game using my card and I have no reasonable way of blocking her from doing so if I want to keep app purchase sharing.
It’s insane. Does no one at apple have senile in laws? Or is this acceptable?
Older versions of MacOS had an elegance to them. It’s lost some of that over the years.
The overall trend towards minimalism has ironed out much of what made it unique and it hasn’t always succeeded in improving UX. Even Liquid Glass and the ability to tint the icons (to make them even more indistinguishable) depends on the detail being kept to a minimum.
Yeah, what's amazing to me is that they play with the icon so much in an environment where they expect people to find the application by its icon. I always set up my machines so that I use a launcher that allows me to type the name of the program and then press Enter because I hate searching through grids of icons to find things, especially when the icons change over time. But when the company itself is expecting people to find things visually and then constantly changes the visual landscape, it just seems egregious.
And despite that, the place where I work, has disabled ipv6, rendering our development machines useless for trivial tasks such as debugging our iOS app on a device (which uses ipv6 under the hood)
Reasons given: the security policies say ipv6 is not safe enough.
Knowing nothing else about him, I like him based on this alone.
I've been in planning sessions where someone would confidently declare something would take half a day, was surprised when I suggested that it would take longer then that since they were basically saying "this'll be finished mid-afternoon today"...and was still working on it like 3 weeks later.
Besides the usual unknown unknowns, I've also seen this happen with tasks that involve a lot of coordination in the SDLC. Oh the PR went up at at 2pm PST? Coworkers in EST won't review it until tomorrow. Maybe some back and forth = another day until it clears review. Then QA happens. QA is heavily manual and takes a few hours, maybe with some false starts and handholding from engineering. Another day passes. Before you know it the ticket that took an hour of programming has taken a week to reach production.
Time estimations, or conversations to days or other units, typically fail because if a developer says 1 day they might mean 8 focused uninterrupted development hours while someone else hears 1 calendar day so it can be done by tomorrow, regardless of if a developer spends 8 or 16 hours on it.
Are we estimating developer cost (investment cost, writing code only tome), development costs (investment costs including QA time), or time to delivery and first use? People want and use estimates for different purposes. You point out great reasons why knowing what the estimates are for is important.
This is essentially t-shirt sizing without all the baggage that comes from time. Your boss is trying to use the relative magnitude but it's inevitable that people will (at least internally) do math like "7 day tasks is the same as one week task", or worse over-rotate on the precision you get from day/week/month, or even worse immediately map to the calendar. Suggestion: don't use time.
But still we are much better at estimating complexity
Time estimations usually tends to be overly optimistic. I don’t know why. Maybe the desire to please the PO. Or the fact that we never seem to take into account factors such as having a bad day, interruptions, context switch.
T-shirt sizes or even story points are way more effective.
The PO can later translate it to time after the team reaches certain velocity.
I have been developing software for over twenty years, I still suck at giving time estimates.
Time estimations, or conversations to days or other units, typically fail because if a developer says 1 day they might mean 8 focused uninterrupted development hours while someone else hears 1 calendar day so it can be done by tomorrow, regardless of if a developer spends 8 or 16 hours on it.
Yes, I've seen this too in sprint planning. However, the layer of indirection I think is helpful. If you use actual time, then when something isn't done after 1 week when that was the estimate, then bosses are asking why. If your estimate was simply "8 story points", then the bosses can't point to a calendar and complain. They can try to argue that an 8-point task should be done in a week, but then you and the scrummaster remind him that points don't map directly to time, just effort.
Here's my observation: ballparking an estimate for a whole project, in my experience, tends to be more accurate than estimating each task and adding them together.
I like to think of this as 'pragmatic agile': for sure break it down into tasks in a backlog, but don't get hung up on planning it out to the Nth degree because then that becomes more waterfall and you start to lose agility.
Hours is insane. But ultimately time is money and opportunity cost. Software engineering can’t be the only engineering where you ask the engineers how much something will cost or how much time it will take and the answer is “it’s impossible to know”. Even very inaccurate estimates can be helpful for decision making if they are on the right order of magnitude
First, people asking for estimates know they aren't going to get everything they want, and they are trying to prioritize which features to put on a roadmap based on the effort-to-business-value ratio. High impact with low effort wins over high impact high effort almost every time.
Second, there's a long tail of things that have to be coordinated in meat space as soon as possible after the software launches, but can take weeks or months to coordinate. Therefore, they need a reasonable date to pick- think ad spend, customer training, internal training, compliance paperwork etc.
"It is impossible to know" is only ever acceptable in pure science, and that is only for the outcome of the hypothesis, not the procedure of conducting the experiment.
> "as soon as possible after the software launches"
This isn't true, just desired, and is one of the main roots of the conflict here. OF COURSE you would like to start selling in advance and then have billing start with customers the instant the "last" pr is merged. That isn't a realistic view of the software world though and pretending it is while everyone knows otherwise starts to feel like bad faith. Making software that works, then having time to deploy it, make changes from early feedback, and fix bugs is important. THEN all the other business functions should start the cant-take-back parts of their work that need to coordinate with the rest of the world. Trying to squeeze some extra days from the schedule is a business bet you can make but it would be nice if the people taking this risk were the ones who had to crunch or stay up all night or answer the page.
Trying to force complicated and creative work into a fake box just so you can make a gantt chart slightly narrower only works on people a couple times before they start to resent it. 10x that if management punishes someone when that fantasy gantt chart isn't accurate and 100x that if the one punished is the person who said "it's impossible to know" and then was forced into pretending to know instead of the person doing the forcing.
My take: if they have not done the work to get to at least some degree of a spec, and they won't give you time to review and investigate, they get nothing more than a vague, relative t-shirt size.
I think software is one of those VERY rare things, where inaccurate estimates can actually be inaccurate by "orders of magnitude". After 20 years in the field, I still managed to use 2 months of time on a task that I estimated as 10 days.
A rule that has suited me well is to take an estimate, double it, and increase by an order of magnitude for inexperienced developers.
So a task the say would take two weeks ends up being 4 months.
For experienced developers, halve the estimate and increase by an order of magnitude. So your 10 days estimate would be 5 weeks.
The biggest estimation effort I ever took part in was a whole-system rewrite[1] where we had a very detailed functional test plan describing everything the system should do. The other lead and I went down the list, estimated how long everything would take to re-implement, and came up with an estimate of 2 people, 9 months.
We knew that couldn't possibly be right, so we doubled the estimate and tripled the team, and ended up with 6 people for 18 months - which ended up being almost exactly right.
[1]: We were moving from a dead/dying framework and language onto a modern language and well-supported platform; I think we started out with about 1MLOC on the old system and ended up with about 700K on the rewrite.
10 days was already after I used this algorithm. Previous several tasks on that codebase were estimated pretty good. Problem with this is that some tasks can indeed take SEVERAL orders of magnitude more time that you thought.
One of the hardest problems with estimating for me is that I mostly do really new tasks that either no one wants to do because they are arduous, or no one knows how to do yet. Then I go and do them anyway. Sometimes on time, mostly not. But everybody working with me already knows, that it may be long, but I will achieve the result. And in rare instances other developers ask me how did I managed to find the bug so fast. This time I was doing something I have never before done in my life and I missed some code dependencies that needed changing when I was revieving how to do that task.
Something often overlooked in cost/schedule estimates is the nature of joint probability of actions slipping. Action A slips and causes action B to slip. I think software is tougher to estimate because the number of interfaces is often much higher, and sometimes more hidden, than in hardware.
My home construction slipped 6 months on 2 year build time. It happens in construction very often.
> software is only tougher to estimate if incompetent people (vast majority of the industry, like 4+ million) is doing the estimating :)
No, it is tough to estimate, but not only for incompetent people. And "incompetent" can be stretched to "don't know what he's doing", which is how I operate most of the time. I don't know what really needs to be done until it's done. Main part of my work is research on what actually needs to be done, then "just" implementing it. If I waited with estimating until I know what needs to be done, I would spend 3/4 time estimating and then 1/4 with clear understanding and good schedules (example description: I will be clicking keys for 5 hours).
> My home construction slipped 6 months on 2 year build time. It happens in construction very often.
Tangent, but I have at least 3 friends that would've (in retrospect) been nothing short of ecstatic if their home construction had "only" slipped 6 months on a 2 year timeline.
That’s a bit of a strawman considering I was deliberate in saying hardware interfaces are limited and not saying they are zero. The number of interfaces in software is often going to be orders of magnitude greater. The network effects and failure modes will often increase geometrically with the number of interfaces. In fact, big construction design firms have tools to easily identify and mitigate the “clashes” you bring up and those tools tend to work well because there is a finite number and the designs are well-documented (as opposed to software where changes are relatively cheap and easy so they often occur without documentation)
Saying incompetence is the reason is a trivial rebuttal that ignores the central claim about complexity. It’s like saying “the reason why we don’t have a theory of everything is because we don’t have competent physicists”
The next natural progression of this line of discussion between "the business" and engineering is for them to agree on a time range as an estimate. Engineering doesn't want to say it'll be done in 6 weeks, but they feel okay saying it will take between 4 and 20 weeks so this estimate is accepted.
You can guess what happens next, which is that around week 8 the business is getting pretty angry that their 4-week project is taking twice as much time as they thought, while the engineering team has encountered some really nasty surprises and is worried they'll have to push to 24 weeks.
it is still better to give a range though because 1. it explicitly states the degree of unknown and 2. no boss is going to accept 4-20 weeks, which means you start talking about how you can estimate with better accuracy and the work required to do so, which is a major goal of planning & estimation.
> Software engineering can’t be the only engineering where you ask the engineers how much something will cost or how much time it will take and the answer is “it’s impossible to know”.
Because it's not engineering at all. But even if it was, plenty of engineering projects are impossible to estimate - the ones that are doing something novel - and disliking that fact doesn't make it go away.
> Even very inaccurate estimates can be helpful for decision making if they are on the right order of magnitude
If what the business wants is an order-of-magnitude, they should ask for that; often (not always!) that's a lot easier.
> I honestly don’t know what the PO and TL gains with this absurd obscenity
There are marketing campaigns that need to be set up, users informed, manuals written. Sales people want to sell the new feature. People thinking about road maps need to know how many new features to can fit in a quarter.
Not only that they still live with ptsd from the times when they almost disappeared, and will do everything in their power to keep as much revenue as they can squeeze.
Because of this, the Japan appstore will be as crappy as the european one. And the apps as surpar as the ones from the appstore.
Because let’s be honest, apps quality have gone downhill
This cycle is about max extraction and fraud - Legitimized by the presidential family cashing out billions in meme coins, insider trading and forks of existing protocols.
Hacks have also been hitting hard. North Korea has stolen 500m this year alone and 2b last year.
So… no thriving. On the opposite. Dying is a more appropriate word at this time. Some would call this an opportunity. I see more pain ahead.
No wonder Coinbase is laying off people with the excuse of AI. The reality is that volume is zero. At this stage only me and a bunch of other retail weirdos keep on buying bitcoin paycheck by paycheck…
reply