• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Does the AWS principle of "Make frequent, small reversible changes" apply to any programming

 
Ranch Hand
Posts: 2932
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does the AWS principle of "Make frequent, small reversible changes", apply in general to any programming as a developer ? Thanks


Reference :  https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_freq_sm_rev_chg.html



 
Sheriff
Posts: 17652
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Kent Beck's next progression on TDD is TCR, Test && Commit || Revert. With parenthesis to clarify the precedence, it's Test && (Commit || Revert).

https://www.infoq.com/articles/test-commit-revert/#:~:text=TCR%20stands%20for%20Test%20and,to%20the%20version%20control%20system.

This is exactly what that AWS principle is about. So yes, it at least applies to this style of programming. Not sure if you can say any programming though, especially if you doing big batches of code before you actually test and deploy.
 
Junilu Lacar
Sheriff
Posts: 17652
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Maybe a more useful question is: To what kind of programming would this approach NOT apply? Why is it about that kind of programming that doesn't lend itself to making frequent, small reversible changes?
 
Marshal
Posts: 28263
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sometimes there are changes to the system which can't be framed in that way. For example: suppose your system produces bills for things which you have sold to people. So you have a list of items and their prices, multiplied together and summed up to give the total amount due. Let's suppose this is how the system works now.

Then it is decided that we need to allow discounts on some items and show them on the bill. There's quite a few things necessary to support this change. We need a tool to specify what items get discounts and how much discount applies to each item. We need to specify what dates the discounts apply on and maybe what times of day too. We need to specify which people are eligible to receive these discounts. We need to decide what happens when a person gets a refund for an item which had a discount. And so on.

I suggest that it would be quite difficult to produce this as a sequence of small, reversible changes. It's not that the whole thing needs to be installed as one big change (although we used to work that way), it's more that the changes needed are not necessarily small and not necessarily reversible.
 
Junilu Lacar
Sheriff
Posts: 17652
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ask yourself what underlying assumptions are there that prevent you from working in small, reversible increments.
 
Junilu Lacar
Sheriff
Posts: 17652
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:I suggest that it would be quite difficult to produce this as a sequence of small, reversible changes. It's not that the whole thing needs to be installed as one big change (although we used to work that way), it's more that the changes needed are not necessarily small and not necessarily reversible.


I installed some shelves in my pantry last week. I had 4 shelves in all, 3 of which I messed up a little, even with careful planning. Only the last one was done without some kind of mistake. The second one was the worst. I ended up with three holes that I need to patch up. When working in the physical world, it's hard to make reversible changes, no matter how small they are.

It's a whole 'nother thing for software though. If your software change isn't reversible, there's probably something you can change in the way you're doing things to make them so. Feature toggles, frequent commits, rollback on failure, automated tests, refactoring, ... all these are practices that contribute to the softness of software. If changing your software is hard, you're likely lacking in one or more of these kinds of practices.
 
Junilu Lacar
Sheriff
Posts: 17652
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:For example: suppose your system produces bills for things which you have sold to people. So you have a list of items and their prices, multiplied together and summed up to give the total amount due. Let's suppose this is how the system works now.

Then it is decided that we need to allow discounts on some items and show them on the bill. There's quite a few things necessary to support this change. We need a tool to specify what items get discounts and how much discount applies to each item. We need to specify what dates the discounts apply on and maybe what times of day too. We need to specify which people are eligible to receive these discounts. We need to decide what happens when a person gets a refund for an item which had a discount. And so on.


There's nothing in this description that couldn't be made as a small and reversible incremental change. That suggests to me that we have different underlying assumptions about the way we'd work this sort of problem. I'd ask again what are those assumptions?

I assume at least the following about the system of work:
1. Using feature toggles to isolate changes
2. Using a small set of users for whom the features would be enabled
3. Having a set of automated tests
4. Code that's well factored enough to allow layering in of behaviors.
5. Frequent commits and automatic rollbacks on failure.
 
Saloon Keeper
Posts: 27886
198
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My programming style is typically what I call "take the automotive transmission completely apart, spread the parts all over the floor, and then rebuild".

That's obviously not conducive to the nightly build approach, because the system in question may not run at all for days at a stretch.

Even so, I've learned to be selective in how many changes I pile on at once.

Fortunately, modern code management systems such as Git (and Eclipse History) allow me to easily do experimental works and post changes to a branch. Or "stash" work in progress in the production system needs a quick fix.

But again, I do a lot of go-forward/back-up/try-again. Much more than most people, I think. And definitely, keeping the changes between versions small make that a lot easier. Making lots of changes at once means re-creating the good all over again while excluding the bad. At best that could be a merge operation, which is stressful enough. At worst, things move around so much that the whole set of kept changes has to be re-coded.
 
Paul Clapham
Marshal
Posts: 28263
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let's try something more up to date. I have a cell phone. No doubt you all have one as well. From time to time, it connects to the internet and downloads an operating system update and spends some time loading it into my phone.

So why don't we get frequent small reversible changes to our cell phone operating systems? The connectivity is there, it could be done physically. What's holding them back?
 
Tim Holloway
Saloon Keeper
Posts: 27886
198
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I believe that I'm currently getting 2 types of updates on my phone.

One is application updates. These happen more or less in the background, and it's usually one or more applications in a small batch. Some apps, I think, ask permission to update.

The other is OS updates. An Android phone is running a Linux kernel supporting a Dalvik VM. That requires a total reboot of the phone to update and the phone asks permission to "update now" or "schedule for later update".

It should be noted that there HAVE been Linux implementations where a live kernel can be updated, but they never went mainstream. I suppose, in large part, because Linux tends to boot fast and doesn't need rebooting often, unlike Windows, which historically has required rebooting for simple application updates and especially for DLL updates.

Reversible changes on a phone aren't really feasible because the average drooling user can't tell what's changed, nuch less intelligently choose from different versions of changes.

On my Nook, as I recall, I could reset back to the original ROM OS/apps, but Nook's idea of a change update notice tended to simply say "small changes have been made". When in fact, they could have done a complete DRM software replacement that meant that should their servers die you couldn't manually decrypt your library like the original scheme did and now your library has in effect, burned to the ground. Which is why I stopped buying ebooks from BN, Even their explicitly "sold without DRM" books have had "no user serviceable parts inside". Minor change, indeed.
 
Junilu Lacar
Sheriff
Posts: 17652
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:So why don't we get frequent small reversible changes to our cell phone operating systems? The connectivity is there, it could be done physically. What's holding them back?


Don't conflate delivery with release. The AWS principle in question is about operational excellence, fast feedback, failing fast and often, in essence, continuous delivery. https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.pillar.operationalExcellence.en.html#:~:text=Make%20frequent%2C%20small%2C%20reversible%20changes,without%20affecting%20customers%20when%20possible).

All that can be and is done by mobile app development teams. Here's an article I found about Etsy: https://www.infoq.com/news/2014/11/continuous-integration-mobile/
 
Junilu Lacar
Sheriff
Posts: 17652
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Admittedly, the lines that distinguish between delivery, deployment, and release can get blurry. Even the experts use the words interchangeably sometimes. See this attempt by Dave Farley, the co-author of the book on Continuous Delivery: https://www.davefarley.net/?p=333.

My understanding of how Dave Farley defines it is: Continuous Integration --> Continuous Delivery (with manual release step) --> Continuous Deployment (automated release)
 
Monica Shiralkar
Ranch Hand
Posts: 2932
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Paul Clapham wrote:Let's try something more up to date. I have a cell phone. No doubt you all have one as well. From time to time, it connects to the internet and downloads an operating system update and spends some time loading it into my phone.

So why don't we get frequent small reversible changes to our cell phone operating systems? The connectivity is there, it could be done physically. What's holding them back?



Yes. But apart from putting this in PROD, I think in lower environment frequent small changes should still be fine.
 
Monica Shiralkar
Ranch Hand
Posts: 2932
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:Not sure if you can say any programming though, especially if you doing big batches of code before you actually test and deploy.



Ok. But individual developed on his IDE, can still find it useful to go with the approach of testing small small changes in each run from his IDE?
 
Junilu Lacar
Sheriff
Posts: 17652
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One of the practices "frequent, small reversible changes" is alluding to is Continuous Integration. If you're developing locally, you can obviously make small incremental and reversible changes, but if you're not frequently merging those changes to a common repository where everyone else can see your changes, you're not going to be adhering to the spirit of the AWS principle. Another practice related to this is Continuous Delivery. If you're not doing continuous integration, you can't do continuous delivery, where your changes are integrated and deployed to some environment and then tested. This won't happen if you're just developing locally.
 
Monica Shiralkar
Ranch Hand
Posts: 2932
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I meant suppose there is a work I am assigned to do some changes. When I do those changes and run in eclipse often it doesn't run and it takes time to isolate the issue. Instead if I do small change run it successfully then to this running code add the next small change run it then it makes me more confident in doing it and keeps less confusing in mind.
 
Junilu Lacar
Sheriff
Posts: 17652
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Good for you if you're already doing that locally but your question included a reference to an AWS principle for well-architected systems. All I'm saying is that in that context, it's really about doing continuous integration and continuous delivery. Whether or not you can do it outside of that context is tangential.
 
Monica Shiralkar
Ranch Hand
Posts: 2932
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks
 
reply
    Bookmark Topic Watch Topic
  • New Topic