Enterprises complain about their inability to innovate at a pace that even approaches that of startups, and yet puts into place every system imaginable to prevent a team of Lions from forming and executing.
Anyone who lacks the knowledge of how to build quality software, as well as the wisdom to know when code is good enough to ship, does not have the experiential background to have a valuable opinion on the code quality vs. getting things done debate.
Recently I’ve been talking to companies that want me to improve staff productivity. The opening conversation tends to be about the same: they pitch me on their company and what a “great place to work” it is. They brag about how smart the people are, how much fun everyone has, and how it’s more like a family that a bunch of co-workers. They describe all the perks like massages, video games, beer-on-tap, coffee bars, and how much everyone loves them. “Sounds like you have it all together,” I say after hearing all of this. “Well,” they reply, “I just wish we could get a bit more out of them.”
The following is my response to Ewan Valentine’s blog post “How to never complete anything” that I discovered on Hacker News. Once again, I ask for people’s indulgence for posting a reply on my own blog rather than in the Hacker News comments. I find writing on my own blog a bit easier than wading into the surf that is the sea of many perspectives.
In my previous “An Attempt at a Pragmatic Framework for Defining a ‘Senior Engineer’”, in the “A Process to Estimate Work” section I said:
“It is beyond the scope of this post to describe everything that goes into making a good estimate, but suffice to say a senior engineer views estimates as a difficult challenge to be surmounted, and as a result will normally ask for dedicated time simply to come up with the estimates.”
A commenter asked that I write an article on estimation, and this is my feeble attempt to do so.