Live data from Hacker News

Iterative development: the secret to great product launches

mindk.com

21–30 of 77 posts

Re: Iterative development: the secret to great product launches

#21

I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. On small teams this might be marginally possible but still difficult - on largers ones (> 5 people) leads to madness and failed projects. My other pet annoyance is management still seems to think that adding more resource to a project makes it faster. Especially "cheaper" resour…

> I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built.

Backlog items in most processes called agile are specs, and most variations include an activity of assuring that they meet whatever quality standards are in place prior to being eligible for development.

It's more common for places claiming to be agile to not have any integrated spec for what has been built than to not have specs of each to-be-built unit, AFAICT.

Re: Iterative development: the secret to great product launches

#22
post #18

Earlier quoted context omitted.

> I think one of the biggest problems with Agile is that everybody thinks it's okay to operate without a specification of what is to be built. On small teams this might be marginally possible but still difficult - on largers ones (> 5 people) leads to madness and failed projects. I'd say that the biggest failures I've seen have been due to having a specification, and the bigger the project the more important it is no…

> You can, and should, have specifications for the next ~two weeks of changes that you want to do. We completely agree here - are you saying you've never encountered the "we're agile, no need for specs" mindset?

I've encountered it and not found it to be a problem - if you have good access to someone who can answer questions during development then that's better than a spec. Even without that, as long as you're keeping your iterations short and demoing at the end of them then the worst case is you get things wrong for two weeks and then correct them after.

I've found the "we're "agile" but going to have a huge up-front spec" mindset far far more damaging.

Re: Iterative development: the secret to great product launches

#24
post #7

> Iterative development: the secret to great product launches I'd argue that often far from being helpful. Some of the best tech bosses I worked under would've shove a person out of the window simply for uttering a word "iteration." One told about that approach as - "trying to construct an airplane by making changes utill it stops crashing on takeoff" It a good to have a distinction in between software being iterated…

Isn't it how first airplanes were built? First let's build something that flies. Now let's build something that can fly for more than a minute. Now let's build something that flies for more than a minute and can also be steered. It's pretty much the same nowadays: engineers keep building new generations of airplanes which are heavily tested snapshots of current "trunk" branch.

    > It's pretty much the same nowadays:
    > engineers keep building new generations
    > of airplanes which are heavily tested
    > snapshots of current "trunk" branch.

It really depends on which industry you're talking about. I remember somewhere reading about "emergent" and "convergent" industries.

Many mature industries like commercial aircraft manufacturing are "convergent" meaning that their goal is providing the customer what they're expecting. Success is measured by "meeting the spec", beating the competition using some combination of price, reliability, time-to-market, and leveraging established status and reputation in the market. I think your SW development analogy of version control branches applies to convergent industries.

There are other industries which are "emergent." These types of industries attempt to create markets with entirely new and unexpected products. They don't face competition, instead their success hinges on developing the market for the product.

The rules are entirely different for each of these two categories.

Re: Iterative development: the secret to great product launches

#25

It should be stated that iterative development does come with a cost in that it takes longer to execute than the ideal case sequential development. You trade risk reduction for more work.

“slow is smooth and smooth is fast”

Re: Iterative development: the secret to great product launches

#26
The longer I work in this industry, the more I am coming to believe that waterfall is nothing more than a strawman set up to make development process X look like the Holy Grail.

Has anyone seen it in real life - in the pure form?

I once worked at a place that "did waterfall", but a diagram of the process would have shown arrows in all directions (would we call these things salmon runs or something?) and if you needed to go backwards only that specific piece did so while everything else continued as normal. Unit testing, integration testing, system testing, etc was all present on day 1.

Re: Iterative development: the secret to great product launches

#27
I have built many things in my short career, have worked at big and small companies.

In my view iterative development is far harder, maybe even impossible, to do at companies that don’t have the culture for it. Startups have it and most grow up with it but you’ll struggle to succeed with this approach at any big company. They may introduce Agile and bring in Agile coaches but they are just putting lipstick on the pig. That culture is set, I say this having seen it first hand.

As an example, and a little self promotion that I hope I won’t get downvoted for :) I have been working on a cross platform App that reads any article to you. It uses AI/ML models to convert the text to audio so you can listen on the go and maximize learning on that dead time on commutes.

This is a fairly complex thing to build, especially in a few months and to make it work cross platform. We now have a lot of features but this all happened feature by feature. Get one thing done, get it out, start on the next thing. If I tried this approach in a big team at a big company there is absolutely no way we would have this much done in a few months. The politics, the nonsense, etc.

If you want to check out the app you can try it here:

https://articulu.com

Re: Iterative development: the secret to great product launches

#28

It should be stated that iterative development does come with a cost in that it takes longer to execute than the ideal case sequential development. You trade risk reduction for more work.

This is the conventional wisdom, but in my n=1 experience, I have never seen the “ideal case sequential development” actually work in the wild. The ideal case presumes that everything is known when the sequential development is planned, which is what permits it to be optimized. But in my n=1 experience, everything is not known, the development team is constantly discovering new information, requirements change, and t…

I've been calling it "wagile" and it's so bad at my day job that it makes me want to cry in frustration some days. I hope they give me an exit interview.

Re: Iterative development: the secret to great product launches

#29
Is it me, or is "a series of small waterfalls" like TFA describes not actually anything to do with Agile?

I mean, I guess it's more agile than one big waterfall, but it's still not embracing the principles of Agile (like involving developers in product decisions, or letting developers assign deadlines). It's still locked in the worldview of "serious people spec the product, then the nerds push the nerdbuttons to build it".

Re: Iterative development: the secret to great product launches

#30
Agile, MVP, Iterative development: these are common knowledge by now. But I think there are problem spaces where this does not really work becasue even an MVP must be huge, otherwise users will simply ignore the product. You cannot write a small MVP of a browser, an operating system, a search engine, a game engine, a 3D modeling suite, etc... I think markets in problem spaces where you can start with a very small MVP become oversaturated, because everyone wants to start a product with a 1 month MVP development. So you will have a competitive advantage if you are able to design products in problem spaces where even the MVP is relatively big, so you can attack not-so-oversaturated markets. I think the ability to design complex products becomes an important skill.
Post reply on HN