3 ms·

I have a different take on this. If my project somehow becomes wildly successful and is acquired, the next team is not going to want to maintain my code anyway.

by ilaksh 4y ago

I have a different take on this. If my project somehow becomes wildly successful and is acquired, the next team is not going to want to maintain my code anyway. How do I know that? Because no one wants to maintain someone else's code. No one wants to deal with someone else's abstractions and bugs or anything else. 100% of the time if it's feasible, the next version will be a rewrite of all or a significant portion. Especially for relatively small projects in terms of lines of code, which all of mine are. Now the fact that it's plain JavaScript and messy, console.logs all over the place, I would argue, actually helps that new team. Because it makes it easy for them to trash my code. Which they definitely will want to do anyway. Why? Because they don't want a back end in JavaScript. Actually they didn't want it in TypeScript either. They wanted it in Python. What if it was in Python? Well chances are they wanted it to use a different Python framework. Or actually Rust. But what if the front end was very very well factored React. AND the front end team loves React. Well sorry but it uses React Hooks which they hate. And they really switched to Svelte months ago actually. I would argue the part that matters the most is just not having a lot of code. Which you accomplish by not reinventing the wheel. Another big part is having relatively small functions and low cyclical complexity, and descriptive but not overly long names. So in my mind although my code is a mess on the surface and easy to trash, and could be organized better, it will be easier than average to rewrite they way the want. And easy to trash means less likely to be stuck maintaining someone else's code for an extended period of time. What I care about is getting a usable product out that has features that provide value before I run out of money. I could do half the features and MAYBE if I am lucky they won't trash my code.. but they will actually be worse off because then they will be stuck maintaining a code base that actually isn't using the frameworks they preferred anyway.

swatcoder 4y ago
This is extremely pragmatic wisdom and I love it. I like writing legible code for its own elegance and for my own sanity, but given that you found your way to be productive, I admire your radically honest (and accurate) understanding of what happens to received code no matter what!
- ilaksh 4y ago
  Thanks. Just to clarify, I do feel that overall my code is quite legible.
  - dgb23 4y ago
    Good! Code that’s clear and well tested is easier to delete. Ironic.
bartread 4y ago
This reads like a very theoretical perspective. In 23 years of software development I've picked up or handed over, both solely or as part of teams (mainly the latter), dozens of projects across seven companies. Some of these were projects bought as part of acquisitions. In only three cases was a rewrite performed, and in only two of those cases was it justifiable (both of which involved creating a new version of the product with substantially better capabilities, and on a completely new technical foundation without which those capabilities couldn't have been enabled, nor the commercial value they unlocked). None of the acquired projects were rewritten even though they'd mostly been built by single developers. The idea that developers want to rebuild everything from scratch is a pretty tired cliche. Maybe it's true in some contexts but it's certainly far from a universal law.
- wirrbel 4y ago
  There probably also is a bit of a difference in the companies business context. A rewrite in my company needs to be argued for and needs a solid business case, I.e you need to estimate that the burden of the current code base is choking the dev team and that the rewrite is a better alternative to plain refactoring. Essentially most rewrites I am aware of were either of really small tools or when a project had been written in an esoteric programming language.
- throwbadubadu 4y ago
  Fully agree, always amazing how some can make up reasonable reasons and then based on no data argue it must be like that? Ok, maybe unfair and it is based on some experience, but mine is that code sticks no matter how bad. Most people and industry have grown up and fears a total rewrite unless it really really hurts, and this sometimes taken to absurd levels where every dev knows it should be done, but management is like: but it works, just add me that tiny (lol) feature. On the other hand, single devs code is usually quite good, otherwise they wouldn't have gotten that far... and it usually also has some consistency in itself. I'd say 70% good, 10% too clever guy with code that noone understands but is amazing too look at, 10% too unexperienced student but still good enough too gradually improve on, and 10% bug ridden shit. Who cares about frameworks that much nowadays, except the to be feared teams described below (and unless you have to integrate and it is a conflict)? But what has to be feared is the code base of a mediocre team with a lacking vision and a lacking lead, that's where the horrible code bases that need an immediate full rewrite for me always stemmed from (:
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
watwut 4y ago
That is not my experience at all. People are reluctant to rewrite it all due to sheer amount of work and people who take over others software keep maintaining it. The rewrites I have seen happened after years of talking about rewrites. Or after the original code was utterly unmaintenable. > Now the fact that it's plain JavaScript and messy, console.logs all over the place, I would argue, actually helps that new team. Because it makes it easy for them to trash my code. That being said, your code is going to be rewritten, but you are not making it easier. No one needs you to write crap to be able to trash your code and people do not need to trash your code to rewrite it. But messy code is much harder to rewrite while clean one is much easier to rewrite. Especially if your goal is different technology, having original clean means that you spend a lot less time puzzling over what it done.
lwhi 4y ago
In my experience even refactoring is difficult to carry out with stakeholder approval. A rewrite is extremely difficult to get approval for. You're describing an interesting take, and it makes sense in theory. Unfortunately I don't think it happens in practice.
unemployable 4y ago
Exactly. All I care about is getting things done quickly and moving on. At university I was taught about "maintainable code", but in real life, I have never seen such code. I have inherited code written by teams and it was not good quality. I just rewrote each section when I needed to change something. This seems like a much better approach then trying to write maintainable code - write code that can be thrown out and rewritten.

