Відео

I prefer a "if it isn't broken, don't fix it" approach. However, sometimes the code is written so poorly that you can't make changes without rewriting part of it. Often, I have to refactor the code incrementally, cleaning it up in small steps. Every time I've decided to quickly rewrite everything, it ended up in overtime for me and explanations of where I spent my time. I try to avoid making such fatal mistakes.

I wonder if we could create some metrics to gauge how much a rewrite could be worth. Perhaps fail rate, time to bug fix, how long it would take a mid full-stack engineer to ship a brand new form in the most complicated part of the app, how long it'd take to ship a feature that required data migrations as a result of db schema changes. I could see code bases (and eng orgs) having wildly different answers for each. Though I'm assuming we have an active code base, sounds like the cold fusion thing nailed it with essential functionality and does need to worry about any of the above.

make it work, when it's slow, optimize it, when its optimized enough, scale it.

I strongly feel like the general engineering answer applies to the question "Should you do a rewrite?", which is: it depends. Over the past 16 year I've been involved in many rewrites (unfortunately, because I like greenfield better). No rewrite was ever the same. The existing legacy product always worked "fine", but there was always a reason to rewrite: code was unmaintainable, refactorring took more than rewrite. Worked fine at small scale, but over X users performance took a nosedive, nobody understood the system anymore because all domain experts left. No confidence in building extra features, because the codebase was already too big and there were zero automated testcases written, every change would break the system in ways you would not have guessed. Deciding on doing a rewrite is not a developer-only decision, enough stakeholders must be involved. I like this video because you consider the context of the situation.

I think to begin with, we need to define what "requires a rewrite" means. Do we mean when the code is not perfect. Do we mean when the code is not fit for purpose? Do we mean when using newer technologies would be more appropriate? Etc, etc. Then, once we establish that, then we can factor in things like value added by doing a rewrite, etc, etc. There should never ever be any hard and fast rules, such as "never do a rewrite" or "always do a rewrite".

Rewrite is fun but not profitable. Profit is not everything. Rewrite is not the only fun. Ideally, code should be in a state that any change will incur fmt, linter or compiler or test suit to warn or err or revert the change. Then, your current code should be the unique solution of such specification.

I am not in IT in my company, but I do make apps on the side. My company was bought by a bigger player and I have used multiple software solutions for my industry. The parent company's software is shit... all shit... from a user perspective and all written in old code meant to be used on a PDA and the stuff that is meant for web was cold fusion. They wanted to do a rewrite of all of it. The previous software solutions I used combined pretty much ALL of our systems into one very flexible UI on the browser and in a phone app. I suggested to do the same. They then decided to keep everything separate as it is (the boomer founder decided this without ever digging deeper or asking anyone as far as I can tell). I now represent my company as the client and our internal IT is recreating every bit from scratch with separate teams working on each system (I only represent one app). We are 14 months and about 2 million dollars in for "my" application and it isn't much better than the original, in fact I'd argue it is worse except with the phase 2 (scheduled to be done after 18 months from start date) which is is my defined scope, not that Boomer CEO's. I believe with the current way it is being handled a re-write was not needed. But I do believe they could have done a rewrite and been justified if they'd only done it right and made a cohesive software. Now we are really stuck and if it is going to be changed later there will be a sunk-cost-fallacy thing going on. If you can't tell I am super annoyed, but glad to finally be apart of the process.

it depends......................................

However this is still a naive viewpoint. What really mattered was that after our nine months of beautiful architecture and coding work we were making approximately 10k/month more than what our stupid production prototype made for all of its shortcomings. I did not understand this statement. What did they mean? Was it worth to rewrite?

Oh, a large rewrite. For sure this can be problematic. I thought this was going to be a discussion of refectoring or tidy-first mentality. This talk is a mature look at tradeoffs. I'm in the middle of a major rewrite and planning the migration makes me cry. Other systems are coupled to the original system through its database. I'm trying to decouple them and it's a house of cards.

ua-cam.com/video/xCGu5Z_vaps/v-deo.html

You might be forced if the language or framework you are working is losing traction and is not / no longer supported on your current platform.

But do you know for sure that the other 80 % of the features are not used by any of your customers?

In my experience usually the question is not whether to rewrite or not, but how to isolate the broken parts you need to rewrite without losing connection to the rest that is still working (and maintainable!).

Dude stop it with the hypermedia already 😅 A lot of great stuff in this channel but pushing this is just bad.

We've had two rewrites. Our main application was in a VB6 desktop app that we needed to bring to the browser. So we had the brilliant idea to go with Microsoft's shiney new Silverlight framework 😂. Fast forward a few years later, rewriting that shit again...

How did you know? I needed this NOW, I have a SAAS application built in PHP, it's being used by clients but I'm thinking of rewriting in new technologies but I'm thinking WHY? I have few reasons but it takes a lot of work to rewrite.

I say rewrite, Take what you have. 1) Document the design. 2) Build UNIT TESTS, 3) Use newer constructs. 4) After putting them behind unit tests, reuse your best objects and routines. 5) Take advantage of better OO, SOLID and DRY principles. 40+ years of experience here. I'm tire of falling into sh*t code because few want to rewrite.

rewrites are taking times 1/10th of what it used to in the past bro. we got LLMs to do much of the work these days

If you don't understand the code thats a total valid reason to rewrite it. How can you support a code base that you don't understand? (from a retired dev, for example)

