I’ve been in roles where enormous amounts of time were spent on writing specs, and in roles where specs where non-existent. Like most things, I’ve become convinced that success lies in moderation between the two extremes.
I think it would make sense for big specs, but I want to be careful we use it judiciously so that we don’t simply apply more process for the sake of more process. It is tempting to spend too much time recording every little detail in a spec, when that time could be better spent in regular communication between team members and with customers, and on iterating the code (short iterations between demo/testing, so you ensure you are on staying on track and can address design problems early, often). IMO, specs are best used more as summaries, containing useful big-picture ideas, diagrams, and specific “memory pegs” to help us remember what was discussed and decided, and calling out specific “promises” for future conversations where certain design points are TBD. From: Malini Kamalambal <[email protected]<mailto:[email protected]>> Reply-To: OpenStack Dev <[email protected]<mailto:[email protected]>> Date: Monday, June 2, 2014 at 9:51 AM To: OpenStack Dev <[email protected]<mailto:[email protected]>> Subject: [openstack-dev] [Marconi] Adopt Spec Hello all, We are seeing more & more design questions in #openstack-marconi. It will be a good idea to formalize our design process a bit more & start using spec. We are kind of late to the party –so we already have a lot of precedent ahead of us. Thoughts? Malini
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
