This is's Typepad Profile.
Join Typepad and start following's activity
Join Now!
Already a member? Sign In
Recent Activity
I wonder if its that you run #NoProjects or just that you're run by XPers? Most of the companies run by old-school XPers that I know are quite happy with estimates because they understand what they are: educated guesses about an uncertain future. We use estimation to cost external projects and I've found it relatively easy to educate customers on the uncertainty of estimates ... partly I'm sure because there is no-one else in the business they can ask to get a more 'conventional' view. One of the things that saddens me about #NoEstimates is that it eschews what I think has always been a valuable learning tool. Estimation as a process is one of thinking about and discussing the problem and its solution(s) and getting estimates 'wrong' is a chance for reflection and improvement (whether improvement of estimating or of an environment where even accurate estimates have no bearing on time to deliver). Yes its hard to get good at but that's true of many things: Kid: I want to learn the guitar and play some gigs NoEstimates Dad: Playing the guitar is hard. I tried and couldn't do it. Some of my friends tried and they sound awful. Kid: But if I practice and get good at it I can make people happy NED: But not many people are good at it, what makes you think you can be any different? And think of how disappointed people will be if they come and listen when you're not very good - they'll just shout at you (or worse). Kid: I'll just tell them I'm still learning and maybe they'll like my stuff enough to encourage me to get better NED: there are lots of other ways to entertain people with music. Why not just put a CD on and tell them live music is overrated - full of mistakes and imperfections. They don't really want to listen to live music, they just don't know that yet
Toggle Commented Apr 7, 2014 on Estimates Considered Useful at Agile Coaching
1 reply
Interesting idea that reminds me of a dilemma I was facing a little while ago in ruby to do with designing an API. I wanted to retrieve stored objects with zero or more named properties and zero or more conditions store.retrieve('Account', :name) #retrieve objects of type Account populating just the name field store.retrieve('Account', :name, limit: 1) #retrieve first object of type Account populating just the name field store.retrieve('Account', [:name, :last_contact_date], {tier: 'Gold', country: 'US'}) #retrieve US, Gold-tier objects of type Account populating name and last_contact_date fields This feels very Rubyish: a single method with three parameters. the last two of which are optional (no field names means all fields and no conditions means an unconstrained retrieval). The optional parameters may be a single thing or a list of things. Basically this doesn't work without some nasty code (if is_a? or if type_of?) to distinguish between whether an optional argument is a single value or a collection (and, in the case of a Hash its actually both). Asking around for opinions the responses I got were mixed: * Have different names for the methods to distinguish between a single field and multiple fields. Nicely intention-explicit but a complex API rather than a single method * Always pass in a collection (e.g. [:name]. Simple code but the intention is less clear (do I mean :name or a collection with :name in it?) and the onus is on the caller of the method to do extra work to make the provider of the method's life easier. * Write a little language for the query so there is always one parameter, e.g. retrieve('Account', "Name, LastContactDate where Tier = 'Gold' and Country = 'US"). Nice but the point of the API is to make retrieval a lot more declarative and writing a robust parser will require more and more complex code than writing the API as envisaged with a bit of type checking. Someone pointed out to me that the explode (*) operator always returns a collection so the if is_a? Array code can be replaced with *property_names which will always be a collection even if property_names is passed in as a single value. But it seems to me a language where a thing is also a collection of itself (I'd go for single value rather than infinite but suspect there are philosophical and practical problems with both) would make life a lot simpler. JQuery has some aspect of this. is now following The Typepad Team
Mar 18, 2013