April 14, 2020 at 12:00 am
Comments posted to this topic are about the item Teams That Ship
April 14, 2020 at 4:53 am
This was removed by the editor as SPAM
April 14, 2020 at 8:03 am
There is something that is a nagging thought at the back of my mind.
To achieve a fast cadence of delivery requires a number of disciplines. Breaking down requirements in a way that facilitates development and delivery of small incremental units being one of them.
A small deliverable should be simpler and quicker to develop. Its smallness should make it low risk. Testability and observability should be a major part of the foundation stones of anything being developed if the fast cadence is to be maintained.
There is a definite skill in architecting, designing and putting in place the pipework to facilitate this.
My source of concern is that I'm not convinced that the testing regime is quite right. I'm sure that SQL Server is covered by a vast number of unit tests. And yet SQL2019 CU2 broke SQLServerAgent! Apple's Catalina OS upgrade is causing horrendous problems for some Mac users. Windows 10 suffered pain during their recent upgrade. What is going wrong? Let's face it the SQLServerAgent thing is hugely embarrassing.
One thing I do notice is that integration testing is far less advanced than unit testing. Individual parts seem to be robust and well tested but somehow when trying to use those high quality parts together something goes horribly wrong.
The other problem for any data system is getting hold of realistic but not real data. Redgate Data Generator is a thing of beauty. I had a lot of fun simulating realistic data and using its inbuilt rules to get a realistic spread of data. It's a labour of love to assemble the rules and then you get the problem that the existence of rules is part of the problem! The point of data capture is not chaos proof.
The thing is integration testing can be a damn site slower than unit testing. Robust data testing even slower. If you want ultimate reliability your delivery cadence cannot exceed the speed of your slowest test part.
April 14, 2020 at 4:31 pm
Testing is always a hole. A similar SQL Agent bug in 2005, from changing an enum. Here, I think someone just didn't cover this case, which is both disappointing, and understandable. There certainly is still some laziness from what developers see as "simple cases" and they don't write a test, assuming no one would make a mistake here.
I think testing is an endless pursuit of covering important cases, and we never really get there.
April 15, 2020 at 12:24 am
At my current employer I saw the dawn of DevOps coming. Some managers were interested, all the way from the C-suite on down. We were starting to really get into DevOps. We were doing two week sprints, shipping at least something at the end of each sprint. Having never worked in a place where DevOps was practiced I was excited.
But then the person who was the primary driver of DevOps adoption, left. And when she left, so did the DevOps momentum. We went from two week sprints to, what are sprints again? The current sprint was supposed to have ended in early December. Its still petering along. Of course the Coronavirus has had an impact, but we were already two months late to closing the current sprint, before we were all sent home to work.
Sad.
Rod
April 15, 2020 at 2:40 am
Heh... so many companies seem to have adopted the attitude of "We have to so something... even if it's wrong" and then they bitch about a slow release cadence with more and more bugs. They never realize the bad drug habit they've developed. Running fast means you're more prone to errors and shortcuts that don't work. Making more errors and shortcuts accumulates as technical dept and takes a whole lot longer than most people would ever suspect to repair and restest especially if you don't want to make other errors while making the repairs, which few can pulloff because they're all marching to the snap of the bullwhip wielded by the cadence and the technical debt grows and grows. Still, the cadence continues as do the number of errors and someday you can no longer come even close to keeping the cadence because the errors have actually prevented further development.
It seems that even after such a death of productivity, people never do learn the value of doing one simple little thing that takes just a little longer than the task masters might like but will ship product faster than they ever did before and that's to develop the habit of doing right the first time. Just like the old adage of "If you mind the pennies, the dollars will take care of themselves" so it is true that if you mind the product, the shipping will take care of itself.
There actually never is enough time to fix errors, especially if all you do is ship them because shipping has become the product rather than the product itself.
"Make it work... make it fast... make it pretty... and it ain't done 'til it's pretty".
--Jeff Moden
Change is inevitable... Change for the better is not.
April 15, 2020 at 7:29 am
I'm reminded that DevOps is a culture and culture is the hardest thing to change.
One of the things I've discovered is that I have more power over my own destiny than I thought I had. I don't have to be suppine to my manager's every whim. I do have to build the relationship with them to have some quite stressful conversations. Like any relationship it has to be worked on and built on honesty and trust.
There's also the art of selling what you are proposing in terms of meeting your bosses objectives. Their objectives are at a much higher level than yours so you should have a lot of wriggle room.
My boss has an objective to increase velocity and efficiency. I've got 12 things I want to do that align to that! They may want me to do a specific thing a specific way. I'll prioritise their WHAT but am clear that HOW is what they pay me to decide
April 15, 2020 at 12:40 pm
That's kind of what I'm talking about. It's difficult for many people (especially managers) to understand that, many times, the key to increasing velocity and efficiency is to slow down a bit and simply do it right the first time instead of doing it wrong and then having to fix it even if you only have to fix it once (which isn't usually the case). Of course, quality also soars in the process.
The hard part is convincing people that's true. The only way to do it is to have data on the subject from previous episodes. What's a bit stupid about that is companies usually have such data but never consider using it to prove they need to slow down to speed up.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 15, 2020 at 1:46 pm
That's a link to the monthly breaking changes to the Stripe API. Words cannot express... it's too much too often... it forces you to choose between constantly working on Stripe upgrades or applying multiple changes at once. Some of it is driven by security (ok fair enough) but a lot are features being crammed in at the earliest point.
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
April 15, 2020 at 1:57 pm
That's a link to the monthly breaking changes to the Stripe API. Words cannot express... it's too much too often... it forces you to choose between constantly working on Stripe upgrades or applying multiple changes at once. Some of it is driven by security (ok fair enough) but a lot are features being crammed in at the earliest point.
That's just for the overall API. Specifically for .NET the release of the C# library for the last 12 months looks like this:
Version Downloads Last updated
35.17.0 0 20 hours ago
35.16.0 0 2 days ago
35.15.0 0 2 days ago
35.14.0 517 5 days ago
35.13.0 421 6 days ago
35.12.1 478 7 days ago
35.12.0 2,579 12 days ago
35.11.1 2,929 15 days ago
35.11.0 341 15 days ago
35.10.0 3,095 20 days ago
35.9.0 1,710 22 days ago
35.8.0 595 22 days ago
35.7.1 287 23 days ago
35.7.0 1,939 a month ago
35.6.0 8,423 a month ago
35.5.0 784 a month ago
35.4.0 234 a month ago
35.3.0 7,333 a month ago
35.2.0 163 a month ago
35.1.0 854 a month ago
35.0.0 840 a month ago
34.26.0 9,882 2 months ago
34.25.0 3,031 2 months ago
34.24.0 2,191 2 months ago
34.23.0 11,201 2 months ago
34.22.0 6,214 2 months ago
34.21.0 133 2 months ago
34.20.1 1,624 2 months ago
34.20.0 9,463 2 months ago
34.19.0 8,744 2 months ago
34.18.0 5,847 3 months ago
34.17.0 11,664 3 months ago
34.16.1 3,273 3 months ago
34.16.0 9,556 3 months ago
34.15.0 6,599 3 months ago
34.14.0 1,441 3 months ago
34.13.0 5,511 3 months ago
34.12.0 6,865 3 months ago
34.11.0 3,560 3 months ago
34.10.1 1,862 3 months ago
34.10.0 9,445 4 months ago
34.9.0 4,746 4 months ago
34.8.0 5,592 4 months ago
34.7.0 2,102 4 months ago
34.6.0 6,825 4 months ago
34.5.0 7,852 4 months ago
34.4.0 1,179 4 months ago
34.3.0 7,861 4 months ago
34.2.0 274 4 months ago
34.1.0 22,390 4 months ago
34.0.0 2,014 4 months ago
33.9.0 8,677 4 months ago
33.8.0 7,657 5 months ago
33.7.0 4,502 5 months ago
33.6.0 3,044 5 months ago
33.5.0 2,548 5 months ago
33.4.0 3,140 5 months ago
33.3.0 17,324 5 months ago
33.2.0 1,778 5 months ago
33.1.0 2,213 5 months ago
33.0.0 3,430 5 months ago
32.2.0 2,916 5 months ago
32.1.3 18,291 6 months ago
32.1.2 2,712 6 months ago
32.1.1 107 6 months ago
32.1.0 1,159 6 months ago
32.0.0 8,438 6 months ago
31.2.0 966 6 months ago
31.1.0 21,616 6 months ago
31.0.0 519 6 months ago
30.1.0 2,573 6 months ago
30.0.1 424 6 months ago
30.0.0 3,083 6 months ago
29.6.0 11,707 6 months ago
29.5.0 11,427 7 months ago
29.4.0 9,617 7 months ago
29.3.0 4,255 7 months ago
29.2.1 6,299 7 months ago
29.2.0 12,627 7 months ago
29.1.0 27,681 7 months ago
29.0.1 2,683 7 months ago
29.0.0 30,761 7 months ago
28.11.0 10,590 7 months ago
28.10.0 27,110 7 months ago
28.9.0 3,481 7 months ago
28.8.0 20,734 8 months ago
28.7.0 608 8 months ago
28.6.0 16,456 8 months ago
28.5.0 12,292 8 months ago
28.4.0 5,020 8 months ago
28.3.0 4,206 8 months ago
28.2.0 38,793 8 months ago
28.1.0 15,030 8 months ago
28.0.0 4,967 8 months ago
27.25.1 973 8 months ago
27.24.0 16,005 8 months ago
27.23.0 2,071 8 months ago
27.22.0 171 8 months ago
27.21.0 21,315 8 months ago
27.20.0 7,767 8 months ago
27.19.0 9,453 9 months ago
27.18.0 9,823 9 months ago
27.17.0 1,687 9 months ago
27.16.1 33,894 9 months ago
27.16.0 15,091 9 months ago
27.15.0 10,922 9 months ago
27.14.0 4,916 9 months ago
27.13.0 16,547 9 months ago
27.12.0 2,036 9 months ago
27.11.0 6,896 9 months ago
27.10.0 10,614 9 months ago
27.9.1 4,732 9 months ago
27.9.0 8,230 9 months ago
27.8.1 11,919 9 months ago
27.8.0 3,804 9 months ago
27.7.0 327 9 months ago
27.6.0 1,779 9 months ago
27.5.0 3,633 9 months ago
27.4.0 9,969 10 months ago
27.3.2 16,698 10 months ago
27.3.1 10,477 10 months ago
27.3.0 355 10 months ago
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
April 15, 2020 at 2:26 pm
For a C# data access library that targeted SQL Server maybe 4 or 6 month release could make sense 🙂
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
April 15, 2020 at 5:24 pm
DevOps is a culture, but the culture isn't to write sloppy code faster. It's to release the changes, backwards compatible, quicker. From code commit to release is quick, not from spec-> commit. Too many managers look at the latter, which is wrong.
For the Stripe thing, I don't work with it, but most of those seem to be enhancements, not breaking changes. If they are, that's poorly architected. APIs can rev, but must be backwards compatible.
April 15, 2020 at 7:23 pm
DevOps is a culture, but the culture isn't to write sloppy code faster. It's to release the changes, backwards compatible, quicker.
While I agree about the culture part of that, I disagree with the idea that it's to release changes more quickly. That may be a result but, to me, that's not even a goal of DevOps IMHO.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 15, 2020 at 8:50 pm
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
April 15, 2020 at 9:03 pm
DevOps is a culture, but the culture isn't to write sloppy code faster. It's to release the changes, backwards compatible, quicker. From code commit to release is quick, not from spec-> commit. Too many managers look at the latter, which is wrong.
For the Stripe thing, I don't work with it, but most of those seem to be enhancements, not breaking changes. If they are, that's poorly architected. APIs can rev, but must be backwards compatible.
It's difficult to realize the benefits of DevOps for yourself when a service you've integrated with is releasing on a machine gun cadence. By the time we do a "catch up" project for Stripe there will have been changes on top of changes. So I always have that to look forward to. The real goal of DevOps IMO is (or ought to be) predictability and maintainability. Versioning, regression testing, unit testing, performance benchmarks and monitoring, and slotted deployments.
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply