Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things You Should Never Do, Part I (2000)

joelonsoftware.com

Post reply on HN
Print view View original

71–80 of 104 posts

Re: Things You Should Never Do, Part I (2000)

#71

Post by onetimeuse92304 »

toast0 wrote: post #16
onetimeuse92304 wrote: post #7

I think people tend to want to rewrite software for the psychological break from the old, bad and ugly thing they don't want to have anything to do with anymore. It is so easy to think "If only I could start everything from scratch, life will be so beautiful and I will be so successful and everybody will be happy. I will fix all the problems of the current codebase and people will forever sing songs about how amazing…

> * developers not appreciating the fact they are in a much very different (worse) situation than original creators of the previous version. The creators of the previous version had time to build the system and then slowly evolve it. But the current team has typically a short time horizon to replicate ALL of it. On the other hand, developers writing the new system have the major benefit that the requirements are know…

I don't think real requirements are known and understood in general.

For example, consider a team that has been maintaining the system for a long time. Most or all of the people that has initially created the system have moved on to other positions or companies. Many of the people who stuck with the team did so for reasons of being experts but are also unable or unwilling to communicate well (for example, because they see the value in preserving their position of being one of the few people with expertise).

In a team like that, they might have good memory of things they have worked on recently, but not necessarily things that are working and the users take for granted. Users do not typically spend much time reaffirming the features that are working well.

One of the challenges of working with stakeholders is that close to 100% of the communication tends to be on things that are not working or are missing or they want to get done. As a developer or manager of the team, you need to find some way of answering the question "am I doing well?". Because users are of course unhappy with how the application works, but to understand levels of unhappiness you need to find some other reference (working for some other projects).

I was yesterday in a meeting with developers where they complained about how manual our deployment system is.

Our deployment system requires them to press a button to deploy a version of the application to the environment. Yes, log in and press a button.

I explained, that I worked in the past for teams that had hundred page manuals on how to compile and deploy the software and that manual would be compiled again and again for each release and the process would take from couple of days to a whole quarter.

So you need to have some perspective to be able to judge that kind of feedback.

Re: Things You Should Never Do, Part I (2000)

#72

Post by dash2 »

sjburt wrote: post #41

Am I wrong in understanding that this rewrite is what produced Gecko, which is still one of the top browser engines a quarter of a century later? I really think Joel called this one wrong.

Netscape could have been as big as Google. Instead, Microsoft ate their lunch. Now, even Firefox too has become niche.

Off-topic: anyone else remember the Mozilla browser before Firefox? Remember XUL? That was with KDE and Gnome 1.x, when the Linux desktop was just round the corner. Who needs Word when you could use StarOffice....

Re: Things You Should Never Do, Part I (2000)

#73

Post by throwthrow5643 »

I think as always in software, "it depends". The author appears to be assuming there are no tests on all of these paths that we will apparently miss when we migrate the code over. If so that is a problem with testing rather than migration.

Also how messy are we talking? I've seen code at a bank where a junior contractor implemented, in reams of code, his own database locking primitives, apparently unaware that the db could handle concurrent accesses on its own.

Rewrites aren't such a big issue these days, this seems a little dated. The real issue where we get painted into a corner now is architectural, say if you went really hard down the microservices route and tried to back up out of it.

Re: Things You Should Never Do, Part I (2000)

#74

Post by kelnos »

iopq wrote: post #30
burnished wrote: post #12

Earlier quoted context omitted.

Other way around in my estimation.

I've read every line of a 300,000 line web application in less than a year working at a company. I doubt I could write that many lines of code in that amount of time.

300,000 lines of code doesn't seem unattainable for a single developer in a year. If I'm in the zone, I can easily bang out 5-10k lines of code over a weekend if I know what I want to write.

But that's the thing: a lot of development involves not writing any code, as you re-think your abstractions, plan the architecture of the next bits you'll write, debug what you've written, etc.

So I don't think we're necessarily talking about speed when we say that it's harder to read code than to write it. I think reading -- and truly understanding -- code (especially when it's someone else's, or even yours, that you haven't seen in a long time) can require quite a bit more mental effort than writing code.

