Live data from Hacker News

YOLO-Driven Development Manifesto

andersoncardoso.github.io

11–20 of 75 posts

Re: YOLO-Driven Development Manifesto

#11
post #7

>No Documentation, No Problem >Who needs documentation when you have the power of intuition? YOLO-Driven Development encourages you to keep your genius solutions locked away in your head. After all, real developers don’t read documentation; they conjure it from thin air. Apparently this style of development has already become very popular as almost none of the projects that I look at have any documentation at all.

Some problem domains are inherently complex and the code written for them needs documentation. Some are not but get complicated during the design process and perverted into abominations that wouldn't have required documentation if the design and source were more readable.

I'm inclined to say that if you name things obviously and avoid cutesy idioms (AOP/reflection magic, ridiculous object hierarchies, etc) that code can be quite grokkable with little documentation. Of course this falls apart once you start dealing with hundreds of microservices or decades of tech debt but such is life.

Re: YOLO-Driven Development Manifesto

#13

Earlier quoted context omitted.

It's funny that its satirical, but I could make an argument why every point is actually a good thing.

Really? In which context?

The “move fast and break things” context. Ship it now, make butt load of money by over promising and under delivering. No need for testing or docs. Adding half baked features, you only live once.

Re: YOLO-Driven Development Manifesto

#15

I agree with most of these in general, but when combined to a Manifesto, I can't help but feel like this is somewhat satrical

You can tell this is satire by the fact that it is a manifesto, it is a literary form only used by the other side, we yolo'er don't have time for those. There is a lot of nuance to breaking rules but most people can't think for themselves so they just shouldn't do that. Sort of like the saying the psychotic drawn in the water in which in mystic swim.

Re: YOLO-Driven Development Manifesto

#16

Earlier quoted context omitted.

It's funny that its satirical, but I could make an argument why every point is actually a good thing.

Really? In which context?

Probably not what the parent poster was talking about, but fear is a great inhibitor. Excessively high standards for documentation and depth of scope might inhibit less experienced engineers, and nitpicking about scope is a pointless waste of time that ends up being a managerial excuse for more meetings especially if it's brought up endlessly when the core feature does not yet work. This promotes a culture of fear which can paralyze a team of engineers and all you end up getting out of them is the bare minimum.

Or something like that.

Re: YOLO-Driven Development Manifesto

#19
post #7

>No Documentation, No Problem >Who needs documentation when you have the power of intuition? YOLO-Driven Development encourages you to keep your genius solutions locked away in your head. After all, real developers don’t read documentation; they conjure it from thin air. Apparently this style of development has already become very popular as almost none of the projects that I look at have any documentation at all.

sure they do, you have the sourcecode don't you?

If you have an ugly tangled forest of microservices to investigate, even having the code won't save you

Re: YOLO-Driven Development Manifesto

#20
post #7

>No Documentation, No Problem >Who needs documentation when you have the power of intuition? YOLO-Driven Development encourages you to keep your genius solutions locked away in your head. After all, real developers don’t read documentation; they conjure it from thin air. Apparently this style of development has already become very popular as almost none of the projects that I look at have any documentation at all.

Some problem domains are inherently complex and the code written for them needs documentation. Some are not but get complicated during the design process and perverted into abominations that wouldn't have required documentation if the design and source were more readable. I'm inclined to say that if you name things obviously and avoid cutesy idioms (AOP/reflection magic, ridiculous object hierarchies, etc) that code…

That’s the theory. In real life, code is written by teams with different levels of skills over multiple periods of time. Expressiveness is a really hard skill that take years to master and that few people have and that you can only learn by yourself.
Post reply on HN