
He was fired after writing this article - alexgotoi
https://hackernoon.com/the-myth-of-software-time-estimations-576a7466d91a
======
djklanac
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.

~~~
hdhzy
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).

[0]: [https://www.joelonsoftware.com/2007/10/26/evidence-based-
sch...](https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/)

~~~
djklanac
This is awesome. Thanks for sharing this.

------
detaro
previously:
[https://news.ycombinator.com/item?id=14209141](https://news.ycombinator.com/item?id=14209141)
(authors gofundme campaign)

------
gloverkcn
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.

