5 ms·
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 t
by 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 agoTo go fast, stay humble and use boring technology.
- j45 3y ago.. in a simple and flexible way.
- andai 3y agoI agree completely. That sounds much better than my current strategy of delivering incomplete and broken products at unpredictable intervals.
- EliRivers 3y agoMy 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 agoI 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 agoThis 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 agoThanks. Hot coffee just came out of my nose.
- renewiltord 3y agoAs I always tell my team: fast, cheap, good; pick three.
- Eddy_Viscosity2 3y agoIn my work they say: fast, cheap, good -- you can't have any of these.
- bell-cot 3y agoOncology?
- dmoy 3y agoOr defense contracting?
- expertentipp 3y agohealthcare?
- tome 3y agoMore to the point, it's much better than delivering incomplete yet working products quickly and regularly, complete yet broken products quickly and regularly, complete and working products slowly and regularly or complete and working products quickly and irregularly.
- marcosdumay 3y agoWell, that's my main strategy for my personal projects.
- greesil 3y agoBut why can't you just do it faster?
- Gordonjcp 3y agoAh, you sound like the vendor we've just fired. I wish I was joking.
- IggleSniggle 3y agoI’ve been going with “set expectations high and then pivot to new high expectations.” It compliments your strategy pretty well.
- 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 agoWith 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 agoThere is high overlap between customers who leave because their needs aren't met immediately and customers whos needs will never be met.
- natmaka 3y agoI agree, and would add "(nearly)-no software regression" (no "a feature that has worked before stops working"), and never twice the same one.