1. 11

  2. 13

    @itamarst dude, time to step it up. There’s not much content here, and this is a clickbaity blogspam title. The article doesn’t offer much - one time this thing happened to you, and a nice thing to do when you make software is iterate?

    Probably being a bit harsh, but I don’t come to lobste.rs for articles that are short, sugary and don’t particularly contribute anything other than ‘bad things are bad, good things are good’ with no exploration or development or original content.

    1. 2

      Hey, sorry you didn’t like the article.

      I don’t know what to say about “clickbait title”, I’m just not very good at good titles mostly.

      As far as actual content: iteration is pretty basic, yes, except many people don’t do it. So still seems worth repeating.

      But beyond that… the point I’m trying to get across isn’t quite the same as “iterate”:

      • Iteration is a technique, “start with simple version and flesh it out in each release,” let’s say.
      • Incremental results are a desirable goal, with iteration being one way to achieve that goal.

      And so I think the idea of incremental results is more powerful because it’s applicable more broadly. E.g. sometimes you can achieve incremental results without iteration:

      • If each individual feature provides value on its own then you can incremental results with less iterative, more cumulative development.
      • Incremental results can be structured into the output, e.g. the way Progressive JPEGs render incrementally.

      But perhaps that should all have been in the original article.

      1. 7

        Your article also doesn’t provide any evidence that what you’re espousing does produce success. Your correct way isn’t actually a success store, it’s a figment of your imagination. It might be correct but there is no way to know based on this article. Maybe your correct way would have resulted in 6mo - 1yr delay for other reasons.

        1. 2

          No, but I implemented a program per “the right way” [1]. It’s written in Lua using LPeg (because of the amount of parsing involved) and it has proved to be “mostly fast enough.” It’s only recently (the past two months out of 18 months in production) that a performance issue has popped up (because traffic to the service has vastly increased) and the issue only happens intermittently (and usually don’t last long—by the time it’s alarmed, it’s over). Not a bad thing really, as the code is straightforward and easy to work on [2].

          [1] It was intended to be a proof-of-concept (at least in my mind), only it ended up in production, without anyone informing me (long story).

          [2] Thank God Lua has coroutines. It makes writing network code much nicer, as it’s imperative instead of a nest of callbacks with logic spread out all over the place.

        2. 3

          As thin as it may seem to some, I wish my boss would read it…

          1. 4

            Your boss will read the whole thing and only will remember “But maybe a Python version would have been fast enough.”

            1. 2

              ah ah ah, true. Unfortunately.

      2. 5

        I agree the article is a bit thin, but it’s true. The way I’ve heard it described is doing a vertical slice of an entire feature, rather than horizontally filling out your implementation. The end user features have to drive the architecture and not the other way around.

        Another way to think about it is to do end-to-end tests first; don’t write tests for internal interfaces which will undoubtedly change based on contact with the real world.

        1. 1

          I also think that ‘vertical slices’ can be simpler to implement. Here though it seems that some kind of messaging protocol had to be implemented. It seems, at list to me, complicated to slice it vertically mostly as everything should work together. No?

          1. 2

            Yes, I think you mean it’s silly to slice it horizontally if you really need the end-to-end messaging; doing it vertically is obvious. I think the advice is obvious in most circumstances, but I guess in a big organization you can fall into the trap of “well this team will just implement the interface, and then we’ll build to that interface”.

            But that doesn’t really work… Well, you might be able to brute force it, but the result will be suboptimal (buggy, hard to maintain, perform badly). A better approach is to have a small team to build out the end-to-end proof of concept, and then split up the work with a more stable architecture.

            Certain architectural decisions are almost set in stone from the beginning, and very hard to change later.