I'll talk about some counter points to the article. I don't mean to rustle feathers, but there are a couple of points I take issue with.<p>YAGNI/KISS are the two hardest concepts for developers to internalize. Ignoring them creates the brutally painful legacy systems we have to maintain today.<p>Requirements and feature priorities change all the time. I think building an over engineered foundation is always a terrible idea. Complex things are not necessarily better. You shouldn't be building frameworks or platforms. You should be building products. A framework or platform may fall out of your efforts, but it shouldn't be the goal. If you build a framework for the future, then you are wasting effort on a future that probably won't come. When the priorities change then every extra line of code becomes technical debt that the team has to work against. Now you have to have sprints to fix it. And you'll blame business for changing their minds and wasting your effort. That's not agile.<p>Shifting to Timelines.<p>Timelines are important because development, especially in larger organizations, does not work in a vacuum. Marketing, training, sales, customer support, implementations, existing customers, are all impacted by development releases. This impacts accounting's ability to plan for expenses or revenue. Things like, do we go to show X and plan for a big release blitz or not. Do we hire and prepare for a big lead generation campaign this quarter or the next. We have Y amount of revenue if we can get the release out. Is that revenue coming in now, or at the end of the year. We in technology are usually oblivious to these issues, but we shouldn't be. If we are asking everyone to understand our constraints, then we should understand theirs.<p>If development takes the stance "You'll get it when it's done", then it's really hard for everyone else to do their jobs.<p>The core of the friction is resource constraints. You can't add bodies and get more productivity quickly, so for a given release you are usually stuck with the existing team +/- a small percentage.<p>The only dials left are time and feature set. Good orgs will as a group adjust both. Bad orgs will set both in stone and throw rocks.<p>This is why good agile is so important. The original concept of agile, not the "process in a box". I'll copy the tenets here:<p>Individuals and interactions over processes and tools<p>Working software over comprehensive documentation<p>Customer collaboration over contract negotiation<p>Responding to change over following a plan<p>If you are building a platform/framework instead of delivering features then the dev team is prioritizng the plan over responding to change.<p>A good group will establish the MVF (minimum viable feature set). They will do so based on the needs of the company; sales opportunities, product vision (by an industry expert), operational needs (customer support tools, et al.), and technical debt management.<p>The MVF/MVP is not the place for business to include every bell and whistle, and not the place for development to build a MOAA (mother of all archtectures).<p>The most critical items are delivered first and readied for release. Then other features can fill in and enhance the big release date. If development is able to churn out features then marketing can pick the point where they want a formal "release" with fan fare.<p>All that said. It sucks his contract was cut. There might have been other issues and this was the last straw, or the company might feel he was airing dirty laundry, or it he was cut for something completely unrelated.