[HN Gopher] Please Do Not Attempt to Simplify This Code
___________________________________________________________________
Please Do Not Attempt to Simplify This Code
Author : whalesalad
Score : 163 points
Date : 2024-08-06 21:30 UTC (1 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jftuga wrote:
| // ==============================================================
| ==== // PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE.
| // KEEP THE SPACE SHUTTLE FLYING. // ================
| ================================================== //
| // This controller is intentionally written in a very verbose
| style. You will // notice: //
| // 1. Every 'if' statement has a matching 'else' (exception:
| simple error // checks for a client API call)
| // 2. Things that may seem obvious are commented explicitly
| // // We call this style 'space shuttle style'. Space
| shuttle style is meant to // ensure that every branch
| and condition is considered and accounted for - //
| the same way code is written at NASA for applications like the
| space // shuttle.
| wouldbecouldbe wrote:
| hahaha well Kubernetes is the opposite of a special shuttle
| that keeps on flying. It crashes all the time, version updates
| etc. If you want stability go to apache or nginx.
| Sohcahtoa82 wrote:
| This comment is a complete non-sequitor. Kubernetes solves an
| entirely different problem from Apache and nginx.
| andix wrote:
| I've never seen Kubernetes crash. I don't have that much
| experience with operating k8s clusters, but on those I've
| seen it just kept on working.
| whalesalad wrote:
| Same. Pods will crash, run out of memory, fail to get
| scheduled, etc... but I have never seen kube itself crash.
| q3k wrote:
| I've been experimenting with k8s and/or running it on
| prod basically since the initial release, and I've so far
| only had one workload-affecting bug.
|
| The bug caused the scheduler to get stuck meaning pods
| assigned to nodes kept running, but no new pods would be
| scheduled.
|
| https://github.com/kubernetes/kubernetes/issues/124930
|
| That's a pretty good track record, and indicates a level
| of fail-safe design (everything continued working, even
| though a critical components kept crashinglooping).
| whalesalad wrote:
| I tried to link directly to these lines, but hn's url sanitizer
| stripped off the anchor tags.
| arwhatever wrote:
| When I looked into Go I found it a bit surprising that someone
| had created a non-expression-based language as late as ~2009.
|
| I have not familiarized myself with the arguments against
| expression-based design but as a naive individual
| contributor/end-user-of-languages, expressions seem like one of
| the few software engineering decisions that doesn't actually
| "depend," but rather, designing languages around expressions
| seems to be unequivocally superior.
| TurningCanadian wrote:
| instead of "expression" you meant "exception", right?
| whalesalad wrote:
| expression as-in s-expression (ex: lisp)
| Jtsummers wrote:
| In the statement/expression-oriented axis of languages, Go
| is a statement oriented language (like C, Pascal, Ada, lots
| of others). This is in contrast to expression oriented
| languages like the Lisp family, most, if not all,
| functional languages, Ruby, Smalltalk and some others.
|
| Expressions produce a value, statements do not. That's the
| key distinction. In C, if _statements_ do not produce a
| value. In Lisp, if _expressions_ do. This changes where the
| expression /statement is able to be used and, consequently,
| how you might construct programs.
| IAmGraydon wrote:
| I'm assuming you mean "non-exception". Apologies if I assume
| incorrectly.
|
| In case I'm correct, this is from Andrew Gerrand, one of the
| creators of Go:
|
| The reason we didn't include exceptions in Go is not because
| of expense. It's because exceptions thread an invisible
| second control flow through your programs making them less
| readable and harder to reason about.
|
| In Go the code does what it says. The error is handled or it
| is not. You may find Go's error handling verbose, but a lot
| of programmers find this a great relief.
|
| In short, we didn't include exceptions because we don't need
| them. Why add all that complexity for such contentious gains?
|
| https://news.ycombinator.com/item?id=4159672
| Smaug123 wrote:
| You appear to have misread "expression" as "exception";
| this is completely unrelated. An expression-based language
| is one that lets you do `let blah = if foo then bar else
| baz`, for example.
| kuschku wrote:
| I used to be skeptical about introducing complex expressions
| to C-syntax languages for a long time until I saw how well
| Kotlin handled `when`.
|
| Now every time I use typescript or go I have trouble trying
| to express what I want to say because `when` and similar
| expressions are just such a convenient way to think about a
| problem.
|
| In go that means I usually end up extracting that code into a
| separate function with a single large `switch` statement with
| every case containing a `return` statement.
| jiggawatts wrote:
| More to the point, the comment in the code mentions
| "combinatorial" explosion of conditions that have to be
| carefully maintained by fallible meat brains.
|
| In most modern languages something like this could be
| implemented using composition with interfaces or traits.
| Especially in Rust it's possible to write very robust code
| that has identical performance to the if-else spaghetti, but
| is proven correct by the compiler.
| supportengineer wrote:
| I went right into the code and looked for 'if' statements
| without 'else' statements. There are plenty. I don't see how
| you can have any exceptions to this rule if you are truly
| committed to capturing all branches.
| mypalmike wrote:
| Someone has obviously simplified the code. Oops.
| throwanem wrote:
| If the 'if' condition matching ends in a thrown exception, a
| return, or likewise, then you don't really need an 'else'
| unless you're using a language which supports conditions and
| resumption (conformant Common Lisp implementations, and not
| really anything else I know of). The 'else', implicitly, is
| that the flow of control leaves the scope of the 'if' block
| at all.
|
| (I haven't read far enough into the code to know that this is
| what they're doing, but the head matter I did read suggests
| as much.)
|
| (I do wish HN supported an inline monospace markup, the
| <code> to a four-space indent's <pre>...)
| jerlam wrote:
| _/ / KEEP THE SPACE SHUTTLE FLYING._
|
| I understand the intent, but it is a bit funny that the comment
| references a system that is no longer operational due to its poor
| safety record.
|
| In ten years or so, will people even remember the Space Shuttle
| in a good light?
| whalesalad wrote:
| Well over 100 successful missions carrying a bunch of people
| and gear up into outer space and then bringing them back home.
|
| I hold it in a good light now, and will likely continue to feel
| that way. As far as human progress and net good, it was a
| success.
| joebob42 wrote:
| 100 is frankly not that impressive for software. A 2-9 system
| will sometimes work 100x in a row, and a 3-9 system usually
| will.
| rco8786 wrote:
| 100 missions. Not 100 code executions.
| joebob42 wrote:
| Sure, but I imagine at least some components only really
| execute a small number of times per flight, or possibly
| never in the case of certain error handling code.
| Stretching the metaphor more than is probably
| appropriate, I'd treat launching the shuttle and having
| it come back as a big integration test. A system that
| passes it's integration test 100 times isn't necessarily
| particularly impressive in terms of reliability.
|
| We run our integration test tens of times a day, and it
| fails once or twice a month. Our system is kinda flaky :(
| AnimalMuppet wrote:
| Right, but the shuttle failures were not software failures.
| ahartmetz wrote:
| As far as we know, software never caused any dangerous
| incidents for the shuttle. You can't say that about
| Arianespace (Ariane 4 #1) or SpaceX (a couple of crashes
| while trying to land - low stakes though) or Airbus ("just"
| some bad UX in critical situations) or Boeing (software
| basically killed a few hundred people).
| ChrisMarshallNY wrote:
| Wasn't a poor safety record whut killed the shuttle. It was the
| cost, and anticipation of degraded safety, in the future.
|
| Even though more astronauts died, because of the two shuttle
| accidents, than any other NASA disaster, the safety record was
| absolutely amazing, when we consider everything that was going
| on.
|
| The code seems damn good code.
| bpodgursky wrote:
| 2/100 catastrophic failures (deaths of entire crew) is not a
| good record even by the standards of spaceflight.
| Sohcahtoa82 wrote:
| For what it's worth, were any of those catastrophic
| failures caused by bad code?
| bpodgursky wrote:
| Did the amount of time spent on code formatting incur an
| opportunity cost for more impactful engineering safety
| investments?
| yreg wrote:
| Probably not.
| whalesalad wrote:
| the issues are pretty well documented and are all human
| failures.
|
| https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_di
| sas...
|
| the challenger disaster is noteworthy as a tragic
| incident because many individuals tried to stop the
| launch knowing this (ahem, hardware) issue was present.
| to many people, it was not a surprise when it happened.
| ajford wrote:
| Given that the engineering safety folks are more than
| likely not the ones writing the code, I doubt it.
| dessimus wrote:
| But in neither case was it due to a code failure that put
| the shuttle into an unrecoverable state, but rather one the
| falls into materials and/or mechanical engineering.
| Sakos wrote:
| Considering the contemporary competitors, I'm not sure this
| is true. I have a vague recollection that the Soviet (and
| Russian) space program was quite error prone and
| experienced plenty of accidents, including disastrous ones
| with astounding loss of life. Although I guess their track
| record of accidentally killing astronauts is better (4 vs
| 15).
|
| https://en.wikipedia.org/wiki/List_of_spaceflight-
| related_ac...
| andix wrote:
| The space shuttle became obsolete technology after all those
| years. Would've needed a redesign.
| Alupis wrote:
| > The space shuttle became obsolete technology after all
| those years. Would've needed a redesign.
|
| Are people aware of how old the technology is that's
| currently putting objects and people into space? No, the
| space shuttle was not obsolete. It was expensive... very
| expensive. To this day, we still don't have a replacement
| for it's capabilities though.
| echelon wrote:
| _Dream Chaser_ wants to fill those shoes.
|
| - https://www.sierraspace.com/dream-chaser-spaceplane/
|
| - https://en.wikipedia.org/wiki/Dream_Chaser
|
| - https://www.nbcmiami.com/news/local/a-new-space-plane-
| gets-r...
|
| - https://www.youtube.com/watch?v=jVIXI09-AYw
|
| - https://www.youtube.com/watch?v=4Q8tGVUnoZg
| lmm wrote:
| > Even though more astronauts died, because of the two
| shuttle accidents, than any other NASA disaster, the safety
| record was absolutely amazing, when we consider everything
| that was going on.
|
| That's "the operation was successful but the patient died"
| logic. Killing over 1% of your riders is not a good safety
| record! No ifs, no buts.
| andix wrote:
| This code is keeping the space shuttle flying in our memories.
| Kubernetes never kept the space shuttles flying in a literal
| way.
| peoplefromibiza wrote:
| The shuttle program was killed by costs. Keeping it flying
| safely was really expensive.
|
| Despite the safety record you mention, it was the best
| approximation of a spaceship that we, as a human species, ever
| created.
|
| A spaceship program is something you either fully commit to by
| spending billions on it, or you abandon it.
|
| Nevertheless, there has been nothing that has come close to it
| since.
| evil-olive wrote:
| > a system that is no longer operational due to its poor safety
| record
|
| the safety problems with the shuttle were, broadly speaking,
| hardware problems and not software problems.
|
| from "Appendix F - Personal Observations on Reliability of
| Shuttle" [0], which was Richard Feynman's appendix to the
| report on the 1986 Challenger disaster:
|
| > To summarize then, the computer software checking system and
| attitude is of the highest quality. There appears to be no
| process of gradually fooling oneself while degrading standards
| so characteristic of the Solid Rocket Booster or Space Shuttle
| Main Engine safety systems.
|
| he specifically highlighted the quality of the avionics
| software as an example of how engineering on a project like the
| Shuttle could be done well, and wasn't doomed to be low-quality
| and unsafe simply by virtue of being a large complicated
| government project.
|
| 0: https://www.nasa.gov/history/rogersrep/v2appf.htm
| trte9343r4 wrote:
| Space Shuttle was part of "Star Wars" project to bring down the
| Soviet Union. It met its goals by being super expensive.
|
| Space flights were just side project...
| tomcam wrote:
| Is its poor safety record due to software failures?
| seabass-labrax wrote:
| The situation with the Space Shuttle is more complex than
| simply poor safety. In terms of missions, it has a better
| record than many other launch vehicles - 2 fatal missions out
| of 135 for the shuttle, 2 out of 66 for the Soviet-era Soyuz,
| and a frighteningly poor 1 fatal mission out of only 12
| spaceflights for SpaceShipTwo.
|
| However, the Space Shuttle had a much larger crew capacity than
| most missions probably needed (up to eight astronauts compared
| to Apollo or Soyuz's three), especially considering that the
| majority of Soviet/Roscosmos, ESA and CNSA missions were
| autonomous and completely unmanned - no crew to endanger!
|
| Perhaps that makes the metaphor even better for Kubernetes: an
| highly engineered, capable and multi-purpose system requiring
| considerable attention, and probably used a little more than it
| should be.
| mihaaly wrote:
| Since they used aluminium in the Space Shuttle would that also
| reflect poor safety record on using aluminium in mission
| critical situations?
| vednig wrote:
| Main reason it is, as it is, and is usually not seen in any other
| languages is that go does not has operator functions for variable
| fallbacks and logical error handling. But overall this helps in
| improving performance of application(on a large scale).
| boilerupnc wrote:
| Related article on Space Shuttle Software Quality [0]
|
| Excerpt: "But how much work the software does is not what makes
| it remarkable. What makes it remarkable is how well the software
| works. This software never crashes. It never needs to be re-
| booted. This software is bug-free. It is perfect, as perfect as
| human beings have achieved. Consider these stats : the last three
| versions of the program -- each 420,000 lines long-had just one
| error each. The last 11 versions of this software had a total of
| 17 errors. Commercial programs of equivalent complexity would
| have 5,000 errors."
|
| [0] https://archive.is/HX7n4
| emerongi wrote:
| 5000 / 17 [?] 295. Is it a fair assumption to make that a
| commercial program of equivalent complexity would take 295x
| fewer man-hours?
| fleischhauf wrote:
| without any knowledge of the other processes involved in
| space shuttle software development, I highly doubt that the
| correlation is that easy
| burkaman wrote:
| No, I don't think so, 295x is a crazy high factor. The
| article says 260 people are involved, and let's generously
| say it took 20 years to write the software (the first mission
| was 10 years after the program started and it was around for
| a total of 40 years).
|
| Dividing by 295 means a commercial team of the same size
| could have done it in less than a month. Or with a 10x
| smaller team, about 8 months. I don't think either of those
| are plausible.
| fleischhauf wrote:
| I wonder about spaceX track record
| cpf_au wrote:
| One of my all-time favourite articles. Amazing that something
| from the internet in 1996 is still accessible!
| dpedu wrote:
| > Consider these stats : the last three versions of the program
| -- each 420,000 lines long-had just one error each.
|
| What exactly do they mean by this? If each of the 3 versions
| had exactly one bug, isn't this just a weird way of saying the
| first 2 fixes either didn't work or introduced a new bug?
| daemonologist wrote:
| Or maybe between one version and the next they only found one
| bug (there may have been bugs in the first version which
| weren't fixed until the third or later) - this seems more
| plausible to me since it's... rather difficult to count bugs
| until after you know about them.
|
| Of course now the greatness of the feat depends on how much
| testing there was between versions, but given that it was the
| shuttle there was probably a lot.
| rqtwteye wrote:
| It would be interesting to see the NASA approach compared to
| how SpaceX does things. Considering that they have done manned
| missions they seem to have very similar requirements.
| philip1209 wrote:
| Ah, 2k-line files makes me miss my days of coding in Go.
| pizzafeelsright wrote:
| Join me. Still crushing it.
| LAC-Tech wrote:
| 2k lines is a whole widely used and feature filled open source
| library in many languages.
| stitched2gethr wrote:
| Yes, but often density is at odds with readability.
| jsbg wrote:
| > // 1. Every 'if' statement has a matching 'else' (exception:
| simple error
|
| > // checks for a client API call)
|
| > // 2. Things that may seem obvious are commented explicitly
|
| Honest question: Why invent "safety" practices and ignore every
| documented software engineering best practice? 2,000 line long
| modules and 200-line methods with 3-4 if-levels are considered
| harmful. Comments that say what the code does instead of
| specifying why are similarly not useful and likely to go out of
| date with the actual code. Gratuitous use of `nil`. These are
| just surface-level observations without getting into coupling,
| SRP, etc.
| bayindirh wrote:
| Because sometimes, there's "No Other Way(TM)".
|
| Arbitrary line limits tend to unnecessary fragmentation. Add
| includes, licenses, glue code and comment; and you have an
| unapproachable spaghetti.
|
| Try to keep methods to 200 lines in high performance code, and
| see your performance crash and burn like Icarus' flight.
|
| When you read the comments in the code, you can see that they
| simplified the code to a single module, and embedded enormous
| amount of know-how to keep the code approachable and more
| importantly, _sustainable_.
|
| For someone who doesn't know the language or the logic in a
| piece of code, the set of comments which outline what the code
| does is very helpful. In six months, your code will be foreign
| to you, so it's useful for you, too.
|
| Comments are part of the code and the codebase. If you're not
| updating them as you update the code around them, you're
| introducing documentation bugs into your code. Just because the
| compiler doesn't act on them doesn't mean they are not
| functional parts of your code. In essence they're your
| knowledge, and lab notebook embedded in your code, and it's way
| more valuable in maintaining the code you wrote. They are more
| valuable than the code which is executed by the computer.
|
| Best practices are guidelines, not laws or strict rules. You
| apply them as they fit to your codebase. Do not obey them
| blindly and create problematic codebases.
|
| Sometimes you have to bend the rules and make your own, and
| it's totally acceptable when you know what you're doing.
| johnnyanmac wrote:
| > Try to keep methods to 200 lines in high performance code,
| and see your performance crash and burn like Icarus' flight.
|
| Are these loops in Kubernetes so hot that extra microseconds
| for some program stack manipulation will affect performance?
| I never took Kubernetes as a hyper-real time application.
|
| >Do not obey them blindly and create problematic code bases.
|
| I don't know the code so won't question it specifically, but
| wouldn't this also apply to "space shuttle programming"? I
| feel Space shuttle programming's job in many ways is in fact
| to try and remove ambiguity from code. But not by explaining
| the language, but the variables and their units. I sure
| wouldn't mind spamming "units in cm" everywhere or explaining
| every branch logic if it's mission critical. Not so much this
| inconsistent doxygen/javadoc style documentation on every
| variable/class. If you're going to go full entrprise
| programming, commit to it.
|
| Above everything else, the big thing going through my mind
| reading these are "a proper linter configuraion would have
| really helped enforce these rules".
| ajuc wrote:
| There's nothing inherently wrong with a 200-line-long method.
| If the code inside is linear and keeps the same level of
| abstraction - it can be the best option.
|
| The alternative (let's say 40 5-line-long methods) can be worse
| (because you have to jump from place to place to understand
| everything, and you can mess up the order in which they should
| be called - there's 40! permutations to choose from).
| slaymaker1907 wrote:
| I tried writing in this "safe" way for quite a while, but I
| found the number of bugs I wrote was much higher and took way
| longer than just using railroad-style error handling via early
| returns.
|
| The problem with having an explicit else for every if block is
| that the complexity of trying to remember the current context
| just explodes. I think a reasonable reframe of this rule would
| be "Every if-conditional block either returns early or it has a
| matching else block". The pattern of "if (cond) { do special
| handling }" is definitely way more dangerous than early return
| and makes it much harder to reason about.
| mden wrote:
| > Why invent "safety" practices and ignore every documented
| software engineering best practice?
|
| That seems unnecessarily brutal (and untrue).
|
| > 2,000 line long modules and 200-line methods with 3-4 if-
| levels are considered harmful
|
| Sometimes, not always. Limiting file size arbitrarily is not
| "best practice". There are times where keeping the context in
| one place lowers the cognitive complexity in understanding the
| logic. If these functions are logically tightly related
| splitting them out into multiple files will likely make things
| worse. 2000 lines (a lot of white space and comments) isn't
| crazy at all for a complicated piece of business logic.
|
| > Comments that say what the code does instead of specifying
| why are similarly not useful and likely to go out of date with
| the actual code.
|
| I don't think this is a clear cut best practice either. A
| comment that explains that you set var a to parameter b is
| useless, but it can have utility if the "what" adds more
| context, which seems to be the case in this file from skimming
| it. There's code and there's business logic and comments can
| act as translation between the two without necessarily being
| the why.
|
| > Gratuitous use of `nil`
|
| Welcome to golang. `nil` for error values is standard.
| ljm wrote:
| There is no single canonical suite of best practices.
|
| There is also nothing harmful or unharmful about the length of
| a function or the lines of code in a file. Different languages
| have their opinions on how you should organise your code but
| none of them can claim to be 'best practice'.
|
| Go as a language doesn't favour code split across many small
| files.
| johnnyanmac wrote:
| It's all opinions and "best practice" isn't some objective
| single rule to uphold.
|
| But generally, best practices are "best" for a reason, some
| emperical. The machine usually won't care but the humans do.
| e.g. VS or Jetbrains will simply reject autocompletion if you
| make a file too big, and if you override the configuration it
| will slow down your entire IDE. So there is a "hard" soft-
| limit on how many lines you put in a file.
|
| Same with Line width. Sure, word wrap exists but you do
| sacrifice ease and speed of readability if you have overly
| long stretches of code on one line, adding a 2nd dimension to
| scroll.
| jsbg wrote:
| > There is no single canonical suite of best practices.
|
| There kind of is, though. Most software engineering books
| argue for the same things, from the Mythical Man Month to
| Clean Architecture.
|
| > Different languages have their opinions on how you should
| organise your code
|
| In general best practices are discussed in a language-
| agnostic manner.
| cellularmitosis wrote:
| If you think these things are considered harmful, I'd encourage
| you to read "John Carmack on Inlined Code" http://number-
| none.com/blow/john_carmack_on_inlined_code.htm...
|
| "The flight control code for the Armadillo rockets is only a
| few thousand lines of code, so I took the main tic function and
| started inlining all the subroutines. While I can't say that I
| found a hidden bug that could have caused a crash
| (literally...), I did find several variables that were set
| multiple times, a couple control flow things that looked a bit
| dodgy, and the final code got smaller and cleaner."
|
| If Carmack finds value in the approach, perhaps we shouldn't
| dismiss it out of hand.
|
| Also worth noting his follow-up comment:
|
| "In the years since I wrote this, I have gotten much more
| bullish about pure functional programming, even in C/C++ where
| reasonable... When it gets to be too much to take, figure out
| how to factor blocks out into pure functions"
| jsbg wrote:
| Thanks. This is the first instance of a respected software
| engineer arguing in favor this style that I have read
| (contrast with Dave Thomas, Kent Beck, Bob Martin, etc.)!
| ChrisArchitect wrote:
| Discussion from 2018:
| https://news.ycombinator.com/item?id=18772873
| whalesalad wrote:
| wtf I submitted this in 2018?????
| pranshum wrote:
| Our obsessions never change!
| daedrdev wrote:
| The joys of the human memory
| EgoIsMyFriend wrote:
| Previous discussion https://news.ycombinator.com/item?id=18772873
| (Dec 2018, 1552 upvote, 631 comments)
| dangsux wrote:
| By the same user no less
| renewiltord wrote:
| Why was Space Shuttle code so good and the engineering so bad?
| The thing was expensive and shit and had a 1.5% catastrophic
| failure rate for passenger transport. Soyuz was two orders of
| magnitude better.
|
| Russia/USSR have reputation for McGyvering things and US has
| reputation for gold-plating but US ship is killing people every
| 65 flights and Russian ship has over 1500 launches without death.
|
| Maybe engineers should learn from either Soviet/Russian engineers
| or from NASA software engineers. Both are making more reliable
| things.
| teractiveodular wrote:
| Multiple books have been written on this very topic, but the
| TL;DR is that the problem was not the engineering, but the
| absurd, often mutually contradictory design decisions forced on
| it for political reasons.
|
| https://en.wikipedia.org/wiki/Space_Shuttle_design_process
| nvarsj wrote:
| [delayed]
| ranger207 wrote:
| https://waynehale.wordpress.com/2012/11/12/after-ten-years-a...
|
| > I need to give you the issue from the NASA point of view so
| you can understand the pressures that they were under. In a
| developmental program, any developmental program, the program
| manager essentially has four areas to trade. The first one is
| money. Obviously, he can go get more money if he falls behind
| schedule. If he runs into technical difficulties or something
| goes wrong, he can go ask for more money. The second one is
| quantity. The third one is performance margin. If you are in
| trouble with your program, and it isn't working, you shave the
| performance. You shave the safety margin. You shave the
| margins. The fourth one is time. If you are out of money, and
| you're running into technical problems, or you need more time
| to solve a margin problem, you spread the program out, take
| more time. These are the four things that a program manager
| has. If you are a program manager for the shuttle, the option
| of quantity is eliminated. There are only four shuttles. You're
| not going to buy any more. What you got is what you got. If
| money is being held constant, which it is--they're on a fixed
| budget, and I'll get into that later--then if you run into some
| kind of problem with your program, you can only trade time and
| margin. If somebody is making you stick to a rigid time
| schedule, then you've only got one thing left, and that's
| margin. By margin, I mean either redundancy--making something
| 1.5 times stronger than it needs to be instead of 1.7 times
| stronger than it needs to be--or testing it twice instead of
| five times. That's what I mean by margin.
|
| > It has always been amazing to me how many members of
| Congress, officials in the Department of Defense, and program
| managers in our services forget this little rubric. Any one of
| them will enforce for one reason or another rigid standard
| against one or two of those parameters. They'll either give
| somebody a fixed budget, or they'll give somebody a fixed time,
| and they forget that when they do that, it's like pushing on a
| balloon. You push in one place, and it pushes out the other
| place, and it's amazing how many smart people forget that.
| neilv wrote:
| BTW, when linking to a file in GitHub like this, you can link to
| a range of lines of the file, by using the URL fragment
| identifier, like: #L60-L92
|
| https://github.com/kubernetes/kubernetes/blob/60c4c2b2521fb4...
| runlevel1 wrote:
| You can click a line number to select the start of the range,
| then shift+click to select the end of the range to do this
| automatically.
| ivanjermakov wrote:
| I think the whole file worth skimming through
| kylehotchkiss wrote:
| Is this like a thing where people want to appear to be
| contributing to open source and remove all the 'unneeded' elses
| from a codebase?
| dangsux wrote:
| Yes because it puts you as a contributor on the github page.
| quotemstr wrote:
| This sort of code strikes me as an ideal candidate for
| translation into a declarative, rule-based, table-driven system.
| Such a thing is more comprehensible and more verifiable than ad-
| hoc imperative if-clause-rich code.
|
| Messy code of this sort is usually a sign of a missing
| abstraction.
| copypasterepeat wrote:
| I've obviously only skimmed the code, but honestly it doesn't
| look that bad to me. Sure there are things I would do
| differently, but I've seen much, much worse. At least the code
| follows a single convention, and has the appearance that
| everything was thought through and that there is method behind
| the madness, as it were. I'd take this any day over the typical
| mishmash of styles, lazy coding, illogical code structure etc.
| that I've encountered so many times.
| matthewmacleod wrote:
| Personally I love this level of verbosity in code. There are
| still way too many levels of nested control flow for my taste--I
| find that makes it exceptionally hard to retain context--but at
| least there are early returns.
___________________________________________________________________
(page generated 2024-08-06 23:00 UTC)