Hacker News Reader

Comment by illuminati1911 | Hacker News Reader

illuminati1911

Problem is not the agile, but useless sinecure managers trying to rebrand "agile" as something in which projects don't need planning, can be completely chaotic and any requirements can be changed at anytime without affecting the deadline.

"Hey we don't really need to make any decision ever or even know what we are doing. That's the great thing about agile!"

View on HN

> without affecting the deadline

This might be a controversial take but if you have an actual deadline -- "product must cross the threshold of not shippable to shippable" as opposed to a cutoff date "product is at all times shippable but we need a date to say we're done refining" then agile is probably not the way to go.

I've always structured projects like this as waterfall to your MVP then switch to agile. You have to get your PMs to agree to an (externally) unchanging design and feature set until you have something working to talk about and then you can ask what they want next.

Even without a deadline I still try to follow this model but define the "MVP" as a "hello world" app but with functioning prod-ready infrastructure and ci/cd. So then I can go to the design meeting and say, "I have a blank canvas, what do you want on it?"

Yes that's fine if the company can determine what they want before setting dates, or asking for "estimates" (date commitments). Though the OP was talking about worse case of: date set, product/ux/etc continues (or starts) planning, eating well into deadline.

Projects tend to need substantially less planning than people think.

The joke at my previous job was "Months of development can save days of planning."

The management in the company didn't plan anything and the meandering development process showed it.

Please don't underplan. It's awful for morale to throw away work because of bad planning.

Being willing to throw away work is the single most effective way I've seen at running an engineering org, both in terms of promoting innovation and in being able to quickly adapt to evolving customer needs as they get revealed.

If your morale is harmed by throwing away work, that's something you should work on.

It depends on why you throw the work away. If it's because of issues that should have been apparent with minimal planning, it's disheartening. Obviously, throwing away work is important in general. But consider a project to do taxes that gets thrown away because legal says it's a law taxes be done by hand, that an accountant said used the wrong tax code or that marketing comes back and says it has to be a desktop app.

If that doesn't kill your morale, I don't know what to say.

Meanwhile, by all means discover that no one likes typing numbers on a phone so you have to refocus on taking pictures of receipts and wage stubs and text recognizing them.

Creating the 'typing numbers on a phone' version of the app is relatively trivial, so probably worth doing first. You only want to do the AI version if you're really sure that you need it, or you can afford it and it doesn't delay more important things.

I think you are focusing too much on the example, which was chosen to try to explain my point. Obviously it has to be a simple problem with simple issues to be easily discussed in a public forum.

If you worked on a project for any amount of time that wasn’t put in front of users (who would catch obvious mistakes like what you describe), you aren’t taking your job seriously and have bigger problems than feeling bad about throwing away code.

The point here is that programmers are assigned tasks, do them, and the management (whose job is to put it in front of users) is failing at that leading to wasted efforts.

Although I should point out that 2/3 of the examples would not have been caught by a user, because they are compliance related.

If your team is organized in a way where programmers are assigned tasks to execute, you are not operating on a modern software team, and that is your problem first and foremost.

This is something I've come across in my own experience. If you don't actually have any experience in the problem space, the best thing you can do is make something that just barely works, then scrap it.

Then all the unknown unknowns become known unknowns and you can actually create good solutions to it.

All planning is a waste if you don't even know where the speed humps will lie.

It's basically a variation of Chesterton's fence[1]. There's a lot of hubris in thinking one could write a piece of code better than someone else if one has never attempted to write that piece of code, especially when never even having done anything like it at all.

[1] https://en.wikipedia.org/wiki/Chesterton%27s_fence#Chesterto...

Yeah, like to do the job properly you need someone who's done the same job before. Become that someone by exploratorily building the thing you want to build before you seriously build it.

>All planning is a waste if you don't even know where the speed humps will lie.

If that's the place where someone is, they should be conferring with someone else who knows something instead of trying to fly solo

Blindly going through problem spaces is how you waste your life taking wrong approaches

At google it was repeated that Sergey Brin used to say "all work is throwaway work, it's only the time horizon which is in question".

It's kind trite to say “much is explained”, but… that explains so much about google.

It doesn't really. There is plenty of old code at google, he was just saying it to people who were too scared of doing work they might need to throw away.

The promotion process explains way more of what I think you are getting at.

Throwing away code and throwing away products/features are completely different things, and only one of those is a real problem for end users.

It depends at which level you're at. If you're working at an infrastructure or firmware level, throwaway work can be expensive and time consuming. Re-architecture can also be time consuming. There are some parts you have to spend design cycles on, especially if you're doing a large project. It's not that you can't pivot, but the pivot takes a lot of time. At the very least have a set of System Features and System Guarantees that you will drive towards.

With embedded development it's entirely fine to iterate fast and throw away work, until the product is shipped. And in certain applications it is fine even after it is shipped.

True, but usually in this kind of situations it's either zero planning or way too much planning and often the planning is also "wrong kind of" planning.

“Shit, the Oracle costs 10x more than the bullshit number we budgeted. Next sprint, refactor to SQLite.”

I think the dream is "get precise estimate without defined requirements". Also "an estimate is a commitment"

If what you're doing is a "project," then by definition it can't be agile. Agile is for products.

Exactly ... I call that the frAgile methodology and managers seem to love that.

Reply on news.ycombinator.com