I've spent my career living in sales and engineering camps. I've managed whole sales organizations and written full applications from the ground up. I could not disagree more with the author that time estimates should be eliminated. The business does not exist without revenue, and revenue is less likely to be retained (customers) or acquired (new customers) when the business is unable to anticipate product delivery timelines. Think about all of the other business functions that key their todos and deadlines off of a product release. There is also the question of accountability. I'm intrinsically motivated to be productive, but even I value knowing if I am tracking well on a burn down chart. It gives me daily insight into whether or not I should communicate a need to trim scope or coordinate a deadline change with the other business functions if scope can't be trimmed. Kanban is awesome for bug fixes that are hard to anticipate, but any dev worth their salt should be able to offer a time estimate. If something happens, then communicate why the estimate has to change and keep incorporating the lessons learned from into future estimates.
I think developers are kind of afraid to estimate, especially when these estimates are treated as commitments and not... well, estimates.
Evidence based scheduling [0] is an interesting approach to scheduling that may ease some of these pains but is not without drawbacks (e.g. estimation itself can take a lot of time).
I am "worth my salt". I think so. But when I was asked for estimates, I told them a number, but only after I told them that that number is without foundation. It is an estimate, a guess. At many clients / projects, it was taken as a guaranteed time, a deadline - despite my effort to explain that it is just a guess. And when things got bad, it was often used for blame.
Because of this experience, since 2-3 years, I am fighting estimates unless I am in an environment where estimates are really only estimates.
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.
YAGNI/KISS are the two hardest concepts for developers to internalize. Ignoring them creates the brutally painful legacy systems we have to maintain today.
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.
Shifting to Timelines.
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.
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.
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.
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.
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:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
If you are building a platform/framework instead of delivering features then the dev team is prioritizng the plan over responding to change.
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.
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).
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.
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.