But you gained a lot of knowledge since you first wrote the code. You now have the whole picture, you know which parts you don't need etc. You know the business logic and requirements much better. After 5 years every dev can write much better code. Sometimes even after 6 or 12 months.

Have you ever wondered if you would have gotten to your skill level as a developer if you wouldn't have rewritten stuff? I wonder if you mostly read code and merely do little changes here and there you miss out of great learning experiences building a complete system. Any thoughts?

I’ve been doing rewriting of entire projects a few times with full success. Extremely painful process, so only for experienced. You may be surprised how many details is covered in old code. I rewrote iOS app from OBJC to Swift in 5 years and backend system from plain PHP to Laravel in 3 months. And a few others in my 15 years career.

I remember reading and referencing many Joel Spolsky articles back in the day. I think the most memorable content for me is "Why I hate frameworks". Something Ive suggested to colleagues over the years is if you think something is ugly that you have a reason to change, isolate it and rewrite that piece. Usually I would be referring to a smaller section of code that maybe is tangled in a god class or something. I say write what you want that code to look like and have it called instead. Do that enough times as changes are required and eventually you'll be happier. The intent is to do this in the small and typically for a single branch of logic, to avoid doing to much at once. I realized long ago developers would much rather write new code than maintain old code. This technique can allow for small improvements over time while empowering developers to do what makes them happy.

This opinion is stupid. People dont rewrite arbitrarily. Engineers rewrite because they want to refactor. The way to rewrite is to refactor small parts of a system. Add Tests, Repeat until you're done. And you only do this if you need to. I.e. if the system has code smells or arch smells, if its failing and there are no unit test, or if its a legacy system without any tests.

So according to you, if you have a codebase that you understand and someone else gets onboarded and he sees the mess you created (that only you and/or a few other team members understand or partially understand) and he's struggling to understand and he won't fully understand it ever... this code is good enough? What if the ones who understand the code leave? What happens then?

Context matters 🔥🔥❤❤

Ugh I'm sick every time developer are pulling Kafka to be used as queue for their 20 mesaages/h because "it's fast and persistent"

Isn't UTC a timezone. Why can't you store them with that timezone? The client needs to parse the time and apply the offset whether you supply Eastern Time or Universal Time. However universal time will likely not change it's timezone ever.

They definitely are! (more than just Toggle that is!)

Thanks, we had similar situation, so we created boundary in our db, schema for each microservice. it can read but not able to write to schema where it doesnt own .

awesome video... have a question... imagine i have an app with 10 features and 5 of them requires sending mail. do i duplicate the mail functionality in those 5 places ? doing so is bad right , because fixing a bug in mail sending logic will require fixing it in 5 places right ?

Fantastic video and I enjoyed how you focused on the high-level concepts here. Bravo!!!!

it simple wait till 100 tables 😂 or 400 real project then headache

That is exactly how this should be done. It seems to cover majority of the logic in one place making the changes cheaper. Good job!

thanks for the videos

Lovely! Thanks for this video!

Hi! I just missing OpenAPI specification in the video, just seen swaggerUI. OpenAPI allow Hypermedia to be added into the specification with links, etc.. that's what i was expecting

Thanks for the video

03:14 being pedantic, but the original logic for checking if the user is admin was on the server-side as well in the Razor html syntax.

@CodeOpinion When you say "It [the client] just need to understand what operations are possible and how to perform them", i'm mostly interested in the "how". Have you found a good way to remove the "how" or at least a standard that inform the client on how to perform an operation ? In your example of UpdateUser, you have the route & method but what is going to be the payload ? Have you found a good way, ideally a standard, to define that in a json api ? Maybe exposing a schema with the operations ? Might be overkill to always have it so maybe you can have schema endpoints or a special Accept header on the same endpoint ? At the end of the day, maybe i'm trying too hard to shift as much as possible to the backend/api... If we want a nice UX app, we still need someone for the UI code and to learn how to interact with that api. Maybe with something like htmx, even if the json api isn't 100% hateoas, some of that logic can define by the same dev building the backend, thus hopefully increasing the cohesion of the features. At least starting to define which operations are available is the bare minimum imo. I still need to figure out how to build a proper hateoas json api.

Even in this simple example, you don’t use the URL from the OperationViewModel in the front-end code. So is that still hypermedia? I don’t see the difference between that and a much simpler “CanUpdate” flag in the response in terms of coupling. You’re not actually allowing the front-end to perform arbitrary operations that it can discover at runtime. Should you tell the front-end which subset of operations it can or can’t do in a given context, rather than duplicating the logic (in this case, checking the user’s role)? Absolutely. I would just call it good API design, though, not hypermedia.

What pattern are you using for your Blazor app? MVVM?

Yay! More work for the backend guy 😅

Let's extend this idea and assume Blazor (WASM) frontend. When i get list of items over API and each item contains set of operations, how should we eventually build the frontend? Should operation really direct the frontend to load specific Blazor component? (Sometimes another page, sometimes a modal-based component, etc) And sometimes it's a POST request that should be done and as a result a current view should reload its contents? How should it eventually work together? It's easy to zoom in and so it looks easy and logical. But once you bring in full-stack, how would you build it? I'm not saying that the idea here doesn't work. I just see that there's an elephant still in the room that i don't remember you covering. Maybe you could? I would be really interested in that...

Lowkey shilling hypermedia One day Derek will go straight shilling HTMX

very helpful, thank you! 👍👍

my rule of thumb is you never lose precision/metainfo. by storing utc you are doing exactly that

there is a pgq extension to pg.

Good video thanks