Software engineers hate code • Hacker News Board

Re: Software engineers hate code

#231

Post by usrbinbash » Mon, Jul 10, 2023, 10:53 AM UTC

goto11 wrote: post #210

usrbinbash wrote: post #185

Earlier quoted context omitted.

> If the code is well designed with separation of concerns, "If" is the operative term here. "If" it is well designed, then there is usually not alot of reason to scrap it in the first place.

Sure, but my point is, if the code is not well designed, the result of a ground-up rewrite will not be well-design either, for the same reasons which caused the scrapped version to be badly designed. It is even likely the new version will be worse, since it wont be developed incrementally, and that harsh deadlines will be imposed when the organization realize they can't evolve the product as long as the ground-up rew…

> Sure, but my point is, if the code is not well designed, the result of a ground-up rewrite will not be well-design either,

That doesn't follow for me, sorry.

A rewrite, as I understand and use the term, doesn't mean transpiling what exist to, say another language or to another framework. The old version is essentially just a very detailed and testable list of functional requirements; everything the old thing can do (as long as that functionality is still actually useful), the new thing must be able to do as well.

How this functionality is implemented in the rewritten version, and how it's internals are designed, is entirely up to the rebuild. The way functionality is implemented in the predecessor does not necessarily determine how it is implemented in the new version.

Re: Software engineers hate code

#232

Post by goto11 » Mon, Jul 10, 2023, 4:46 PM UTC

usrbinbash wrote: post #229

hinkley wrote: post #226

Earlier quoted context omitted.

A substantial rewrite is developers asking for a do-over, which is infantile behavior (or as GP more kindly put it, delusion). This is a hill I will die upon: The people who don't deserve rewrites ask for them, early and often. The people who deserve a rewrite rarely mention them, and in fact they likely already have done it, bit by bit as a sibling comment mentioned by way of example. I will say that I've often surp…

> A substantial rewrite is developers asking for a do-over, which is infantile behavior That depends entirely on the reasons why they ask for a rewrite. "I like this tech better", "I don't want to work with this tech", "This new tech is shinier": I agree with you, those are not solid engineering reasons. "This doesn't interface well with the rest of the system because...", "This is going to cost us in the future beca…

You approach scalability problems by identifying bottlenecks through measurements, and then you redesign the problem areas to solve the problem. This might be changing an inefficient algorithm, add caching, partitioning a database or whatever the problem calls for. Most likely the majority of code will be unaffected by these changes.

If an engineer propose that the only way to solve scalability problems is to rewrite everything from the ground up, it just tell you they haven't been able to identify the root cause of the problem. The rewrite will probably end up having he same problem.

Re: Software engineers hate code

#233

Post by Silhouette » Mon, Jul 10, 2023, 6:41 PM UTC

goto11 wrote: post #232

usrbinbash wrote: post #229

Earlier quoted context omitted.

> A substantial rewrite is developers asking for a do-over, which is infantile behavior That depends entirely on the reasons why they ask for a rewrite. "I like this tech better", "I don't want to work with this tech", "This new tech is shinier": I agree with you, those are not solid engineering reasons. "This doesn't interface well with the rest of the system because...", "This is going to cost us in the future beca…

You approach scalability problems by identifying bottlenecks through measurements, and then you redesign the problem areas to solve the problem. This might be changing an inefficient algorithm, add caching, partitioning a database or whatever the problem calls for. Most likely the majority of code will be unaffected by these changes. If an engineer propose that the only way to solve scalability problems is to rewrite…

Unfortunately that argument is like saying you approach security by identifying vulnerabilities and patching them or you approach performance by profiling to find hot spots and optimising them. Of course those things are often true in specific instances and that's usually where you should start.

However all of these are systemic issues and once you've picked the low-hanging fruit you can still be left with systemic problems that are not concentrated in one place but spread throughout your code. Eventually your profiler curve is nearly flat but your JavaScript or Python code still isn't going as fast as C or Rust. Eventually you think you've patched all of your injection points but if you're using manual string concatenation to build your SQL queries you'll probably keep missing others. And eventually you run out of places to add caches and load balancers and it turns out that your existing data storage model is fundamentally limited and needs to be replaced.

In each of these cases you may end up needing to rewrite a whole section of your application or a whole service in your distributed system because you can no longer paper over the cracks. Fortunately it happens relatively rarely but it certainly does happen!

Re: Software engineers hate code

#234

Post by bayindirh » Mon, Jul 10, 2023, 7:33 PM UTC

evandale wrote: post #222

bayindirh wrote: post #214

Earlier quoted context omitted.

You're right, one needs to be able to take criticism, not about the code, but in everything, however being able to give criticism correctly is equally important. This is not about style (kind or to the point, or in any style), but again about keeping in mind that you're talking with a human being. You can say "This doesn't work (because of this), so do it this way", in thousand different intonations, and you can add…

Your handling of the PHD situation sounds perfect and it seems like we're in agreement. I want to reiterate you will never be in a situation where everyone is respectful even if it's a professional setting. You also can't control what other people do so there's no point expecting people to give criticism respectfully or trying to teach people how to do so - you can't correct someone's behavior if they don't want to c…

Thanks. Yes, we're squarely on the same page.

I think I misrepresented myself. I don't expect anything from anyone, in any setting, or I don't intend to change anyone. Who am I to expect to change someone?

I just wanted to say that, I behave the way which I want to be treated. I ask myself, "what would I feel if that's done to me", and if I don't like the answer, I change myself, and try to better myself step by step.

Actually "The Four Agreements" by Don Miguel Ruiz sums up pretty well how I live this life. It's a surprisingly thin yet dense book. I recommend it wholeheartedly.

Looks like we try to do the same things with slightly different methodologies. My hat's off to you dear sage internet stranger.

Wish a peaceful future awaits you.

Re: Software engineers hate code

#235

Post by goto11 » Tue, Jul 11, 2023, 2:39 PM UTC

usrbinbash wrote: post #231

goto11 wrote: post #210

Earlier quoted context omitted.

Sure, but my point is, if the code is not well designed, the result of a ground-up rewrite will not be well-design either, for the same reasons which caused the scrapped version to be badly designed. It is even likely the new version will be worse, since it wont be developed incrementally, and that harsh deadlines will be imposed when the organization realize they can't evolve the product as long as the ground-up rew…

> Sure, but my point is, if the code is not well designed, the result of a ground-up rewrite will not be well-design either, That doesn't follow for me, sorry. A rewrite, as I understand and use the term, doesn't mean transpiling what exist to, say another language or to another framework. The old version is essentially just a very detailed and testable list of functional requirements; everything the old thing can do…

If the rewrite is by the same organization, the same forces which caused the first version to be badly designed will cause the rewrite to be badly designed.