April 15, 2020 at 10:28 pm
The goal is to release completed work quicker. Every feature you've completed is inventory. It's work in progress while you wait for QA, packaging, scheduling, and deployment. The absolutely goal is reducing work in progress and inventory and getting that work out to customers. Or out to the system so that other work can be built on top of it.
Your goals for DevOps are aligned with what I see, but this also means you are also going to deal perpetually with changes. Your "catch up" will likely be work, but arguably, whether they release 1x/qtr or every 2 days, the amount of stuff they release in aggregate isn't likely to change. The difference is that you don't see one long release log, you see a lot of small ones.
April 16, 2020 at 5:36 am
If you look at the agile manifesto it lists the principles in terms of x over y. For example people and processes over tools and technologies. It is explicit in saying that while there is value on the right hand side we see more value in those on the left.
It isn't that managers are thick or that there don't understand it is just that their priorities are different. A lot of pressures come from a need to satisfy investors. Those Investors have a very focused set of requirements and with timescales that are out of step with the natural cadence of the business.
I know that selling a longer payback project is difficult. Being seen to do something is almost as important as what you actually do
My whole whole point is that if you're doing things right the first time, you'll actually end up doing them faster and you won't have to sell a longer payback. From what I've seen in the past, rework takes about 8 times longer than slowing down a bit a doing it right and the small amount of slowdown to do it right is actually a lot quicker than doing it wrong and then having to fix it.
The other thing people don't consider is that if something wrong makes it to the customer, there's hell to pay in lost faith, bad advertising, fewer new opportunities, and possible losses of current customers. Word travels fast in elevators and on golf courses.
Well... unless you're a company like Microsoft and people have become so addicted to the product because everyone else is addicted that you'll take whatever crap they publish with glee.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 16, 2020 at 12:07 pm
The goal is to release completed work quicker. Every feature you've completed is inventory. It's work in progress while you wait for QA, packaging, scheduling, and deployment. The absolutely goal is reducing work in progress and inventory and getting that work out to customers. Or out to the system so that other work can be built on top of it.
Your goals for DevOps are aligned with what I see, but this also means you are also going to deal perpetually with changes. Your "catch up" will likely be work, but arguably, whether they release 1x/qtr or every 2 days, the amount of stuff they release in aggregate isn't likely to change. The difference is that you don't see one long release log, you see a lot of small ones.
If it's true every completed feature is inventory then business people are going to go apesh_t trying to get it out the door faster. Inventory gathering dust in a warehouse isn't making anyone money. However, most software businesses are not able to meaningfully attribute revenue to a feature. Maybe for a few features for a little while but then shortly it's back to being a gestalt. Many small companies follow the "HBO" or "Casino" model where a percentage of revenue is pumped back into development. That's the goal where I'm at now. Not one size fits all tho.
Maybe the list of Stripe changes doesn't seem so bad. The Github changelog of changes applied to the Stripe.NET SDK (that goes along with the list of git version id's above) is here:
https://github.com/stripe/stripe-dotnet/blob/master/CHANGELOG.md
Just glancing at it makes me wince. Two weeks ago they pushed version 35.7.0 with these changes:
Add new fields to Issuing Card and AuthorizationAdd Amount and AmountCurrency to Authorization
Add MerchantAmount and MerchantCurrency to Authorization
Add PendingRequest to Authorization
Add ReplacedBy to Card
Add Amount and Metadata to AuthorizationApproveOptions
Add Metadata to AuthorizationDeclineOptions
Those are changes to the 'Authorization' object which is part of every charge transaction. Three days ago they pushed to master 2x in 1 day. O well, maybe this doesn't seem too bad so I do wish it upon you! It's not possible to apply the releases INDIVIDUALLY to our projects. Or it is possible but that's all we'd be doing.
I would contrast Stripe with another vendor we use, Kendo UI. JS UI toolkits is a feature competitive market that's for sure. They could be pumping out features at least as fast as Stripe. But (for all the reasons I detest Stripe) it's all bundled together and released quarterly according to a cadence. The individual features are all staged in versions so you can cherry-pick which beta features you'd like to work with. This is the release log of KUI for Angular:
https://www.telerik.com/kendo-angular-ui/release-history/
Imo it's much better to be productive with and plan for reliably.
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply