Well OK, but that's just the same thing with extra steps.

The point I'm making is that there are large cross-cutting concerns that shouldn't be sliced up by feature, but rather that the features should arise out of the composition of the cross-cutting concerns.

A single user story commonly requires the holy trinity of UI, 'business logic' and data storage, and my contention is that it's more efficient and robust to build those three layers out holistically rather than try to assemble them from the fragments required for all the user stories.

That's interesting, thanks; as you point out, an important aspect of software- as with building architecture is that it tends to evolve over time, and that's where the waterfall approach falls down. However, in software at least, it's not actually necessary to exchange one extreme for another - waterfall or agile; one can take benefits from both approaches, blending foresight and forward planning with modular construction.

> There are many advantages to building a house one room at a time.... It's more "agile"... The downsides are that the services and structure are a hodgepodge of eras and necessity... it may be infeasible to undertake a whole-house project like running ethernet to every room.

The thing is that that end result is actually the opposite of agile, being as it is more difficult to change, and this speaks more broadly to a perennial problem in software development - requirements change regularly, even deep into project development. Planning a design up front does not mean just fixing a specific set of requirements in stone, but also anticipating the things that may change, even without knowing the specifics of what those changes will be, and designing in a flexible way that can accomodate a broad spectrum of possible futures. A car manufacturer might conceivably branch into making other types of vehicles, plant equipment, and similar things like that, whereas they are unlikely to ever get into catering (and if they did, that would likely be a seperate business and a new piece of software). Responding only to the requirements in front of you right now tends to make the design more rigid rather than less, and almost inevitably leads to big balls of mud and big-bang rewrite projects that fail as often as they succeed. Keep in mind also that most software spends most of its life in maintenance mode, so optimising for the delivery stage is short-sighted at best.

Designing software in the way I'm describing is not easy, but it's definitely possible, and in my opinion offers a lot more value than it might first appear.

> You are absolutely building the kitchen, the living room, the bathroom as you put in the foundation, framing, the plumbing, the electrical work, etc

OK, the kitchen and the bathroom are special cases due to the plumbing and so on, so my analogy breaks down a bit there, but the rest of the rooms? They don't crystalise their function until the occupants move in. Maybe I as a builder might assume a certain room will be the living room, and designate another as the master bedroom, but until the owner puts in funiture, they're more or less just empty boxes with power and windows. Most of the 'features' or user stories of the house arise at the end out of the combination of built elements and final decoration. Software is actually a lot like this - take a trivial example user story of creating an invoice. What do you need for that? UI, data storage, comms maybe, some domain logic. Each of those things can (and in my opinion should) be expressed independently, but if you're developing that user story as a single deliverable, then you need to create bits of all of them. And that's what I'm saying - we're building things that naturally decompose into 'horizontal' layers (units of infrastructure), but doing it in 'vertical' slices (user stories), which, to torture my analogy even further, results in uneven flooring, mismatched walls, and untidy structures that get more and more difficult to change over time as requirements change and more builders try to add other slices of building that were not anticipated.

If you want to sleep in the lounge from now on instead of the bedroom, and entertain your guests in the back bedroom, you can just move the furniture. That's a lot more agile in my opinion than the software we commonly build.

Even there, "open up this wall" is not a unit of work. You need to:

* Evaluate what, if any, structural implications removing the wall has * Tear down the existing wall * Redo any plumbing, ductwork, wiring, etc that was hiding in the wall * Remediate structural concerns from removing the wall. * Redo the flooring * Repair and repaint any damage done to remaining drywall

If this is part of a larger renovation, you will likely schedule work so the above tasks happen at the same time as other similar tasks.

E.g. A meaningful unit of work might be "electrical roughing", which would include both moving wires that were previously in the wall, and running a new circuit to the garage for a car charger. No user story covers those to tasks, but the nature of renovating a house means that it makes sense to do them together.

OK, it's just an analogy, to make a broad point about the approach to design and construction. But you absolutely can design software in that way - I do it, and it works very well. It's not easy, but as I said in another comment, it delivers robust solutions that are nonetheless adaptable to change and easy to maintain. By contrast the 'agile' projects I've worked on were either a tangled mess, or else failed spectacularly.

> This isn't how writing code works

Maybe that's not how you write code, but there are many different ways to paint that particular fence, no? I've been coding for a long time and for me, this is the approach that I've landed on that's the best I've found so far. To me, the idea of feature-led development is, to put it mildly, nonsensical.

I don't see the difference. Could you explain how the physical attributes change the analogies?

Yeah the point is about design philosophy. The physicality or not is irrelevant.

That post seems to say that the unit of work must be something customer facing. It even qoutes Kent Beck talking about "Weekly delivery of customer-appreciated value".

There is so much great software in the world that wasn't delivered like that and couldn't be delivered like that: Unix, Microsoft Word, Postgres, AutoCAD, The JVM, Google search, Windows, AWS, Robotics, Calculators ....

The software industry seems to have been captured by contractors who used to deliver CRUD apps and now want to make the whole world in their image and likeness.

That's the point though, thinking of delivery in terms of slices of business value naturally leads one to break application development along those lines. It's very convenient for the stakeholders to see progress mapped out like that, but it tends to lead to fragile and poorly-architected systems that are difficult to change in the future (and therefore not lower-case A agile).

> It has resisted standardizing like lawyers, doctors or even real estate agents.

You can't standardize a field that changes so fast, it takes decades to standardize a field and there has never been a point in time of software where two decades didn't completely changes the job.

This is the absolute truth.

And the worse news is: it will never change. There are several things fundamental to SWE, at least the corporate, open source, and/or indie flavors, that ensure it will not be standardized.

> "SE is a low class low power field"

This is the difference with FAANGs. Software engineering is king. The inmates are running the asylum.

Google is at least 4x as efficient as other large companies I've worked for. Nearly every internal process that can possibly be automated is.