Jonathan Lange wrote: > Hello, > > I've been thinking a bit about how we can achieve three[1] things: > * avoid reworking features > * avoid working on silly features > * make our features so good that we have annoying fanboys queueing > outside our retail outlets on release day
In my experience, great products with annoying fanboys are the end result of 1000s of great decisions: every label, every widget, every workflow, every error message, etc. The primary challenge in a large software development team is how to distribute (wise) decision making. Ultimately, it's ideal if every software engineer "gets" the vision and makes smart choices accordingly. Failing that, team leaders need to be capable of getting it right. I've been reading Mary & Tom's latest book on Lean SD this week. They put a huge emphasis on managing flow: finding what's slowing you down from delivering value faster. They also caution against introducing new processes that solve "occasional" problems: it can be better to wear the cost of rework (say) now and then than to slow down every change. Sometimes the fastest way to improve quality is to simply fix lots of bugs. The primary argument against doing that is opportunity cost: could the time be better spent on delivering new features instead? That's never an easy call. I think your templates are great for new features. If fixing small bugs takes too long though, then that process needs to be improved IMO. I'd be hesitant to impose additional overhead on small changes. > """ > I really, really believe that big design up front is a wasteful > practice that produces crappy software and unhappy developers. I would > only be happy with these things becoming a part of our process if they > were iterative and if the documents do not become ends in themselves. > """ > > With that in mind, I want to know your thoughts on the whole thing. The essential thing is to not make yourself a bottleneck. That's *very* easy to do in a role like Product Strategist or Architect. Also, one "trick" that's appropriate now and then is to write documents that have ongoing value (e.g. end user documentation) instead of documents that become obsolete. HTH, Ian C. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
