Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Every time I look at modern source code, with hundreds of lines of classes, constructors, setters and getters that could be done with a record type or two, and far, far less code, I have this same feeling.


Context is everything.

Writing an app that going to do like 3 things? Keep it barebones.

Writing an app that will eventually be 100k lines of code that runs a business. Spend a lot of time organizing and abstracting! Mistakes in your architecture will be expensive to correct but balance avoiding those with premature optimization.

And beyond just the purpose of the app, remember who is going to build and maintain it. A project with 100 engineers and a project with 1 engineer should use very different architectures and project management regardless of the problem they are solving.


Nah, all this is just rationalisation. I've already heard this a hundred times and seen it go awry every time afterwards.

Complex architectures and unnecessary abstraction are the main reason lots of apps "eventually" get to have the 100k lines of code you mention and require those 100 engineers to maintain in the first place.

It's a self-fulfilling prophecy: When you follow the complex architectures where you need "hundreds of lines of classes, constructors, setters and getters that could be done with a record type or two" that GP mentioned, it's no wonder that the software reaches 100k LOC. Could have been 10k or 20k if the grandparent did it. When there are too many levels of abstraction to navigate, it's no wonder you need 100 engineers to maintain. Could have been 5 or 10.

There is nothing preventing those complex apps from using something that's more expressive and simpler like the records pointed by GP. And there is absolutely nothing in the popular complex architectures we see everyday that is proven to be inherently scalable.

As long as the original goals are maintained, you'll still reap the benefits: testability, composability, predictability, maintainability. And you don't need complexity to reach those goals. In fact, complexity is what people should be running away from to get to them.

If you want to burn both money and time for no future benefit other than having a behemoth of a project, however, that's your prerogative.

The only major issue with "simpler code" as advocated by GP is that it's not sexy. You can't put "wrote simple code" in your resumé.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: