Hacker News Reader

You can call it a psychological problem if you want but calling names is not a solution, nor does it really provide a good path to finding a solution. The labor market being what it is, people will leave steady jobs with good pay for more exciting work with riskier prospects and less pay. This happens all the time.

Bug fixes and incremental features will generally not get you promoted for good reasons, we expect senior engineers to have system design skills and there is simply no way to demonstrate that without having your engineers design systems. If you only assign tasks based on the needs of your product and not on the needs of your workforce you could easily find yourself with a critical skill shortage.

There's a certain inefficiency to this, but only if you put your blinders on. If you have engineers churning out meaningless work then you certainly need to address that problem, but if you prioritize short-term product success over team health you are only trading one problem for another.

> Bug fixes and incremental features will generally not get you promoted for good reasons.

This is exceptionally bad, but sadly true.

If you have an engineer who can unblock teams and fix issues in an hour that others take a week or cannot fix at all, they are gonna jump ship if they can't be recognized.

At that point you've lost a valuable resource.

Recognition is stupidly cheap.

If I can do that without it being a fluke, they’d better bump my salary.

Would you settle for a certificate?

My landlord doesnt take certificates.

Or a "kudos"? (page 18 of the PDF)

The fundamental nature of a tech company is near-unlimited appetite for new stuff to build and new people to build it. If there are zero projects on your backlog, such that the only way to do interesting work is to retrace old projects, you’re in serious trouble.

Code rots, even the best code rots, because the people and cultural environment that the code was written under change and fade away. Refreshing it occasionally, even if it isn’t improved in a significant way, is one way to deal with that rot.

Even if the product/library/framework never changed much, rewrites would still be necessary to keep it going as new generations of programmers shuffle through. Otherwise we wind up with a Verner Vinge dystopian culture of software archeology.

Exactly this. I view rewriting a code base, even if I am copy and pasting some things from the existing one a way of either learning or refreshing my knowledge on how the system works.

An added kicker, I have actually gone down this road, and later realized the only thing I needed to do was make a small change to the existing system, so I did just that and discarded the new work.

Business got their new features, delivered on time, the system was still stable and reliable, everyone was happy, and now my domain knowledge has increased significantly so that new features and development or bug fixes will be even faster.

Code does not rot. It gets complicated and starts to look rotten, but that's the hard won complexity of features and bug fixes. To think you can start over and not re-introduce bugs that have already been fixed seems foolhardy.

The underlying dependencies (OS, libraries, runtime, compiler, etc) slowly get out of date.

Out of date dependencies can be seen as code rot, regardless of quality/state of the actual code.

(Not saying that it should be rewritten because of that, but I do consider outdated dependencies to be code rot.)

This.

Trying to make the software "theirs" seems to be an issue at Google, at least with their open source software and has seemed to have lead to it being less reliable.

For example, Angular Material v1 was one of the most complete and stable front-end packages on the market a few years ago. Then, back in 2017 the lead developer for the project was replaced with a new dev.

This new dev then went about assigning every issue and pull request to himself, modifying or rejecting pr's that had previously been approved, closing issues that had in progress pr's as won't fix, locking discussions, and just generally breaking stuff. (I've personally had to peg my project to v1.4 because everything since 2016 has been a regression)

If you go to the Angular Material v1.x Github page today, you'll see the same dev on pretty much everything.

This isn't productive ownership as it prioritizes the engineer over the customer and has lead to a generally broken system from one of the most stable properties out there. Not to mention, these open-source projects are most people's first exposure to Google's code... Having them be unpredictable regarding the functionality of their software with little concern for users/contributors in the name of making their devs feel special seems like a bad model to learn from.

One thing I think that is important to point out is the, “working beautifully” part. I agree that rewriting stuff just because is a waste of time and money. There are plenty of solutions out there that may solve a problem and may be working fine, but have now hit their scaling ceiling and people become frustrated. Rewriting stuff is a part of software, but should almost always be done incrementally.

I also don’t think it’s laziness. Developer hubris is real and it can get in the way of actual business value.

You pretty much nailed everything else. I share the sentiment because I’m currently working on splitting up a monolith into microservices. Most of the “quick wins” are things that didn’t need to be rewritten anyway, and the stuff that actually sucks is difficult to address. It’s tricky to get right.

The only reason given was exactly what was quoted by parent. Also refactoring different than rewriting.

Remember, we are talkin about a bunch of good, well supported engineers working within rather well oiled machine with a lot of other teams doing similar work and sharing experience and advice.

Nobody said it is good general advice. There is so much stuff you need to do well to have a good chance at successful rewrite that it become good advice that it is a bad idea. Nobody said rewrites cannot be done. If you have a company that knows how to do rewrite (and makes it constantly which, I guess, helps a lot) then a lot of problems can be solved by starting from scratch and it it may be it is well worth it.

I know this is a battle as old as time, but the other extreme does exist: a system so complex that it directly attributes to attrition and decay, but too business-critical to get rid of. Yes, it's a "serious issue", and yes, it's common at many overgrown startups.

There are always good technical reasons to rewrite things but the reason quoted by the parent i.e. devs not “feeling” ownership and won’t work on code wholeheartedly unless it’s their code - those reasons are evil.

No. Absolutely wrong.

A sense of ownership and responsibility over a codebase is fundamental and essential to proper stewardship and maintenance of that code, and refactoring and rewriting is the most effective way to inculcate that feeling. Sometimes it’s not always feasible, and sometimes it’s not necessary, but the end state is essential. Group or shared ownership of code is a manager’s wet dream but pragmatically impossible, a swamp of mediocrity.

