Seb Rose gave an excellent presentation on the difficulty of providing estimates in the software industry. He debunked some myths, including the shape of Cone of Uncertainty, and recommended several books on the subject for further reading:
A few other points to take away:
- We are best at estimating small tasks, so split them into 1, 2 or 3 days tasks
- Express estimates as a range with a confidence level – 90% confident that will take between 2-3 weeks
- Communication with stakeholders is most important – assess the impact on upstream and downstream systems
I’ve downloaded the Leprechauns eBook – it’s main intention is to persuade the reader that several views that are taken for granted have not been proven in the literature – such as the Cone of Uncertainty as projects progress (the further into a project, the less error in estimates) and the 10X Programmer (some programmers are ten times more productive).
For what it’s worth, my view on the 10X Programmer issue is that, whilst it’s hard to gather the necessary evidence to compare performance across real world projects, there’s little doubt that some developers add much more value to a project than others. This is true of any human activity – queuing in a coffee shop with a handful of baristas serving while the queue barely moves, it’s usually possible to tell the one person who’s actually getting any work done. On holiday, I watched at a cycle hire place while one guy served at least three times as many families as any other.
It may not be 10X productivity in programming, but a star developer will: eliminate swathes of work by adopting a suitable 3rd party library; consistently check-in code that works (unlike his unproductive colleague who always breaks the build and leaves edge cases untested); produce intuitive user interfaces, reducing the hours of support to train new users.
I have Waltzing with Bears on order – PeopleWare by the same authors was excellent, so looking forward to this one.
Plenty of good ideas here from Jeff Atwood. I love the passion he shows for his new venture:
Have your team and yourself start using that minimum viable product, every day, all day long. This is way more than mere software development: it’s your whole life. If you aren’t living in the software you’re building, each day, every day, all day … things are inevitably going to end in tears for everyone involved.
Now, need a customer service mindset for this approach, and a band of dedicated, cross-discipline engineers prepared to roll up their sleeves and get things done. But if you have that spirit and belief, the project can succeed.
The only thing I’ve ever seen work is getting down deep and dirty in the trenches with your users, communicating with them and cultivating relationships. That’s how you suss out the rare 10% of community feedback that is amazing and transformative. That’s how you build a community that gives a damn about what you’re doing – by caring enough to truly listen to them and making changes they care about.
This paper by Dijkstra was linked from a discussion on ArsTechnica about system design. It’s amazing that many of his high-level points remain true today, despite being published in 1968 – I’ve picked out a few below:
Production speed is severely degraded if one works with half time people, who have other obligations as well. This is as least a factor of four, probably it is worse. The people themselves lose time and energy in switching over, the group as a whole loses decision speed as discussions, when needed, have often to be postponed until all people concerned are available.
The intellectual level needed for system design is in general grossly underestimated. I am more than ever convinced that this type of work is just difficult and that every effort to do it with other than the best people is doomed to either failure or moderate success at enormous expenses.
It seems the designer’s responsibility to construct his mechanism in such a way —i.e. so highly structured— that at each stage of the testing procedure the number of relevant test cases is so small that he can try them all and that what is being tested is so perspicuous that it is clear that he has not overlooked a situation.
I’d add to the list that it’s vital to spread knowledge within a team to maintain productivity and avoid one person being silo’d to a specialist skill and becoming a bottle neck. Instead, find out how to pull the source code out of the repository, how to build and test it – and start making small changes yourself as a learning exercise.
The BBC posted an article about Valve, who have a totally flat structure and leave their star developers to get on with it.
InFSharpMajor.com is working through a book of algorithmic interview questions and solving them in F#. The questions come from this book which provides solutions in C++.
I think the problems and solution algorithms are interesting in their own right. I found the F# solutions a bit opaque (and I’ve been writing F# for several years), but my colleagues from a functional (*cough* Haskell) background tell me the idioms are well recognised in the community.
Great article on how to achieve high productivity.
Productive people aren’t braver than others; they just find the strength to keep moving forward. They realize fear is paralyzing while action creates confidence and self-assurance.
I subscribe to the school of thought that, in order to finish a project, you have to keep starting – to get over the fear of imperfection, you don’t focus on completion, but focus on beginning again and again.
Think about a time you put off a task, finally got started, and then, once into it, thought, “I don’t know why I kept putting this off–it’s going really well. And it didn’t turn out to be nearly as hard as I imagined.”
Read more: http://www.inc.com/jeff-haden/7-qualities-of-uber-productive-people.html#ixzz2KoR5fDv8
Good article about an unexpected problem from hiring too many B-players in your firm. Here are the author’s definitions:
A player: Fully self-sufficient and takes initiative that positively impacts the company.
B player: Does some things well, but not fully self-sufficient, and not consistently strong.
C player: Just average, and does not excel in any area.
D player: Poor performer, and shouldn’t last long if you are a half-capable manager.
F player: Should be out…like yesterday.
Here’s the problem with B-players, the inconsistency catches you by surprise the first time, so then they need careful monitoring – something you don’t have time to do.
When you have someone on your team that you think is doing well enough, you will likely trust them with mission-critical tasks like hiring or pushing code. This will impact the entire evolution of your company. If you entrust important decisions to someone who is just “good enough,” you will watch the opportunities pass.
The author claims that a star engineer isn’t just worth 10x the average, s/he is irreplaceable by any number of lower quality people.