9 ms·

From my perspective - speed is about 2 things: more smaller iterations, confirming you're working toward a desired outcome. Over my career, I've been surprised

• Zetice 3y ago
  I cannot possibly emphasize this more strongly. It's so important to deliver complete and working products quickly and regularly, that it's worth the cost of the occasional lost customer who leaves because all of their needs aren't met immediately. A) they're rarer than people seem to think and, B) the people you gain due to this incremental approach more than cover the losses. That said, some devs interpret "quick" to mean "sloppy", which is not correct. When you can cut releases hourly the cost of some kinds of bugs does go down, but fewer bugs is better, and as always some categories of bugs are, "never, ever" (e.g. data corruption/leak, security bugs, outage inducing bugs).
  • afarrell 3y ago
    To go fast, stay humble and use boring technology.
    • j45 3y ago
      .. in a simple and flexible way.
  • andai 3y ago
    I agree completely. That sounds much better than my current strategy of delivering incomplete and broken products at unpredictable intervals.
    • EliRivers 3y ago
      My highly specialised sarcasm sensors (honed in the UK) suggest that this is not in fact your current deliberate strategy; that said, I have worked for so many groups and companies where that is exactly what happens, even if they think they're planning for something else to happen, and it's obvious to pretty much everyone involved that that is what is happening and will keep happening.
      • andai 3y ago
        I was being humorous, but also telling the truth! I went straight from hobby programming to freelancing, so I've been "rediscovering" best practices the hard way. I did actually intend to do things properly, but client asked "can it be done faster" and I thought "sure I'll just ship fast and then rewrite it later"... ha! Project became so unmaintainable, development ground to a halt. (I am doing the rewrite now...) Turns out sometimes my job is to say "no."
        • steve_adams_86 3y ago
          This is the side of software where soft skills are critical. Navigating when and how to say no can be extremely difficult, but it’s arguably crucial to operating effectively and sustainably. Early in my career, everything was a yes and it cost me a lot of sanity. It rarely cost me clients because I was so diligent about keeping things on the rails, but that seemed to come with an inversely proportional cost to my well-being. It took me a long time to realize that saying no is kind of like saying yes; you’re saying yes to getting the project done on a reasonable timeline and with the budget the client has, and most importantly, with your happiness intact. Saying yes at the wrong time can be saying no to finishing the project at all. It’s the right, and in a sense “nice” thing to do for everyone involved. If you’re a chronic people pleaser, this kind of work can be extremely taxing (speaking from experience).
    • collenjones 3y ago
      Thanks. Hot coffee just came out of my nose.
    • 3y ago
  • gedy 3y ago
    > That said, some devs interpret "quick" to mean "sloppy", which is not correct. Totally agree, but I've seen some devs completely melt when we need to go fast/iterate. For them, they really do produce sloppy work when they go too quickly. Many "big thinker" types are like this. Not defending it, just an observation.
  • hinkley 3y ago
    With a good sales team, you can land customers who don’t see all the features they need, because you’re routinely delivering a solid if simple product that gets major new functionality a few times a year and if you just hold on we will get your feature to the top of the list. Those paying customers are where your MRR comes from. Another case of perfect being the enemy of good.
  • aeternum 3y ago
    There is high overlap between customers who leave because their needs aren't met immediately and customers whos needs will never be met.
  • natmaka 3y ago
    I agree, and would add "(nearly)-no software regression" (no "a feature that has worked before stops working"), and never twice the same one.
• boredemployee 3y ago
  I wish the PO of my team read it. He is so insecure to talk to customers and iterate with them that it gets on my nerves. He always have an ideal of "finished work" that, very often, we end delivering something not finished and/or wrong because we didn't iterate enough. Customers not always know what they want even though they say that they know what they want.
  • cbhl 3y ago
    If they find the appeal to authority useful, I'd grab them a copy of _Software Engineering at Google_ and leave them a bookmark in "Help Me Hide My Code". You can find the text here: https://abseil.io/resources/swe-book/html/ch02.html#help_me_hide_my_code https://abseil.io/resources/swe-book/html/ch02.html#help_me_... (disclaimer: work there, but wasn't involved in the book at all)
    • sureglymop 3y ago
      This is interesting and I agree with it. I think the problem is that it's not necessarily irrational insecurity. In computer science especially people can be very pedantic and quick to call out an individual or shut down the work of someone who is learning but is not yet on the same level of skill. Now if nothing is being hidden and all code is made public there is a big window for such criticism. The thing is that, often, a developer already knows how to make their code better, solve their problem or get rid of some unnecessary abstraction. But they just don't have the time to do that. They don't have time for perfection. So when their work then gets criticized pedantically even though they already are aware of all those things it must be a very frustrating. I certainly know what it's like to have the urge to rewrite something and I may on paper already know exactly what needs to be changed. Having something you know is imperfect out there feels stressful.
• Ixiaus 3y ago
  I really like the framing of "providing relief". I think it also makes sense to allow the definition of who experiences the relief to be flexible (e.g in some cases the audience that experiences relief might be developers, security engineering, sre, etc. not just customers...)
• PartiallyTyped 3y ago
  > The way I see it, if the problem is important - any early solution should provide some relief. If some initial relief isn't wanted, the problem is probably not important. I experienced this today, just now. The whole org’s release for fall was hinging on what I was proposed… the relief of everyone once the presentation was over and it all clicked, when they saw the light at the end of the tunnel, that the path that I had uncovered towards that is reasonable, and tenable is priceless. I understand now that I live for this shit. 10/10 would do it again and again and again.