Once upon a time, there was a core software engineering principle of "egoless programming". I'm glad we've thrown that piece of idiocy out the window.

Bollocks. There are tons of people doing maintenance programming on code that they didn't write.

Does the developer not work on any systems unless they feel it is theirs, or is it a particular system that causes this phenomena? If it is the latter case, then the dev's reasoning is really a symptom of a deeper problem.

If you feel ownership over some system, you feel as if the whole system reflects on yourself, whereas if you do not feel that sense of ownership, then you feel as if only the work you do on that system reflects on yourself. If you feel ownership then, you're likely to be more proactive in your maintenance and making sure that everything is up to standard rather than being reactive and fixing things that break. You want people to feel a sense of ownership, and rewriting a project is a very good way of doing that. Rewriting may not be the only way, of course, and it may not be the most optimal solution given other goals.

It's hard to relate without more information about the specific situation.

What is the current programming language used?

Is the project mostly legacy (few or no changes in the last few years)?

Is the project critical to the company?

How many people are working on it today? Are they fully assigned to it or is it a "touch when it breaks" kind of situation?

Is the project following modern CI/CD practices? If not, how hard would it be to adapt in the current software stack? Would it be easier in a new stack?

Are developers spending more time than expected understanding the code base?

Is it a political situation? Is the current owner refusing changes? Could it be that rewriting it is just a costly way for removing ownership from that developer/manager?

Yes, there are many legitimate reasons to rewrite like dieng frameworks/languages. However we are discussing here the case where reason proposed for the rewrite is solely to satisfy physiological need of some developers to work on code they can call it their own. A lot of things can be done by refactoring but the devs with these issues often just start new projects of their own that does same thing. In companies like Google, for example, there are at least 5 different products for messaging.

Ok, understood. I think the point I was trying to make (and apparently didn't write it down correct thus the downvotes) is that sometimes the ownership argument could just be an easier, less politically charged way to engage the audience. Who would argue against letting some new developer take ownership of something (if they have the skills, of course)? While discussing all those other questions I posed could open a can of worms.

Do you mean psychological or really physiological? I get the former, the latter seems dubious at best.

Indeed, "physiological" would mean developers die or suffer serious injury if they don't rewrite. Seems unlikely.

It’s not a physiological problem, it’s a technical problem. They do it so they work gets easier. It’s much easier to write code than to read code.

> It’s much easier to write code than to read code.

The fact that "write-only code" is apparently considered a part of sensible software-engineering practice speaks volumes about what their technical culture is like more generally. One would think that code should be much easier to read and survey than it was to write.

But even something like a CS101 assignment takes longer to read than to write, at least for me. This is a common enough starement that I assume I'm not alone.

In fact, I'll often sketch out a block diagram or some pseudocode if I'm having trouble grokking something I'm reading just to help me get into the proper mindset. I agree this is a problem with the current state of the field, but I haven't seen any good solutions, only hacks and workarounds.

The whole point of a computer language is so that another human being (or a team of human beings) can read it.

If the intention is for a uniquely skilled human to give a computer instructions, and the computer to execute them - then just write it in machine code.

If you have engineers with psychological problem of “not invented here”, you have a very serious issue.

We need to be precise about what the problem is, exactly. Here is a more salient formulation: "Not Invented Here" is a form of bias that distorts cost/benefit analysis when people are deciding whether to reuse existing code.

They get ticked off by one imperfection here and other over there and immediately run for exit shouting “I could do so much better”.

Given the formulation of NIH as a form of bias that distorts cost/benefit analysis, what can we do at this point? How about quantifying the cost of the "one imperfection here and other over there" instead of going by the subjective being "ticked off?"

Instead of understanding why things are the way it is, they fantasize about how they can one up original authors and claim their own hero title. They go on to throughly underestimate the time to recreate what has taken years of learning.

To complete the cost/benefit analysis, we can then quantify the development cost of the library they are considering re-implementing.

Meanwhile competition has moved on to V2 laughing their way to the bank and customers scratch their heads why you are still stuck in same place for so long. Then our new “owners” gets their promos after massive marketing of how much better everything is now.

This needs to be quantified and put into the cost/benefit analysis.

But to everyone’s surprise they soon leave the project because working on bugs and incremental features has became boring and BTW, the new stuff is just as complex as old stuff. New devs roll in and we start the whole cycle again.

This also needs to be quantified and put into the cost/benefit analysis. Instead of doing cost/benefit analysis attached to individuals, it should be done by product or by project, so that these turnover costs are also accounted for.

A wide gap separates NIH syndrome and a healthy culture of collective code ownership (with the automated testing, shared style guidelines, frequent small commits, and continuous integration that usually go along with it). The situation you're describing sounds closer to the NIH side, but don't throw the baby out with the bathwater the next time someone wants to rewrite someone else's method to improve its readability!

To be clear, "Not invented here" isn't about "don't rebuild things", it's about "don't build things that exist outside of the company".

It's perfectly reasonable (for the reasons in the submission) to rewrite code that exists already.

> Instead of understanding why things are the way it is, they fantasize about how they can one up original authors and claim their own hero title.

Hell, if they really care about claiming that hero title, why not spend that effort to understand and refactor the parts of the code that were initially hard to deal with. What you wrote above is a distillation of what a "tech bro", "Type-A player", ego-based culture looks like. It is the opposite of true professionalism.

I don't think it is laziness. Some developers simply can't ever shake off the need to be the smartest person in the room. They have been told all their lives how smart they are. Now among peers, they're ... well ... average and they haven't been given the tools to understand how to cope with that. Some developers never outgrow that, sadly.