Software engineers hate code • Hacker News Board

Re: Software engineers hate code

#211

Post by ranting-moth » Sun, Jul 09, 2023, 10:16 AM UTC

kstenerud wrote: post #207

ranting-moth wrote: post #83

Using a house analogy, I don't hate other people's houses. I hate it when other people blow a hole in the side of my house to put in a new window. They blasted a hole through two walls because it was the quickest way. Then just taped some plastic over the second hole. The project manager said it's still summer and we don't really need that wall at the moment. I know who will have to fix the wall when the winter comes…

That's an organizational issue. Code that does such things would not pass review unless it were specifically a requirement (or if your team is disogranized). Once you're a senior dev, you start to look at the project holistically, adding your input to the design in order to ensure that the project serves its objectives. The code is still important, sure, but the success of the project is more important (and that can…

I think you can boil any problem in a software company down to "an organizational issue".

What you are describing happens in an ideal world of software development. It exists but it's rare.

Re: Software engineers hate code

#212

Post by kstenerud » Sun, Jul 09, 2023, 10:19 AM UTC

ranting-moth wrote: post #211

kstenerud wrote: post #207

Earlier quoted context omitted.

That's an organizational issue. Code that does such things would not pass review unless it were specifically a requirement (or if your team is disogranized). Once you're a senior dev, you start to look at the project holistically, adding your input to the design in order to ensure that the project serves its objectives. The code is still important, sure, but the success of the project is more important (and that can…

I think you can boil any problem in a software company down to "an organizational issue". What you are describing happens in an ideal world of software development. It exists but it's rare.

Actually, that's been my experience in most places I've worked over the past 25 years.

When it wasn't, I shopped my resume around.

Re: Software engineers hate code

#213

Post by goto11 » Sun, Jul 09, 2023, 10:31 AM UTC

Silhouette wrote: post #183

hinkley wrote: post #107

Earlier quoted context omitted.

You say that as if these events are unfortunate accidents instead of lack of technical leadership. I’ve met quite a few “unlucky” people in my life and what nearly all of them had in common was the inability to connect their actions and inactions to consequences. They were blindsided by predictable outcomes over, and over, and over again. Eventually the people who could actually help you get tired of your drama and m…

You say that as if these events are unfortunate accidents instead of lack of technical leadership. Sometimes they are. I've seen several applications that were successful for many years but eventually had to be rewritten because some vital dependency was no longer viable. In web development we had an early generation of web apps that used plugins like Flash or Java to do things. Fast forward five years and those plug…

Browsers discontinuing Flash support is indeed a good reason for porting an app to a different platform.

But this is also a very different scenario than the grandparent example, where the cost of maintenance due to bad code quality is supposed to justify a ground-up rewrite. In the Flash example there is a clear business case for porting, even though it is understood the porting will expensive.

The fallacy is believing a ground-up rewrite will lead to more maintainable code. This is just developers deluding themselves. There is no reason to think a ground-up rewrite of existing working code will lead to better and more maintainable code.

Re: Software engineers hate code

#214

Post by bayindirh » Sun, Jul 09, 2023, 10:44 AM UTC

evandale wrote: post #72

bayindirh wrote: post #25

Earlier quoted context omitted.

I think it's a spectrum. For example I like writing new code and designing new things, but I don't hate or dislike my or other people's old code. That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice. It might not be good code, by our standards, but who knows how it was written. Was the author under stress, under time obligations, or happy, or somethin…

> That code also has been written by a human, and it's disrespectful to approach somebody else's work with this prejudice. Small piece of advice: it is much better to learn how to take criticism of your code as exactly that - it's criticism of your code. People will always be unkind when reviewing code. Even if it's the best code ever written someone will have a different opinion and express it in a seemingly unkind…

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 the underlying message in anywhere on the spectrum of "this works better for our case" to "you're a triple distilled idiot".

This is not about being sensitive or having a skin, this is about mutual respect in a professional setting. When you do your to the point, brutal criticism, you cannot hurt the other party if you keep in mind that you are talking with a human being.

During my M.Sc. jury, one member called me a liar, and my professor had to intervene politely yet forcefully, and in my Ph.D. jury one member flat out insulted me, yet I defended myself politely yet forcefully.

They could have said the same thing, with the same words, in a much politer tone, but they preferred to attack me directly instead of attacking my work, so there's that.

I tend to give direct criticisms as well, yet I do my best to make sure that it's plain and simple I'm trying to guide and it's about the work, not about the person.

Because, I do not do anything to anyone which I don't want to experience myself.

Re: Software engineers hate code

#215

Post by goto11 » Sun, Jul 09, 2023, 10:49 AM UTC

Silhouette wrote: post #179

goto11 wrote: post #40

Earlier quoted context omitted.

> when the predictions say, that, forseeably, the company will lose money down the line because we waited to long for a rebuild, it may be time to pitch that to whoever allocates resources. Only developers who love greenfield or need a new framework on the CV would suggest a company could lose money by not rebuilding. If the developers are not competent enough to write maintainable code or maintain existing code, the…

If the developers are not competent enough to write maintainable code or maintain existing code, then you will have exactly the same difficulties after the rebuild. Why assume the same developers would be doing the rewrite as the original? Maybe the reason for the rewrite is because the original is hopeless and most of the people who worked on it are no longer around. Also everything usrbinbash said in a sibling comm…

> Maybe the reason for the rewrite is because the original is hopeless and most of the people who worked on it are no longer around.

Why are the current developers not able to maintain code they didn't write themselves? Is it because the new developers are less experienced, or because the organization culture have encourage writing convoluted, idiosyncratic and badly documented code? Whatever the reason, the root problem is certainly not solved by rewriting the code base from scratch, since you will just have the same problem next time there have been a few replacements.

Re: Software engineers hate code

#216

Post by Silhouette » Sun, Jul 09, 2023, 12:14 PM UTC

goto11 wrote: post #215

Silhouette wrote: post #179

Earlier quoted context omitted.

If the developers are not competent enough to write maintainable code or maintain existing code, then you will have exactly the same difficulties after the rebuild. Why assume the same developers would be doing the rewrite as the original? Maybe the reason for the rewrite is because the original is hopeless and most of the people who worked on it are no longer around. Also everything usrbinbash said in a sibling comm…

> Maybe the reason for the rewrite is because the original is hopeless and most of the people who worked on it are no longer around. Why are the current developers not able to maintain code they didn't write themselves? Is it because the new developers are less experienced, or because the organization culture have encourage writing convoluted, idiosyncratic and badly documented code? Whatever the reason, the root pro…

I don't think that follows at all. I've seen my share of development groups where someone had previously made a bad hire or brought in the wrong consultants and that had left them with a body of code that simply wasn't very good. That doesn't necessarily reflect the overall culture at the organisation and it doesn't say anything about whether the people currently available would make the same mistakes.

The assumption that a big rewrite would be too expensive and end up with the same problems is itself quite dangerous. Some of those groups I mentioned knew very well they had a pile of junk but management had apparently read the usual advocacy about how Big Rewrites Are Bad and stubbornly insisted on adapting the existing code instead of recognising that it should be written off. They spent far more time and money on the updates than it would have taken to do a clean rewrite. And then they got into this kind of sunk cost fallacy where because they'd spent months doing what should have been weeks of work once they then became even more attached to the flawed code and kept repeating the same mistake.

Re: Software engineers hate code

#217

Post by Silhouette » Sun, Jul 09, 2023, 12:32 PM UTC

goto11 wrote: post #213

Silhouette wrote: post #183

Earlier quoted context omitted.

You say that as if these events are unfortunate accidents instead of lack of technical leadership. Sometimes they are. I've seen several applications that were successful for many years but eventually had to be rewritten because some vital dependency was no longer viable. In web development we had an early generation of web apps that used plugins like Flash or Java to do things. Fast forward five years and those plug…

Browsers discontinuing Flash support is indeed a good reason for porting an app to a different platform. But this is also a very different scenario than the grandparent example, where the cost of maintenance due to bad code quality is supposed to justify a ground-up rewrite. In the Flash example there is a clear business case for porting, even though it is understood the porting will expensive. The fallacy is believi…

There is no reason to think a ground-up rewrite of existing working code will lead to better and more maintainable code.

As with almost every argument in this area that depends very much on context.

A substantial rewrite might be an opportunity to use better tools and improved techniques that have been developed since the original was written. In some cases that could represent a huge improvement in things we actually care about like developer productivity and the quality and performance of the product. Importantly this doesn't imply anything was done wrong or any bad decisions were made by the developers of the original product or the people who have maintained it so far. It's just that we work in a fast-moving industry and sometimes even a few years can see some big improvements in what the available technologies can do.

A development team starting with a relatively clean slate can take into account all the knowledge and feedback received over the lifetime of the existing system. Maybe it was too expensive to make use of those insights while evolving the original system but a new version can take advantage of them. Again that can represent big gains in areas that we care about.

It's often observed that a big rewrite risks losing a lot of small improvements and fixes that have accumulated over the lifetime of the existing system and of course that's true. However it's also true that a big rewrite can avoid a lot of existing design problems or get rid of long-standing bugs that no-one was ever going to get around to fixing.

I've seen big rewrites that didn't end well. But I've also seen big rewrites that were done for sensible reasons and had very positive outcomes. And I've also seen things that should have been rewritten but weren't and instead became a drag on everything. There is no universal rule here.

Re: Software engineers hate code

#218

Post by goto11 » Sun, Jul 09, 2023, 1:28 PM UTC

Silhouette wrote: post #217

goto11 wrote: post #213

Earlier quoted context omitted.

Browsers discontinuing Flash support is indeed a good reason for porting an app to a different platform. But this is also a very different scenario than the grandparent example, where the cost of maintenance due to bad code quality is supposed to justify a ground-up rewrite. In the Flash example there is a clear business case for porting, even though it is understood the porting will expensive. The fallacy is believi…

There is no reason to think a ground-up rewrite of existing working code will lead to better and more maintainable code. As with almost every argument in this area that depends very much on context. A substantial rewrite might be an opportunity to use better tools and improved techniques that have been developed since the original was written. In some cases that could represent a huge improvement in things we actuall…

> A substantial rewrite might be an opportunity to use better tools and improved techniques that have been developed since the original was written. In some cases that could represent a huge improvement in things we actually care about like developer productivity and the quality and performance of the product.

Can you give an example? I have a hard time imagining what kind of techniques cannot be applied to an existing code base with some adaption, but require the code to be written from scratch.

Re: Software engineers hate code

#219

Post by goto11 » Sun, Jul 09, 2023, 1:44 PM UTC

Silhouette wrote: post #216

goto11 wrote: post #215

Earlier quoted context omitted.

> Maybe the reason for the rewrite is because the original is hopeless and most of the people who worked on it are no longer around. Why are the current developers not able to maintain code they didn't write themselves? Is it because the new developers are less experienced, or because the organization culture have encourage writing convoluted, idiosyncratic and badly documented code? Whatever the reason, the root pro…

I don't think that follows at all. I've seen my share of development groups where someone had previously made a bad hire or brought in the wrong consultants and that had left them with a body of code that simply wasn't very good. That doesn't necessarily reflect the overall culture at the organisation and it doesn't say anything about whether the people currently available would make the same mistakes. The assumption…

> They spent far more time and money on the updates than it would have taken to do a clean rewrite

Of course this claim assumes you can reliably estimate the time and cost of the rewrite and the claimed improved productivity after the rewrite.

It is still unclear to me what kind of improvements cannot be applied to an existing code base through refactoring and gradual improvements, but requires all the code to be written from scratch.

Re: Software engineers hate code

#220

Post by Silhouette » Sun, Jul 09, 2023, 2:25 PM UTC

goto11 wrote: post #218

Silhouette wrote: post #217

Earlier quoted context omitted.

There is no reason to think a ground-up rewrite of existing working code will lead to better and more maintainable code. As with almost every argument in this area that depends very much on context. A substantial rewrite might be an opportunity to use better tools and improved techniques that have been developed since the original was written. In some cases that could represent a huge improvement in things we actuall…

> A substantial rewrite might be an opportunity to use better tools and improved techniques that have been developed since the original was written. In some cases that could represent a huge improvement in things we actually care about like developer productivity and the quality and performance of the product. Can you give an example? I have a hard time imagining what kind of techniques cannot be applied to an existi…

One example is adopting a safer or more productive programming language for a new version. The Rust ecosystem has now reached a point where it's a viable replacement for a lot of things we would almost certainly have used C++ for a decade ago with Rust offering significant safety and productivity benefits. Rust is also now being used to replace tools for web developers where the incumbents were written in JavaScript and in this case the advantage is order(s) of magnitude performance improvements.

Another is when your platform evolves and forces the issue like the web plugins being replaced by new web standards that we were talking about before. Here you might not need to rewrite your entire application but you probably are forced to rewrite the affected parts and possibly significantly change the software architecture around them. A related example is if you previously wrote your application targeting a specific environment and now want to support multiple environments but the operating systems or frameworks or other dependencies follow very different conventions that impose some constraints on your software design.