timurlenk

We have debate in our company - who should provide the estimation for the duration of a task (usually part of a project). I have seen a few popular options:

- the developer who will implement the task (a somewhat prevailing opinion on the internet) - senior developers - project managers

Thinking about it a new option may have emerged: estimates should not really be needed; and I would like to explore this option below.

Let's agree first that estimates are mandated for various business reasons but we won't require greater precision than a day of work.

Now, doing a thought experiment we analyse if there would be any estimate difference for a task requiring one line of code or "Hello World!" and agree that no matter who would provide the estimate the answer will be the same - probably the smallest unit of estimation since the task is trivial and the solution is canonical.

Going forward, however we agree that there is a point where estimates will diverge even between the most seasoned developers and estimators. I would argue that in that point the divergence stems either from a difference in understanding of the problem or different approaches in solving the respective (complex) task. Since both scenarios could cause problems down the line in the project, the team should step back, clarify the requirements & approach to the solution and break it down into further tasks that are trivial enough to be executed in the smallest unit of estimation.

In summary, estimation is the wrong problem to solve, the team should spend the time to thoroughly understand the requirements and truly define the solution approach, leaving the time estimate to be just a matter of counting the generated tasks and multiplying that with the agreed smallest unit of work.

While the above is a hypothetical scenario, what are your thoughts around it? Where do you see its flaws and where do you see its merits? Is anyone doing such a thing or was it tried and failed?

In my corporate life, I have noticed that most of the senior/executive staff are quite protective of their CV's and profiles.

Even more, if they are members of linkedin, they usually only present their job titles with no further description of role or responsibilities. This would seem to me counter-productive as a potential recruiter would be less likely to find their profile using a generic search.

Personally I would have greater trust in a public CV because my feeling is that the respective person would be less likely to lie or embellish facts in a CV that be seen by their immediate peers.

Is your CV public or not? Why? Do you fill in your complete linkedin profile or just job titles? Why?

All of the startups I see around HN seem to be developing some kind of app that connects, syncs or organizes something. While this is all exciting, are there any stories about startups that do hardware?

I would be interested to know about startups that want to change the way the internet works by building the next generation router or a different way to store data. How did they fare? What were the challenges?