Are Feedback Loops the Key to Building Better Software?

No video

Are Feedback Loops the Key to Building Better Software?

Рет қаралды 5,506

Dylan Beattie

Күн бұрын

Пікірлер: 45

@Huntracony Ай бұрын

The slowest feedback loop I've had to deal with (as a hobbyist) so far is automatic SSH certificate renewal. No way to know for sure that it's working other than to wait a few months. Luckily it did work.

@logiciananimal Ай бұрын

That "instantly fail" test is wonderful. I will now also use the example of the 44 hr feedback cycle.

@PostmanLee 25 күн бұрын

I once had a software to test on a complex production machine for opto-electronic sensors. It was an relatively easy task, selected for new devs like I was by that time. Only thing was: I had to wait every day until the shifts changed to get machine time, so I only had about 1h of testing time a day. Each test took 10-15 minutes and it included some soldering ( to fix some parts instead of glueing ). After each test I had to desolder the parts again, which also took some time. So after the first three unsuccsessful tests I decided to reduce the amount of soldering points to get faster feedback. But I still got apparently random errors from the unit under test. After six weeks of errors and frustration I talked to the system designer. He told me that the machine is adjusting the parts on a nanometer scale and skipping fixation points can make the whole thing unstable. Two days after the talk, the new software was online. This story is still told to every new software developer for production equipment at my company. Key takeaway: Make it fast only if you really, really need to. AND ONLY if you really, really know what you are doing.

@LuminousWatcher Ай бұрын

If you have testsuites that need very specific data, you do as i did and create test helper tools to find or create the data you need

@kaaszigekarel Ай бұрын

Have you tried making an automated script that requests new tokens every minute and stores them? After 4 hours you have an expiring token available at any time.

@DylanBeattie Ай бұрын

You know, that's not a bad idea... :)

@adambickford8720 Ай бұрын

Its critical; i can be twice as dumb but still succeed if im iterating 3x faster.

@Yusuf-ok5rk Ай бұрын

lol. good example

@DylanClouden Ай бұрын

Wow, I had no idea this was a thing that's sick, going to try and integrate this into my workflow

@DavidLindes Ай бұрын

This all reminds me of Brett Victor's talk, Inventing on Principle (and in particular, Brett's principle that he holds to, as demonstrated through much of the talk -- though he's also talking about a broader point). He wants to see feedback loops shortened, too... and has some cool ways of doing so in his demos. (Alas, AFAIK they're only demos... nice to see some real things taking on some of the ideas here.)

@ShadowKestrel Ай бұрын

this doesn't only apply to programming. human brains are fundamentally better at working with immediate feedback than delayed. can you imagine trying to walk if all your senses were delayed by even one second?

@nandoflorestan Ай бұрын

Yes, I remember that, and that is exactly why I dislike marijuana

@DylanBeattie 22 күн бұрын

The audio interface I use to record guitar parts very occasionally has a driver glitch and introduces latency. It's noticeable at 10ms and anything more than 25ms makes it basically impossible to play.

@barneylaurance1865 Ай бұрын

Yep, tight feedback loops are a huge part of building better software. They're key to continuous integration and continuous delivery. With continuous integration in the form of "scaled trunk based development" I get fast feedback on whether or not my colleague developers on the team agree with the way I'm choosing to code something. And in the ideal case where we're working on interrelated things then I also get fast feedback on whether the way I've written it makes them happier and more effective in their jobs or not.

@JeremyAndersonBoise Ай бұрын

The late Joe Armstrong is still my #1 computer science hero because of the way he thought about problems, and his great mind for critiques, positive and otherwise.

@DylanBeattie 22 күн бұрын

I had the great pleasure of meeting Joe at an NDC conference back in 2015 or so. I had no idea who he was - we were sat next to each other at dinner, had a great chat about music and some stuff he was working on about analysing the way great pianists played the piano... lovely guy. After an hour or so somebody else came over to say hello and I realised I was talking to the creator of Erlang.

@naught0 Ай бұрын

Insightful and interesting per usual!

@JeremyAndersonBoise Ай бұрын

In my personal experience, it sure helps.

@cthutu 4 күн бұрын

My slowest feedback loops have always been with the Unreal engine.

@capability-snob Ай бұрын

That's one wild bit of software! No emacs support though. I guess I have some work to do.

@BarryStaes Ай бұрын

“Are Feedback Loops the Key to Building Better Software?” YES. Both in software design and in software development. Split big milestones in plannable chunks with limited complexity, and make feedback (result to requester) part of the process. Even if you do not do Agile to a stakeholder, do this internally. And make software robust but fail fast by design, do not postpone feedback to dev.

@georgehelyar Ай бұрын

Beware of "internal feedback" as an excuse for not getting feedback from real users though. I see this from PMs with waterfall mindsets where they do an increment, don't release to real users, do another increment, don't release, etc. 6 months later they release rubbish, and all they did was waterfall with extra steps, then try to blame agile.

@ScottCowanOrg Ай бұрын

I moved from electronics to software to get the faster feedback loop, It was still faster than Oracle

@barneylaurance1865 Ай бұрын

I'm definitely missing the fast feedback from real users as at the moment I work on a website that's very low traffic for most of the year and then has some very high traffic period when events are on. You can learn so much by logging from the production system on a high traffic website, or by seeing alerts within minutes if you deploy buggy code.

@nandoflorestan Ай бұрын

Having your users test your code is abuse.

@barneylaurance1865 Ай бұрын

@@nandoflorestan I think having users test your code is unavoidable. You can test it as much as you like yourself, but the the first time a real user uses it that is necassarily some sort of test. Both of whether your code technically works in that circumstance and of whether they actually like it. You can acknowledge that its a test and set things up to benefit from it (e.g. by monitoring closely and/or rolling the feature out gradually through a large user base) or you can pretend you know in advance exactly what will happen. But you can't eliminate uncertainty.

@barneylaurance1865 Ай бұрын

@@nandoflorestan I think large businesses that do things in a non-automated way will often test out a new policy or method with real people on a small scale before rolling it out to the whole organisation. Sometimes formally, sometimes one worker will take the initiative do do something differently and then the change can be picked up by management and rolled out if it seems successful. I don't see why we shouldn't do the same with automated systems.

@Ostap1974 Ай бұрын

I am currently in the middle of 3months waiting cycle. 10 days to go...

@DragoniteSpam Ай бұрын

XKCD 1205 charts out the amount of time that can be saved if you automate tasks that take varying amounts of time. XKCD 1319 charts out what happens if you automate tasks poorly. Both feel relevant here.

@chrisnuk Ай бұрын

I find doing TDD so frustrating. I spend so much time thinking about the interfaces and tests I need to write. I then spend what seems like a significant amount of time writing the tests and then what feels like almost no time writing the actual code. I feel less productive, but when I think about it, I say to myself how much longer does that take than just writing code? A little bit in some cases, maybe 50% longer in more extreme cases. Except that's not true... There is a significant amount of my code I probably wouldn't have tested because it's too hard and I almost always would have gone back and changed some of my earlier code to make it play nicer with the later code. I'm hoping I get quicker, I'm getting quicker at the second part, but I guess what I'm trying to say is hacking away at something feel so much more productive even when it's not. I do love the green ticks all over my code, even if it feels a lot harder to make the initial red ones😂 Thank you for your videos

@MrC0MPUT3R Ай бұрын

"There is a significant amount of my code I probably wouldn't have tested because it's too hard and I almost always would have gone back and changed some of my earlier code to make it play nicer with the later code." This is exactly why I like TDD. It's very obvious to me when someone (including me) wrote something without thinking about testing because it's often a pain in the ass to work with.

@chrisnuk Ай бұрын

@MrC0MPUT3R I like to imagine I've got two users of my system of a human who just wants it to do what he/she asked for not interested in your app if they can easily get what they want and a very nosey computer who wants to look inside an interrogate it.

@alexandermackintosh1755 Ай бұрын

