If you've never built a complex thing out of wood, I highly recommend it. There's an interesting curve of experience. First you try to build basic things, and it seems kinda easy, everything just works. Then you start trying more advanced things, and it seems like everything gets screwed up constantly. Finally you master the advanced things, and you screw up less and it gets easier.

The same is true of software. At first you try to make software, and you do, and it's kinda easy. Then you try to make more advanced software, and it seems much harder than it should be, as what you think will work doesn't. You spend a lot of time changing your design to make things work, which ends up not being exactly as you thought it should at first. Finally, after you master software development, things get easier and work like you expect.

In both cases, when you are ignorant, you do the wrong thing, and it works despite your ignorance, because you're doing an easy thing in the most straightforward way. But then you get cocky and try things that aren't as easy, and suddenly the straightforward way doesn't work anymore, because complex things never work the way you expect. Finally, after you've screwed up doing the thing enough, you remember what not to do, and now you can do it without the mistakes. But you're just not-screwing-up the things you already screwed up once before. You'll still screw up new things, because you haven't learned them yet. And you'll screw up again when you forget a past screw-up.

What separates the woodworker from the software engineer is, the woodworker doesn't make a lot of different things, and doesn't use a lot of different ways to do it. The software engineer is constantly doing new things, in different ways. So the software engineer is perpetually rising to their level of ignorance, while the woodworker stays mostly within their level of competence.

This is why there is no system in the universe that will be better than any other at software development. Agile, Waterfall, or anything else, doesn't matter. As long as you keep doing new things, you'll never not be screwing up. But stick to one thing and master it, and it doesn't matter how you do it.

▲

zelphirkalt 2 days ago | parent [-]

And that's why agile is not a set in stone process, that imposes tools and process upon the devs, but states: "Individuals and interactions over processes and tools". Basically, it tells you, that you will need to figure out what works for this project and this set of people.

▲

0xbadcafebee 2 days ago | parent [-]

Which means Agile will always be more expensive, time-consuming and difficult than alternatives.

Say you're building a boat. Boats require not only lots of skills in woodworking, but a whole 'nother skill of design, to get a boat that does what you want on the water. It is always time-consuming, expensive, and hard.

And there's two basic ways to build it: with plans, and without plans. Without plans, you have to design it yourself, then try to build it, then make mistakes, maybe even to the point you have to start from scratch. Time-consuming, expensive, hard. But start with plans that have already been built, and you benefit from somebody else's time, money, expertise and toil. The boat is built faster with less effort and fewer mistakes. And instead of needing master craftsmen, you only need journeymen who can follow orders.

	▲	zelphirkalt a day ago \| parent [-]
		No, that's not at all what it means. It means, that you need capable engineers, who are willing to talk to users and build understanding, rather than just being Jira task rabbits. It means, that you might not even need all the intermediaries, each having their own personal agenda and incentives, that engineers usually have to put up with. It also means, that certain layers in an organization have to trust their employees a little more. It means, that what you build it based on user feedback, rather than what someone tells the engineers, what the user feedback supposedly is, without having a clear idea, what the users actually want. I have seen this first hand. When in the beginning of the product I as an engineer interacted with the users and found out their issues with the platform I was developing, later on the organization added hierarchy layers, shielding or preventing engineers from talking to the users, to build their own job moat, and patronization going on in terms of "Your time is better spent developing the actual features.". In the end the product ended up drifting far from what is good for the actual users, and instead people talked more to B2B customers, than the employees at those other businesses and what they actually need or want. With each additional layer between the user and the developer (which is also people who want to be paid btw.), the business is inflicting significant cost and increases the risk to steer off course.