by ilaksh 4y ago

swatcoder 4y ago

This is extremely pragmatic wisdom and I love it. I like writing legible code for its own elegance and for my own sanity, but given that you found your way to be productive, I admire your radically honest (and accurate) understanding of what happens to received code no matter what!

ilaksh 4y ago
Thanks. Just to clarify, I do feel that overall my code is quite legible.
- dgb23 4y ago
  Good! Code that’s clear and well tested is easier to delete. Ironic.

bartread 4y ago

This reads like a very theoretical perspective. In 23 years of software development I've picked up or handed over, both solely or as part of teams (mainly the latter), dozens of projects across seven companies. Some of these were projects bought as part of acquisitions. In only three cases was a rewrite performed, and in only two of those cases was it justifiable (both of which involved creating a new version of the product with substantially better capabilities, and on a completely new technical foundation without which those capabilities couldn't have been enabled, nor the commercial value they unlocked). None of the acquired projects were rewritten even though they'd mostly been built by single developers. The idea that developers want to rebuild everything from scratch is a pretty tired cliche. Maybe it's true in some contexts but it's certainly far from a universal law.

wirrbel 4y ago
There probably also is a bit of a difference in the companies business context. A rewrite in my company needs to be argued for and needs a solid business case, I.e you need to estimate that the burden of the current code base is choking the dev team and that the rewrite is a better alternative to plain refactoring. Essentially most rewrites I am aware of were either of really small tools or when a project had been written in an esoteric programming language.
throwbadubadu 4y ago
Fully agree, always amazing how some can make up reasonable reasons and then based on no data argue it must be like that? Ok, maybe unfair and it is based on some experience, but mine is that code sticks no matter how bad. Most people and industry have grown up and fears a total rewrite unless it really really hurts, and this sometimes taken to absurd levels where every dev knows it should be done, but management is like: but it works, just add me that tiny (lol) feature. On the other hand, single devs code is usually quite good, otherwise they wouldn't have gotten that far... and it usually also has some consistency in itself. I'd say 70% good, 10% too clever guy with code that noone understands but is amazing too look at, 10% too unexperienced student but still good enough too gradually improve on, and 10% bug ridden shit. Who cares about frameworks that much nowadays, except the to be feared teams described below (and unless you have to integrate and it is a conflict)? But what has to be feared is the code base of a mediocre team with a lacking vision and a lacking lead, that's where the horrible code bases that need an immediate full rewrite for me always stemmed from (:

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

watwut 4y ago

That is not my experience at all. People are reluctant to rewrite it all due to sheer amount of work and people who take over others software keep maintaining it. The rewrites I have seen happened after years of talking about rewrites. Or after the original code was utterly unmaintenable. > Now the fact that it's plain JavaScript and messy, console.logs all over the place, I would argue, actually helps that new team. Because it makes it easy for them to trash my code. That being said, your code is going to be rewritten, but you are not making it easier. No one needs you to write crap to be able to trash your code and people do not need to trash your code to rewrite it. But messy code is much harder to rewrite while clean one is much easier to rewrite. Especially if your goal is different technology, having original clean means that you spend a lot less time puzzling over what it done.

lwhi 4y ago

In my experience even refactoring is difficult to carry out with stakeholder approval. A rewrite is extremely difficult to get approval for. You're describing an interesting take, and it makes sense in theory. Unfortunately I don't think it happens in practice.

unemployable 4y ago

Exactly. All I care about is getting things done quickly and moving on. At university I was taught about "maintainable code", but in real life, I have never seen such code. I have inherited code written by teams and it was not good quality. I just rewrote each section when I needed to change something. This seems like a much better approach then trying to write maintainable code - write code that can be thrown out and rewritten.