Hacker News Reader

Comment by jackblemming | Hacker News Reader

For a small hobby editor, this is fine. For anything serious, much of this advice will not scale at all.

Most serious editors started as small hobby editors, including Vim and Emacs

What historically doesn't scale is trying to get everything "scalable" and "extensible" from the get go - most ambitious projects like that get abandoned because they get the initial designs wrong and its too hard to change, or because there's just too much effort to get to usable state...

Not convinced. I worked on a project with some friends that got to about 20kloc and then collapsed under its own weight because it became impossible to change anything without breaking something else. While there's a wrong way to design for scaling or extensibility, development practices that rely on holding the whole thing in your head will hit a brick wall sooner or later.

It's fascinating reading posts like this from people who have actually put in the work on 20k+ LOC projects with multiple people and those who just repeat a few articles or blog posts they read.

The difference is stark.

I find the comment a little rude, as if implying the grandparent poster (me) "just repeat a few articles or blog posts they read", whereas the anecdotal parent comment about a 20k+ project they've worked on shows the real experience.

I've worked in multiple 20k+ LOC projects with other people and everything (teams of 10 or more people are good enough to you?). And 20k+ is not even that big, it's not like it offers any great insight regarding software development.

I don't think the size of a project is that important if you're looking for insight into software development. There's certainly poor ways to go about developing small and large projects and most of the insight is to be gained from looking at the mistakes (and lack thereof), whether it's a 100 line piece of glue you wrote which became unreliable and caused major issues or if it's some 100k line project which became increasingly difficult to maintain.

There's a difference between making something a scalable and extensible product from the get go, and writing unmaintainable code.

You can write simple and maintainable code for a simple product which isn't scalable or extensible.

The recent Randall comic is quite fitting:

https://xkcd.com/2730/

I rather think, it has to do a lot with momentum. If you think hard about every step and every change, you will be so slow, that a competing project that just focus on shipping useful features, will get so much traction, that they overcome their wrong design decisions with more man power and after a while, so many people use it, that they continue to use it, despite its flaws.

Otherwise we wouldn't have javascript as the most widespread language for example, with monumental efforts invested in fixing the initial flaws and making it do things, it was never designed for.

the question is 'what is serious?' generally one can go about every piece of code with a mindset that if it fails the sky will fall, or on the other extreme 'let it fail' philosophy.

I like to take a mix of slow and fast approach. While some cases demand test-driven development, in other scenarios the test cases can follow the user demand. I like to build test coverage slowly depending on most used parts of the code. So they coverage catches up slowly but at the same time i am not spending time on test cases for things that don't get used at all.

This means, I would prefer releasing features in small batches and as the features start being used, I start improving the coverage. While this may not work for all the teams or environments, it is one approach to build early stage products. which I mostly do.

Most if not all of the points are not applicable when medical software and firmware is involved. I could never play so fast and loose at work.

Obviously when you want to scale things up, specially to webscale you want mongodb but I rather like the approach of bootstrapping the minimum viable product and then actually using it in order to design the rest.

The world would be a much better place if that was the case.

> when you want to scale things up, specially to webscale you want mongodb

What is about coffee in your actual nostrils that wakes you up more than the full cup itself?

> What is about coffee in your actual nostrils that wakes you up more than the full cup itself?

Not the person you're replying to, but as a food and beverage expert, I'm confident most beverages will yield more powerful emotional and physical responses and quicker absorbtion of many chemical components when taken nasally.

Perhaps OP should try piping their code to /dev/null, which is fast in web scale. Does this editor support sharding? Shards are the secret ingredient in the web scale sauce. They just work.

Thank you for reminding this gem https://youtu.be/b2F-DItXtZs

“Do things that don’t scale”

http://paulgraham.com/ds.html

I don’t want to diminish the work the author has done. For a nice hobby project, sure hack away!

But if you are looking to give this to the world, the lack of planning and emphasis on testing is less than ideal.

It wouldn’t hurt to play with some editors and write a spec so data structures and algorithms can be planned appropriately. After all, there are tons of great examples to get inspiration from!

Reply on news.ycombinator.com