161–170 of 601 posts
A customer-facing dashboard. Yes, a dashboard. How bad can a dashboard be bad you ask? Well, for one, the dashboard had tabs, and each tab was a separate webapp hosted on a separate server. And each team was responsible for developing and maintaining the webapp that their team was incharge of (i.e the User team in charge of Users webapp, Feature1 team incharge of Feature1 webapp). Now add on the fact that different t…
Not exactly code but people would be scared if they found out how much of the Internet, at OSI layers 1, 2 and 3, is held together by the metaphorical equivalent of duct tape and twine. At OSI layer 1, sometimes almost literally. Major ISP outages that have been caused by somebody tripping over the $5 power strip that was powering the authoritative nameserver.
How about barbed wire? https://news.ycombinator.com/item?id=15910263
My own CMS. Here's the function signature of the heart of it, which depending on circumstance may call itself recursively. function a_nodes_list_trees( $site_url, $base_url, $mode, $site_id, $max_subtree_depth, $nlevels, $node_id = 0, $tree_id = 0, $nleft = 0, $nright = 0, $nlevel = 0, $current_subtree_depth = 0, $flags = 0, $order = 'tree', $inline = false, /* needed when loading stuff via ajax*/ $skipped_types = []…
My god man that is beautiful. I'm going to put that on a poster.
1. Millions lines of messy Java code with annotations and dependency-injection form a multi-shard distributed job with tens of distributed downstream backends, some of which provide fake always-success synchronous RPCs hiding the fact that the underlying operations are actually asynchronous and may fail very often. What makes it worse to work on these code is it was built with a single transactional underlying database but then due to reliability issues of the single database, data are now across at least three different transactional databases. This causes endless race conditions and concurrency issues to fire everywhere. The production release of this distributed job used to be once every week, now multi-months is normal, and quarter rollback is not a surprise to people.
2. Almost million lines of messy C++ code with several .cc/.cpp files containing tens of thousands C++ code, some class implementations are across multiple .cc/.cpp files. I have always been scared when touching some of these giant .cc/.cpp files. People who have been working on the code for years can still easily make ignorant mistakes when adding/modifying a small feature (with so-called fully unit-test overage of course). There are multi-million lines of testing code, which is almost 10x of the code be tested, but most of them are bogus and almost test nothing, hence silly mistakes are everywhere, everyday. Even the original author of the code base needs 5 follow-up fixes in order to make a 10-line behavior change work.
For both code bases and the jobs running these code, people are now talking about breaking them into microservices, by converting function calls in the existing code bases into RPCs. I can foresee a tremendous number of service outages are coming...
Worked on a file-sync system written in Python 2.6/7 by B-players in a hurry. Lots of microservices, before it was cool, that was fine. Shitty code everywhere, commented code, dead code, 5 blank lines here and there. Many lines over 100 chars, lots pushing 150 or 200+. Didn't understand how to use argparse or logging but tried. Crazy mixed-case WTFExtremelyLongSillyNamesEverwhereSendThis at the command-line interface…
My only code style rule is don’t write lines more than 100 char which usually means “one statement per line”. It floors me how people think it’s acceptable to write code that you have to scroll not one but two axises to try and comprehend. Reading code should be like reading a book. And forcing yourself to write code that grows vertically instead of horrizontally usually solves all the problems and more that people d…
15 years later the app was close to half milion lines long of huge bowl of spaghetti code. Only comments in whole codebase were timestamps. I don't know why he dated his code, but I find it fascinating: he never deleted basically anything so you can find different timeframes of when he discovered various concepts. There is use-exception-instead-of-if period, there is time when he discovered design patterns, there is time before he learnt SQL so all the database queries was done by iterating over whole tables and such. I am sure I will find commented Hello world somewhere in the code someday.
I am working on this codebase for 10 years. Code quality improved and major issues get fixed, but there is not enough budget to actually rewrote whole system, so after all it is more or less huge spaghetti monster and I get used to it.
Earlier quoted context omitted.
Presumably, down the road, you'll either be a defunct company or doing well enough to afford 10 times the manpower to fix things. Facebook was a spaghetti code mess in the beginning. I'm sure it caused them some growing pains, but moving too slowly early on would have likely been more costly.
> Presumably, down the road, you'll either be a defunct company or doing well enough to afford 10 times the manpower to fix things. Only in startup land which is still a small fraction of our industry. Most places will never have 10 times the manpower to fix things and are hurting themselves by not doing them properly in the first place. > Facebook was a spaghetti code mess in the beginning. I'm sure it caused them s…
if it works, it's not bad code
