|YaK:: WebLog #535 Topic : 2004-09-03 06.52.50 burddell : knowledge is not wisdom and love is not music||[Changes] [Calendar] [Search] [Index] [PhotoTags]|
|[Back to weblog: pretention]|
music is the best. Caught up with a lot of albums recently. We picked up the <a href="http://www.amazon.com/exec/obidos/ASIN/B0001DMUBS/matthargettbl-20?dev-t=mason-wrapper%26camp=2025%26link_code=xm2">new Sondre Lerche CD</a>. It's good, but not grabbing me as much as <a href="http://www.amazon.com/exec/obidos/ASIN/B00006IQH4/matthargettbl-20?dev-t=mason-wrapper%26camp=2025%26link_code=xm2">his first CD</a>, which completely rocked my ass (and still does). I also picked up <a href="http://www.amazon.com/exec/obidos/ASIN/B00009V7TI/matthargettbl-20?dev-t=mason-wrapper%26camp=2025%26link_code=xm2">The Polyphonic Spree</a>, which is my current obsession. It's so damn catchy, with some really nice arrangements. I loaned it to Ralph Pearson and it made him wretch. The balance between the rock instruments (guitar, bass, drums) and the orchestral instruments (strings, flutes, horns, etc) reminds me a lot of Zappa's <a href="http://www.amazon.com/exec/obidos/ASIN/B0000009SX/matthargettbl-20?dev-t=mason-wrapper%26camp=2025%26link_code=xm2">Orchestral Favorites</a> album, which is why I thought Ralph would like it. There are some other albums I picked up recently, but I'll save those for another blog entry.
I've been studying up for the next BugScan development cycle reading a lot of design, pattern, process, and requirements/use cases books. One thing I've always had trouble with is decomposing requirements into decent use cases that can be translated into a decent design. By "decent" here, I mean the use cases aren't too low level so as to be specifying the implementation, and the design is abstract enough to promote modularity, test-driven development, and reuse. I recently re-read the <a href="http://www.amazon.com/exec/obidos/ASIN/0201702258/matthargettbl-20?dev-t=mason-wrapper%26camp=2025%26link_code=xm2">Writing Effective Use Cases</a> book (which I didn't remember reading, but was already highlighted in my styling, so...) and I had an epiphany. The previous day I had re-read (which I remembered reading and had my highlighting in it) the <a href="http://www.amazon.com/exec/obidos/ASIN/0201710919/matthargettbl-20?dev-t=mason-wrapper%26camp=2025%26link_code=xm2">Planning Extreme Programming</a> book, which reminded me of some good ideas for the planning game, but I didn't get as much out of it this time around.
Well, it did help get me into the right mindset. I find I need to be in the business, coding, architecting, or writing mindset to get anything done objectively. I have to dedicate an entire day to the mindset -- switching inside of a day ruins my concentration on all the subjects generally.
Anyways, enough pretention (of that variety, anyways) -- Reminding myself about the importance of stories and CRC cards, combined with the quick tips and tables inside the Effective Requirements book made me realise how I need to go about decomposition on this new project. It's already clarified a number of fuzzy things and found some major kinks in my initial ideas. I like writing (and have been told I'm good at it), so this is a good medium for me to work in. I did this big design idea a few months ago with some input from Greg Hoglund and now I see how fucked up it was, even though it seemed to fit together really well at the time. I never would have seen it if I hadn't gone through writing the use cases. Live and learn.
Tomorrow after a conference call I plan to write up some summary use cases for several of the supporting actors, do a bit of modelling from that, then start retrofitting the prototype code (and unit tests) into the new model. I know this new framework will need to evolve as I experiment with different process models and things, and I've put a good deal of breathing room in the schedule to allow for that. Framework development sort of requires thinking ahead like this, and it seems to be in minor conflict with XP/Agile development. It's not quite big design up front (BDUF), but it's also not as fast and loose as XP stories/iterations. To help give me some perspective, I tracked down a book called <a href="http://www.amazon.com/exec/obidos/ASIN/0201731320/matthargettbl-20?dev-t=mason-wrapper%26camp=2025%26link_code=xm2">Framework Process Patterns</a>. I was going to get it at Barnes & Noble, but they don't appear to provide a way to search their physical stores' inventories. So I found <a href="http://www.borderstores.com/search/search.jsp?tt=gn">a neat site that allows one to search Borders book store inventories</a>. I found the book, went to the store and picked it up, and started reading it at a cafe in downtown Palo Alto.
Like most patterns books, it states a lot of things that seem obvious, but the stories and perspective it gives are invaluable. It gave a lot of interesting stories about developing a reusable framework, and even mentioned XP a couple of times, but didn't totally resolve my mixed feelings. We'll see how it works out, it's probably not that big of a deal and it's all in my head. Frameworks require a little bit more planning and documentation to be cohesive and usable. The code, use cases, diagrams, etc are all deliverables -- they provide value to the customer. Maybe that is what resolves this seeming contradiction -- the value provided to the customer require these things that are seemingly uncommon to most other XP projects I've read and heard about.
I'd be interested if anyone has thoughts on this, though I'm sure we'll learn about most of this through doing.
Discussion:showing all 0 messages
|(last modified 2004-09-15) [Login]|