Blog Views
Categories
Reviews by Content
Archives
- February 2012 (1)
- January 2012 (1)
- December 2011 (3)
- November 2011 (3)
- October 2011 (3)
- September 2011 (5)
- August 2011 (26)
- July 2011 (6)
- June 2011 (8)
- May 2011 (6)
- April 2011 (9)
- March 2011 (6)
- February 2011 (7)
- January 2011 (6)
- December 2010 (5)
- November 2010 (22)
- October 2010 (5)
- September 2010 (4)
- August 2010 (4)
- July 2010 (5)
- June 2010 (4)
- May 2010 (3)
- April 2010 (1)
- March 2010 (1)
- February 2010 (2)
- January 2010 (4)
- December 2009 (1)
- June 2009 (1)
- May 2009 (1)
- April 2009 (2)
- March 2009 (1)
- November 2008 (2)
- July 2008 (2)
- June 2008 (1)
- April 2008 (1)
- January 2008 (1)
- July 2007 (2)
- June 2007 (1)
- April 2007 (4)
- March 2007 (1)
- October 2006 (2)
- June 2006 (1)
- May 2006 (2)
- March 2006 (1)
- January 2006 (3)
- August 2005 (5)
- July 2005 (5)
- June 2005 (5)
- May 2005 (6)
- March 2005 (9)
- February 2005 (5)
- September 2004 (2)
- June 2004 (1)
- May 2004 (2)
- April 2004 (1)
- March 2004 (2)
- December 2003 (1)
- September 2003 (1)
- August 2003 (2)
- July 2003 (4)
- June 2003 (1)
- April 2003 (2)
- March 2003 (2)
- July 2002 (1)
- June 2002 (2)
- April 2002 (9)
- January 2002 (1)
- September 2001 (1)
Monthly Archives: June 2005
Cirrus Minor – A New Architecture Site
Arnon Rotem-Gal-Oz has set up an interesting new site / blog dedicated to software architecture. Of particular note, he’s trying to put some detail on the architecture “process” which is often negelcted as a single box on the development process picture. His approach has the name SPAMMED, catchy, but might cause the odd problem with email filters
Domain-Specific Languages
There seems to be quite a lot of activity on the “Domain Specific Language” front at the moment. Martin Fowler published “Language Workbenches: The Killer-App for Domain Specific Languages?”, in which he concludes that the common programming pattern of setting up repeating data structures via either very similar lines of code, or an external configuration file, is actually a DSL. He also republished a paper by Dave Thomas entitled “Design to Accomodate Change” on the related topic of table-driven programming.
However, Martin’s essay goes beyond common programming and data techniques to look at the development of specialist tools which he calls “Language Workbenches”. I’m not completely convinced that we need these in the world of XML and XSD. If you have a defined schema for you XML-based DSL (and aren’t all the many *ML langauges just different DLSs?) then any schema-sensitive editor will provide you with good design and editing support. The leading IDEs (e.g. Visual Studio) all have such a tool built into their core capabilities. Surely we now have a sufficiently sophisticated set of XML-based tools and standards that we have an opportunity to exploit synergies rather than re-inventing the wheel?
The Fear Premium
In an interesting echo of my last piece (Why Software Isn’t Like Building Construction), Scott Ambler has analysed bureaucratic processes as a response to management fear about what can go wrong in software development. His conclusion is that these processes only give the illusion of addressing the underlying fear. His article is well worth reading.
Why Software Isn’t Like Building Construction
Many software development and management methods are founded on a basic assumption – that constructing software is rather like building a bridge or a house. Once we’ve “done the design”, actually generating the software ought to be a completely predictable, relatively low-skilled process. However four decades of failure to achieve this vision might suggest that we should revisit
the assumption.
In a paper entitled “The New Methodology” Martin Fowler, the guru of object-oriented development, suggests a couple of reasons why this might be.
My article answers Martin’s, suggesting a couple of other considerations, and whether we have to completely abandon the physical construction analogy as a result.
Review: Waltzing with Bears
Managing Risk on Software Projects, By Tom DeMarco and Tim Lister
A good book covering an important and negelected area
|
This book is an interesting mix. It starts with a philosophical discussion of why it is ethically wrong and success-endangering to ignore risks, but commercially weak to simply avoid them, thus establishing that we must accept and manage risk. The book then develops a comprehensive method for risk management in IT (or other) projects. It may be surprising where DeMarco & Lister start from, explaining what risk is, why we need to accept it and why we must manage it, but they explain how common attitudes in the IT industry, which they correctly term "pathologies", can make it almost impossible to properly acknowledge and manage risks. |
Posted in Reviews
Leave a comment