I worry that the context switch by jumping to your test code everytime you see a red dot could almost be counterproductive, do you ever get that feeling when using these tools? (In complete fairness I haven't tried so am just guessing!)

@DylanBeattie Ай бұрын

Honestly, no. The red dot gives me an immediate indicator that what I just did has broken something, and it's usually obvious whether this is because I've actually broken it (in which case I fix the code I'm already writing), or that I've unearthed a new requirement or an edge case (in which case I update the test first, then make it pass). It's also worth noting that it happens the other way, too - it's not just immediate feedback when you break something, it's also immediate feedback when you fix something. And watching a hundred dots all change from red to green when you change one line of code is just delightful. 🔴➡🟢🤠

@alexandermackintosh1755 Ай бұрын

@@DylanBeattiefair, time to convince my boss the team needs this IMMEDIATELY 😅

@rf1890 Ай бұрын

Is there Something for python?

@JW-lv1fm Ай бұрын

"Make it work" okay.. yea... "Make it beautiful/faster" What are you wasting time on something that already works? You might break it. Chances are you have to rewrite it. This mentality isn't just in corporate programming. This mantra can only exist in "infinite time/passion project" land. It is better to just: "Look at it from end user perspective." This means you look at if it functions, if its fast/beautiful, and bonus: if it makes sense. IF you can't speed through the task/tests, then you aren't designing for power users, and the workflow sucks + you are wasting time developing waiting through those tests.

@Pystro Ай бұрын

I heard this with "maintainable" or "serviceable" instead of "beautiful". Yes, if you immediately re-factor some ugly spaghetti code right after you're done getting it to work, then yes, it may fail. But it's better than trying to come back to code that you wrote years prior (or code that someone else wrote) and implementing some change and having it fail _then._ At least you still know exactly what the code was supposed to do. Also, ideally you have automatic tests set up and can catch exactly what broke the code. I'd even go as far as saying: "Make it work, make it's tests, make it maintainable, make it fast. You may swap 2 subsequent steps except for making it fast. ...And if your boss makes you stop after the fist step, ask for any further time you're asked to spend on it to be paid 5-fold."

@nandoflorestan Ай бұрын

The OP is clueless. In TDD, the very short loop is write a failing test, make it pass, refactor. Don't forget the 3rd step, refactor. In Extreme Programming, the advice is: you have a feature to implement. Before you implement it, inasmuch as you have courage due to your test suite, refactor the code, so implementing the feature becomes easier. In Clean Architecture, the advice is: You've made it work, that's great -- you are half done. Now you have to clean it up. Keeping code clean is necessary because code is not for machines, code is a means of communication between humans. Look up Literate Programming, look up who invented it, see if that's someone you respect. Corporate programming is no different; but ignoramuses will ignore the above advice and apply Extreme Go Horse instead.

@JW-lv1fm Ай бұрын

@@nandoflorestan I wouldnt say "clueless" as to what has been seen in corporate atmosphere. I would consider you inexperienced or even lucky if you didn't see this type of response when you tell your boss "Its done, but I want to spend 2x more time to make it pretty". Especially if its an internal tool. Tests/clean code are immediately outdated the next code change. Because languages like C# evolve still quickly enough, and tests are so small that testing 1 function is pointless. Do you really write tests for something as simple as "add 2 variables together", or "write entry to database"? If its something larger, the business logic will have changed anyways, so when that test fails, you wonder if you should rewrite the entire test or just drop it entirely. Guess what will happen? The test gets dropped anyways, because you waste that same amount of time "maintaining" the tests too. As stated, this mentality is for people who have TOO MUCH time. While you spend 7 days on this 1 tool, someone else cranked out 7 tools that work 99% of the time. You don't work at NASA, you dont need 100% stability and maintainability.

@GuusHamann Ай бұрын

You have to do the refresh before the token is expired

@vexxxG Ай бұрын

The idea behind the refresh token is to have a way to not send the client ID and client secret every time, so you get an access token which lasts for x and a refresh token which lasts for y where y is greater than x. If x == y then you basically reauthenticating every x time units because both expired. You cannot randomly refresh your access token without context. Basically you need to call the API (because of some user action or scheduled job) you check the access token if it's active, if it's not you check the refresh token. If the refresh token is active you refresh the access token, if it's not you login.

@davidruppelt Ай бұрын

If the access token is a jwt and contains the exp claim, you can schedule a refresh before it expires.

@vexxxG Ай бұрын

@@davidruppeltyes you can, but this adds more complexity than it's worth. Think about what happens if you have a race condition? And is it really worth having a job that does this?

@davidruppelt Ай бұрын

@@vexxxG depends I guess. I've done it in the past for the refresh tokens to keep a session alive as long as needed. And you are right, the complexity and dealing with race conditions was pretty annoying.