So you know that from working at Amazon - ie they aren’t micro service focused (yes I worked at AWS) or that they break it all of the time?
You keep saying you can’t break users workflows. But that doesn’t jibe with reality. In B2B, the user isn’t the customer. B2B businesses break users workflows all of the time. I know people complain about how often AWS changes the console UI all of the time and you hear the same gripes from users all of the time in consumer software. How many people cancel their SaaS contracts because of a change in UI if the features remain?
Photoshop users complain (or did when I followed it closely) all of the time when Adobe broke their automations via AppleScript. They kept buying it.
But the point is that you specifically said that you can’t treat a system as a system of black boxes with well defined interfaces. You damn sure better believe any implementation I started from scratch with a team I did in product companies. It’s the only way you can keep a system manageable with ramp up.
And this is also part of the subject of Stevey’s “Platfotm Rant”
It’s the reason you can’t fathom that you don’t have to worry about spooky action at a distance when you enforce modularity at the system level.
And even for customers, Apple has a long history of breaking backward compatible and while Microsoft worships at the alter of backward compatibility, major versions of Office have been breaking muscle memory UI for users since the 80s.
If an end users workflow is dependent on mucking with the backend database - more of an issue with desktop software - or an undocumented feature, it’s the same.
Developers have been doing that for years - changing the UI.
You seem to have had a very specific career that consisted mostly of building something new and moving on before you had any idea how it held up long term. I’ve heard enough to pretty confident that despite a 30 year career you don’t actually have much experience in anything other than greenfield projects. This explains the weird overconfidence you have in a methodology with absolutely no track record.
There’s a difference in breaking some user’s workflow ever no and again and doing it every time you add a feature or fix a bug.
1. You have claimed that Amazon doesn’t do micro services and don’t follow it even though you haven’t worked there (and I have) and I cited a famous letter from an ex-Google/ex-Amazon person who talked about the difference
2. I gave you plenty of well known B2B and B2C companies that “break user workflows” all of the time in new versions
3. I asked you should you go out of your way to not change undocumented behavior and gave you examples in both C (officially undefined behavior), and in managed languages like C# and Java.
Your concern about “breaking user workflows flows” because they relied on undocumented behavior is not shared by any major B2B or B2C company. Hell changing things up to break documented user workflows is not shared. The buyer “the business” is just going to tell the users to suck it up and get use to.
Again - I’ve got a proven track record of multiple companies hiring me including one trying to hire me back - well the acquirer of the startup wanting me back after I left before it got acquired - that’s existence proof that my architectural decisions stood the test of time over the almost four years after I left.
As someone who can talk just as well about the intricacies of C as well “how to create a sustainable development department”, do I really sound like I’m bullshitting?
I don’t trust the technical chops of anyone who has never stuck around long enough to see how their architecture changed and developed with use.
I’ve worked with plenty of expert beginners who sound exactly like you. In addition to the work history, your argument style screams overconfident bullshitter who reads the first line in an email and skips the rest.
You read me saying that companies routinely violate their technical guidelines and you skip reading and jump directly to the conclusion that I’m awfully that microservices don’t exist because that scores you a point in your mind and keeps you from having to think about possibly being wrong about something.
You keep saying you can’t break users workflows. But that doesn’t jibe with reality. In B2B, the user isn’t the customer. B2B businesses break users workflows all of the time. I know people complain about how often AWS changes the console UI all of the time and you hear the same gripes from users all of the time in consumer software. How many people cancel their SaaS contracts because of a change in UI if the features remain?
Photoshop users complain (or did when I followed it closely) all of the time when Adobe broke their automations via AppleScript. They kept buying it.
But the point is that you specifically said that you can’t treat a system as a system of black boxes with well defined interfaces. You damn sure better believe any implementation I started from scratch with a team I did in product companies. It’s the only way you can keep a system manageable with ramp up.
And this is also part of the subject of Stevey’s “Platfotm Rant”
https://gist.github.com/chitchcock/1281611
It’s the reason you can’t fathom that you don’t have to worry about spooky action at a distance when you enforce modularity at the system level.
And even for customers, Apple has a long history of breaking backward compatible and while Microsoft worships at the alter of backward compatibility, major versions of Office have been breaking muscle memory UI for users since the 80s.
If an end users workflow is dependent on mucking with the backend database - more of an issue with desktop software - or an undocumented feature, it’s the same.
Developers have been doing that for years - changing the UI.