Here's a anecdote of how a typical webapp goes to shit with the best intentions from everyone. "building it right from the start" sounds great. I've never work

Here's a anecdote of how a typical webapp goes to shit with the best intentions from everyone. "building it right from the start" sounds great. I've never worked on a project where people did not honestly try to do it this way. Lets say that for once you have a clear set of unambiguous requirements (a rarity) when starting in. I like to start with the database first. I'll design a nice normalized database and start building the website from there. If the requirements are fleshed out enough you'll already have a map of what pages ought to do what. Once you get to the point where you can have a customer try out a few pages you get some "feedback" which is actually a change in the requirements. You can't hit them with a change request for every little thing at first so you comply. Maybe it's just a small change turning a one to many into a many to many relation for example, or moving a few fields from one table to another. Soon you have 30 or so similar "small tweaks" even if you hit them with a change request every time, they don't all come in at once giving you a good opportunity to re-evaluate the schema/application as a whole, it's always viewed as a singular "small" change so re-factoring the whole thing isn't really an option. The more changes that come through the more your elegant implementation becomes a series of hacks. Soon they may start complaining asking why their "small" changes are taking so long to fix. This adds further budget pressure. The problem is, it's not very clear to people down in the weeds when implementing the small changes if it's a hack or not. I think this is something that takes experience. So even when you have cleanup be a blocking requirement, taken one at a time it might seem fine and no large refactor is obvious until it becomes too large of a task to lump in a typical change request. This is an especially easy trap to fall into for people who have been toiling away at the current design. They will have a blind spot/affinity for keeping as much of their implementation as possible and resist an overhaul. If you have an iron will and a steely ice cold 1000 yard stare from 10 years of war in enterprise app development it's easier for us to kill code because we don't get attached to it as easily. Be careful not to fall into the dark side though, (the flip side of those 10 years can instil a cold iron heart who stares right through the hacks and stops trying to argue with the client about doing things properly. In this scenario you just do as you are told and stop caring about the overall state of well-being of the codebase.) The real art to web dev consulting is being able to build a flexible enough design to withstand these sorts of changes and still remain elegant and well thought out. It also takes the experience to know the difference between a hack and a proper change and the will power to do the right thing. It's really hard to do and it a good "gut" feeling for how a particular thing will actually be used, what a customer really means when they say something etc. I'm not sure that it's something that can be taught. It leads right back to your brain dump wish. Cheers