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

91–100 of 104 posts

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

#91

Post by Joker_vD »

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]

> Should the French have tried reforming the feudal society?

Well, the English AFAIK have done exactly that, haven't they?

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

#92

Post by barryrandall »

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 Navigator used to be a commercial product that people paid for. Firefox is now free and is used by so few people (me included) that a growing number of sites see no economic value in supporting it.

I think Joel's advice is holding up pretty well.

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

#93

Post by up2isomorphism »

A important point that programmers often overlook is that even writing a buggy but large software and managed to finished it with a lot of functionalities is fundamentally hard than a writing simple program. So unless you really are much better than them (and even so you need to make sure you are the only one actually going to rewrite it, which unlikely), you will have small chance doing better.

However there is a time rewrite is a good solution, that is when you find a lot of the functionalities the old code base provides are NOT actually needed. In this case, it is perfect (and you should rewrite it), because you are writing a much simpler software and you have a much greater chance of success.

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

#94

Post by rawgabbit »

kunley wrote: post #79
Aurornis wrote: post #28

Earlier quoted context omitted.

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.

It is similar with databases. Developers like to pretend that ten years worth of data doesn't exist or is of no consequence. They would like to pretend everything can be re-deployed from github. They fail to realize the database includes data from version .1 while the application version is now 4.7 with completely new business rules and application logic.

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

#95

Post by heleninboodler »

twelfthnight wrote: post #55
heleninboodler wrote: post #50

Earlier quoted context omitted.

There's mess and there's "override $PATH in 50 files" mess. "The old code is a mess" is a really easy conclusion to come to when trying to grok a complicated codebase, and it's not always correct.

Genuine question, is your experience that it is often more your lack of understanding than the code actually being a mess? I ask because while I've been guilty of judging too soon myself, it's much more common the code is just bad, written by someone who's already left. (I work in healthcare and startups though, so different industries are probably different. Also, I've probably been the person who wrote that bad cod…

It's usually a little of both. Sometimes it's a little messy but before you get full understanding, it appears a lot messier. But having the experience of coming across code that I think sucks until I fully understand it and recognize it as something I wrote two years ago (but maybe someone moved to a new location, so I didn't remember it) makes me a little more humble when it comes to judging code.

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

#96

Post by zubairshaik »

RedShift1 wrote: post #75
zubairshaik wrote: post #58

Earlier quoted context omitted.

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.

s/$framework/$any-coding-project-written-ever

Don't let bad frameworks represent all frameworks. That is a faulty generalization [0].

[0] https://en.wikipedia.org/wiki/Faulty_generalization

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

#97

Post by zubairshaik »

lisper wrote: post #59
zubairshaik wrote: post #58

Earlier quoted context omitted.

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…

Just because something is designed to be used by other people doesn't mean it's good. There are lots of things designed to be used by other people, leading to all of the features you list: documentation, community, other people finding bugs, yada yada yada... languages, operating systems, libraries... and many of those things still suck. There is nothing inherent about being designed for use by other people that make…

Absolutely; most frameworks will not fulfill their design goal. Most ambitious open source programming efforts tend to wither away due to loss of interest, a failure to gain contributors, lack of experience, lack of time or energy and many other factors.

But despite that caveat, there do exist frameworks out there today that speed up development for some developers. Whether one has the time or energy or will to audit them to find one that works best for them (or learn that none of them do) is up to the individual.

I bring this up because many of us on this website are at times infected by NIH syndrome and think we can do better than a dedicated team of experienced front-end developers. And it's likely true for many frameworks, but not all. Additionally, we may want to extend that attitude to our workplace where our peers and bosses likely value development speed and cross-project consistency over code performance.

I used to eschew any and all frameworks, but now I realize that my values have changed. Projects like Svelte give me hope for a better future for front-end development.

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

#98

Post by ehnto »

lisper wrote: post #53
ehnto wrote: post #46

Earlier quoted context omitted.

This is why I recommend using a framework in commercial projects, and following it's idioms as closely as makes sense for your project. It means there is a shared idiomatic approach across your team and all the documentation for it is just the framework documentation. It is also easier to hire devs, if you can vet their ability to write idiomatic code in a specific framework then you can better assume they will mesh…

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.

I'll address both your comments here if that's alright,

It's not about code quality at all, it actually doesn't matter that much if the framework is excellent or just okay to reap the main benefit, which is knowledge diffusion through the team and having a set of agreed upon idioms that there's no need to bike shed over. Not every team has a software architect skillset so it's a bit of a risk hedge as well.

There's no need to argue over implementation details, you waste less time onboarding new staff and you have that rich ecosystem of docs and community of solved problems.

That's all. There are great reasons to build your own software but if you're working in a team I feel it's an easier experience to use a known framework. Also a bit more responsible from a business risk management perspective, since you don't have as big of a "bus problem". Only your business logic is trapped inside your org.

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

#99

Post by grecy »

bubblyworld wrote: post #63
grecy wrote: post #54

Earlier quoted context omitted.

I think there's two kinds of bad software The first kind was written by people who know about software, has some attempt at following some conventions, variable names, etc. etc. It's not "clean and shiny", but you can see someone tried . Like if a bunch of first year apprentices built a house. They tried their best, and often did a half reasonable job - at least for a first timer. Plenty of companies are using this k…

Do you have any examples of type two code you could link to? I want to see how bad it can get!

I mean, it's not like it's in github or anything like that - again, the people that write it don't even know what version control is.

Imagine a file with 100,000 LOC, some commented out, copies of functions like "addCustomer()" and then "addCustomerNEW()" and then NEWAddCustomer() and then "makeCustomerDanGNewest()" and so on and so forth. Absolute gong show.

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

#100

Post by lisper »

zubairshaik wrote: post #97
lisper wrote: post #59

Earlier quoted context omitted.

Just because something is designed to be used by other people doesn't mean it's good. There are lots of things designed to be used by other people, leading to all of the features you list: documentation, community, other people finding bugs, yada yada yada... languages, operating systems, libraries... and many of those things still suck. There is nothing inherent about being designed for use by other people that make…

Absolutely; most frameworks will not fulfill their design goal. Most ambitious open source programming efforts tend to wither away due to loss of interest, a failure to gain contributors, lack of experience, lack of time or energy and many other factors. But despite that caveat, there do exist frameworks out there today that speed up development for some developers. Whether one has the time or energy or will to audit…

> But despite that caveat, there do exist frameworks out there today that speed up development for some developers.

Of course. But there also exist frameworks that will slow development down. For any X in {frameworks, languages, operating systems, libraries} there exist X's that will be helpful and X's that will not, and so "use an X" by itself is not helpful advice for any X. You have to use a good X, but that isn't helpful either because it just begs the question.

Post reply on HN