Re: Things You Should Never Do, Part I (2000)

#75

Post by RedShift1 »

zubairshaik wrote: post #58
lisper wrote: post #53

Earlier quoted context omitted.

Using a framework doesn't help at all because a framework is still somebody else's code. There is nothing special about somebody else's framework that makes it any easier to deal with that somebody else's non-framework.

The idea is that frameworks are generally designed to be used by other people, leading to greater focus on documentation, developer ergonomics, community support and generally more versatile code (scales with number of contributers/users; many will report obscure bugs and edge cases you may never consider testing but would impact your end users). Another huge benefit is you don't have to rewrite an entire system from…

Until $framework decides to rewrite everything too, and now you're stuck on an old unmaintained version or waste time migrating to the new version.

Re: Things You Should Never Do, Part I (2000)

#76

Post by mellutussa »

andrelaszlo wrote: post #69

A tool I wrote at a previous job was thrown out after a few years of everyday use within the team. The team lead had noticed that my 300 or so lines of code was unnecessarily complex and could be replaced by ten lines of $TEAM_LEADS_FAVORITE_LANGUAGE. So it was. Every few weeks someone came to me complaining that something didnt work in "my" tool. Thanks to git I could port the old, working code over to the new tool…

I once worked with a guy that probably would be classed as a 10x developer.

Always when the discussion about an edge case came up, he'd dismiss it as "that's never gonna happen".

The of course when those never-gonna-happen things happened, he would absolutely not want the responsibility to fix them.

Re: Things You Should Never Do, Part I (2000)

#77

Post by billpcs »

bdw5204 wrote: post #26

The main reason why developers do rewrites is because it is easier to read your own code than it is to read somebody else's code. Doing a rewrite means you only have to work with code that was written by your current coworkers or by yourself. This is also the core motivation behind all of the schemes to force a single coding style on all developers at the cost of performance and usually with an extremely complicated…

[flagged]

Re: Things You Should Never Do, Part I (2000)

#78

Post by throwthrow5643 »

bdw5204 wrote: post #26

The main reason why developers do rewrites is because it is easier to read your own code than it is to read somebody else's code. Doing a rewrite means you only have to work with code that was written by your current coworkers or by yourself. This is also the core motivation behind all of the schemes to force a single coding style on all developers at the cost of performance and usually with an extremely complicated…

> The main reason why developers do rewrites is because it is easier to read your own code than it is to read somebody else's code.

Did you read the article? He says what you wrote explicitly, in fact there is an entire section on it.

Re: Things You Should Never Do, Part I (2000)

#79

Post by kunley »

Aurornis wrote: post #28
onetimeuse92304 wrote: post #7

I think people tend to want to rewrite software for the psychological break from the old, bad and ugly thing they don't want to have anything to do with anymore. It is so easy to think "If only I could start everything from scratch, life will be so beautiful and I will be so successful and everybody will be happy. I will fix all the problems of the current codebase and people will forever sing songs about how amazing…

In my experience, the biggest factors are: * Many developers prefer working on greenfield code rather than adding to an old codebase * Working on a rewrite buys you some time in limbo where you can write code while being free from the burdens of production operations. This period is shorter than people dream, but it's often long enough for developers to pitch a rewrite for 6 months, code for 12 months and then skip t…

Oh, then from the ops perspective, the programmers who pretend that the production environment doesn't exist, are the worst nightmare.

Re: Things You Should Never Do, Part I (2000)

#80

Post by circlefavshape »

billpcs wrote: post #77
bdw5204 wrote: post #26

The main reason why developers do rewrites is because it is easier to read your own code than it is to read somebody else's code. Doing a rewrite means you only have to work with code that was written by your current coworkers or by yourself. This is also the core motivation behind all of the schemes to force a single coding style on all developers at the cost of performance and usually with an extremely complicated…

[flagged]

I only have surface-level knowledge of any of these things, but I don't think most people would consider a defeated slave rebellion or a war of independence as "revolutions"

As for the other two ... maybe the people of those countries would have endured less suffering afterwards if they had reformed rather than revolted?

Post reply on HN