• dkarl 3y ago
  It's interesting that people almost never disagree with this when they're the customers. We love seeing progress, even if it's a small portion of what we need. When frequent updates show that progress is slow, we're glad we're aware, and we don't blame the updates themselves for slowing the project down. In the rare cases where we feel like the process demands too much of our attention, we don't stress about it; we just say, "Looks great. Let's talk again in two weeks or when you have completed feature X." Those hypothetical drawbacks only loom large in our minds when we're the ones doing the work.
  • kubanczyk 3y ago
    What about those invisible people who gave it a try and decided there were just too many gaps and bugs? They are not customers anymore and probably never will be.
    • dkarl 3y ago
      When the only way to get feedback on something is to go live to random customers, yeah, that's a difficult decision. I was thinking of situations where you are getting feedback on pre-launch software from a customer or from your own product organization, or you have an established product and some of your customers opt-in to beta functionality because they want the opportunity to influence your direction. I agree there are situations where the worse mistake is giving people a bad first impression.
• boplicity 3y ago
  As a customer of startups, I really abhor this attitude. Especially when it lingers for years after the initial product launch. Which is shockingly common. For example, partially complete features are often completely abandoned for years and years, because they're "good enough." Unfortunately, good enough, often means unhappy customers actively looking for new competitors. One company in particular, I absolutely despise, because of this. They are pretty much only focused on releasing new features. The old features, while functional, are in desperate need of improvement. (In many very obvious ways.) This particular company had a good IPO. Their stock then dropped 90%. I wonder why.
  • jrochkind1 3y ago
    > They are pretty much only focused on releasing new features. My guess is that behavior is NOT motivated by the theory "deliver early drafts with more smaller iterations", but is instead motivated by the theory "the people who decide to buy our products do it based on feature checklists, rather than quality of anything." These are actually not even aligned theories. The "smaller iterations with early drafts" appraoch is best done with fewer features included, not more features that are incomplete. Many markets incentivize companies to deliver crappy software, and it is frustrating, but not, I think the fault of an agile/iterative/deliver-early-and-often approach. If you can make the most money by delivering a giant feature list of crappily implemented poorly-thought out features that don't fit well together, you'll tend to do that, regardless of theory of project management.
  • mvdtnz 3y ago
    > Unfortunately, good enough, often means unhappy customers actively looking for new competitors. Here's the thing though - it's your intuition that customers are unhappy, but the startup in question has actual data. It's entirely possible that a small group of people similar to you are unhappy but for a majority of the userbase the feature has gone as far as it needs to. Resources are scarce and priorities need to be changed, which sometimes means making hard decisions.
    • Retric 3y ago
      Alternatively, the rapid failure after IPO is a suggestion that their customers weren’t happy, but the plan was short term pump and dump. It’s not always easy to say if something is stupid or fraudulent, but sometimes it really is just a scam.
• ojbyrne 3y ago
  I once worked on a team, in house at a company, where we were tasked with developing a prototype, in a scripting language with a well-known web framework. Meanwhile another team at a consulting company, was tasked with developing the final product in java, all very enterprise. The outside company ended up with a failed project, missing deadlines and going over budget multiple times. The prototype became the product.
  • imtringued 3y ago
    Let me guess. Someone used JSF and hibernate in the same project. That is an easy way to blow up development time by a factor of 5x to 10x for literally no benefit.
  • vsareto 3y ago
    >The outside company ended up with a failed project, missing deadlines and going over budget multiple times. The prototype became the product. Getting paid to fail is a decent second place prize
• bfung 3y ago
  > speed is about 2 things: more smaller iterations, confirming you're working toward a desired outcome. Well put. Too many managers and execs use the word "speed" but never define it for others to make actionable. Scenarios in real life: Coder: "what's important while we're working?" Exec: "Speed." _feeling_cool_ Coder: "I authored features a,b,c,e,..x,y,z ~ already working fast, gimme a raise!" Exec: _realizes none of those features were desired objectives_ ... Or Senior software engineer: It'll take 9 months, 5 devs, and $200k to run... Everyone else: ... not even sure business will be kicking in 9 months ...
• deepGem 3y ago
  I think even talking about the draft gives you an idea about the severity of the problem. My experience has been the same. If the problem is severe enough a crappy draft will do. Conversely if someone is asking for multiple refinements even to arrive at basic decisions, I begin to write off the problem as not critical.
• quickthrower2 3y ago
  Ahhhhhh! the MVP
  • chrisandchris 3y ago
    I'd rather name it an MMP - a minimal marketable product. It was good enough that it worked, and the buyer (in this case the stakeholder) was happy enough to "buy" it. There's IMHO a slight difference between MMP and MVP in the perspective one takes.
    • quickthrower2 3y ago
      MVP can also be minimum viable proposition which is a similar idea. An MVP of this nature can be a chat in the pub and an email order of whatever was promised!
• IanCal 3y ago
  It's also dramatically easier to have a discussion around what does or doesn't work with a concrete example. "This but with X" or "This but without Y". I've found this also helps just internally - start with a prototype and you have engineering discussions that are more practical than theoretical. > ..and this was maybe 1/3 of the effort I was planning for. Quick anecdote. When just starting out I was building a tool to automatically find the composition of essential oils used given a GC/MS output, and was told it needed to be "fast". I spent a long time optimising it, working on parallelising it and more. I spoke to them after getting it down to maybe 15 seconds or a couple of minutes something like that and was getting ready to explain why I couldn't make it fast. "So you said you need this to be fast to be worthwhile, but" "[intejects] yeah being fast is important, if it takes more than a day or two it'll be a lot harder to use" ... Well it was a useful lesson at least.