> 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 thoug

> 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. This is where it gets tough. I happen to have http://www.colorforth.com/POL.htm http://www.colorforth.com/POL.htm [1] open, a portion of which illustrates the other side of this fence (emphasis mine): > Do not put code in your program that * might * be used. Do not leave hooks on which you can hang extensions. The things you might want to do are infinite; that means that each one has 0 probability of realization. If you need an extension later, you can code it later - and probably do a better job than if you did it now. And if someone else adds the extension, will they notice the hooks you left? Will you document that aspect of your program? Obviously all of this must be taken in moderation, of course. But it hints at the problem I'm trying to describe: the design needs to be flexible, but scoped to the problem space you're working within. Bamboo is flexible, and usefully so; try and generalize that flexibility to the fullest extent and you'll end up with goo which will expand to fill the problem space entirely and then subsequently accomplish nothing. So, it's about figuring out where flexibility will be most critical (eg, for a part of the architecture that will necessarily be "locked in" with a lot of other components or mental models depending on it) and where you should be able to get away with rigidity, either because it'll be easy to redesign (few dependencies / easy to conceptualize and subsequently retool) or because even Revision #31781 won't need you to change that bit. ...I think I just found myself at the brain-dump problem too. Haha I'm also curious... I've known about the "kill code" thing for a while. I haven't really gotten into coding especially seriously as yet (lots of analysis, but nil implementation), and it's hard to contemplate the idea of doing this, even for situations where I know I definitely need to, like iterating on properly implementing something I've never explored before. How does one acquire the "iron will" mindset you talked about? (I ask this as I've recently discovered my lack of get-up-and-go is due to a wonky/underpowered thyroid (giving me chronically low motivation); now that I know what's wrong I'm working on fixing it, but I suspect the anxiety that's developed over time will not go away without some mental effort as well. You could say I'm a bit of a worst-case scenario when it comes to juggling multi-domain mental task sequences generally speaking.) [1]: Search http://www.colorforth.com/blog.htm http://www.colorforth.com/blog.htm for "Problem-Oriented" to find the hyperlink to the mentioned URL. There are many interesting links to other places on this page, which I don't think are mentioned anywhere else on the site. (Translation: there's no sitemap, category system, or menu; you have to dig.)