In summary (original numbering scheme!), places to think about intervening:

9. Numbers
8. Material stocks and flows
7. Regulating negative feedback loops
6. Driving positive feedback loops
5. Information flows
4. The rules of the system
3. The power of self-organisation
2. The goals of the system
1. The paradigm or mindset out of which the goals, rules and feedback structure arose.

[ via Johanna Rothman]

Specifically all works until I try and save a document using parameters (to tell OpenOffice to use an output filter), at which point the OLE Bridge is giving an error.

If anyone reading this has found and cured a similar problem I’d be interested in your thoughts. Code snip follows:

Ignore the escaping of the ” signs – this seems to be some oddity of my WordPress installation…

# oo tests

require 'win32ole'

$serviceManager = WIN32OLE.new("com.sun.star.ServiceManager")
$desktop = $serviceManager.createInstance("com.sun.star.frame.Desktop")

def newWriterDocument()
    document = $desktop.loadComponentFromURL("private:factory/swriter", "_blank", 0, [])
   document
end

def test()
   filter = "writer_pdf_Export"
   fprops = makeProperties("FilterName" => filter)
   document = newWriterDocument
   text = document.GetText
   cursor = text.createTextCursor
   text.insertString(cursor, "Hello World", 0)
   oURL = "file:///c|/test.pdf"
   document.storeAsUrl(oURL, fprops) # this line fails with OLE error
   #store a document in standard format - document.storeAsUrl(oURL, []) - works
end

def makeProperty(name, value)
   property = $serviceManager.Bridge_GetStruct("com.sun.star.beans.PropertyValue")
   property["Name"] = name
   property["Value"] = value
   property
end

def makeProperties(hash)
   properties = []
   hash.each { | key, value |
   properties < < makeProperty(key, value)
     }
   properties
end

begin
  test
rescue

ensure

end

Question also posted to OpenOffice.org forum.

OpenOffice.org forum came up with the answer:
Replace

document.storeAsUrl(oURL, fprops) # this line fails with OLE error

with

document.storeToUrl(oURL, fprops) # this line works!

]]> http://www.synesthesia.co.uk/blog/archives/2005/03/25/problem-with-openoffice-and-ruby/feed/ 1 http://www.synesthesia.co.uk/blog/archives/2004/09/19/blogwalk-iv-intrabliki/ http://www.synesthesia.co.uk/blog/archives/2004/09/19/blogwalk-iv-intrabliki/#comments Sun, 19 Sep 2004 09:10:32 +0000 Julian http://www.synesthesia.co.uk/blog/archives/2004/09/19/blogwalk-iv-intrabliki/ Blogwalk IV was the use of social software inside the firewall. We noted that there were certain technological barriers to be overcome before the tools were sufficiently invisible to support a wide acceptance of corporate blogging / wiki etc. I agreed to start some work to define the requirements of the ideal internal corporate blog / wiki tool so I've started writing some initial user requirements in the wiki. The root of the notes is at IntraBliki, please join in if you are interested.]]> The theme of Blogwalk IV was the use of social software inside the firewall.

We noted that there were certain technological barriers to be overcome before the tools were sufficiently invisible to support a wide acceptance of corporate blogging / wiki etc.

I agreed to start some work to define the requirements of the ideal internal corporate blog / wiki tool so I’ve started writing some initial user requirements in the wiki. The root of the notes is at [wiki]IntraBliki[/wiki], please join in if you are interested.

In “another post(Documents Create Antagonism)”:http://abc.truemesh.com/archives/000305.html he also puts his finger on a common problem with “Big Design Up Front”:http://c2.com/cgi/wiki?BigDesignUpFront projects – namely the dysfunctional behaviour driven on both business and development sides of a project by too much early specification that does not consider the value of requested features.

*Chapter 3 – Decide As Late As Possible*

* Concurrent development – the importance of both knowledge and collaboration.
* Cost escalation curves for changes – the old “exponential” model for increasing cost of late change really only applies to critical constraints (e.g. major technical architecture decisions)
* Use “breadth first” approach for the major constraints – for other aspects defer decision as long as possible through iterative development
* Importance of keeping options open until “last responsible moment”
* Share information early – don’t wait for it to be “complete”
* Direct worker-to-worker collaboration
* Learn how to deal with change
* Breadth-first decision making works best when business domain is evolving
* Simple rules allow robust and flexible response to real-world variation

Mindmap: JPEG [110kb], MindManager

Chapter 2 – Amplify Learning

The problems solved by software do not have “right” answers, rather it is a case of seeking to reduce uncertainty as the project progresses – uncertainty about customer requirements, uncertainty about technology. Software development is therefore a process of learning and like all learning inherently cyclical.

The tools introduced in this chapter are primarily about adopting maximising opportunities for learning, enhancing communication between the people who understand different parts of the problem domain and allowing solutions to emerge that meet the needs of all stakeholders.

An iteration should be considered a demonstration of a possible solution; it should not be considered an only solution [...] As iterations progress and more choices are made, the design space should be gradually narrowed

Tool 3 – Feedback
Tool 4 – Iterations
Tool 5 – Synchronisation
Tool 6 – Set-based Development

Reading this chapter I was struck by the importance of trust between all stakeholders – I’m looking forward to see how that might be dealt with when they discuss teams, committment, motivation and contracting issues…

Mindmap: JPEG [155kb], MindManager

Updated 2003-10-13
Re-reading the chapter, and as the result of a couple of real-life project conversations that have happened since the original entry, I’ve realised the importance of the concept of variable scope. In the book the Poppendiecks cite ROI, It’s your job [PDF 716kb] by Jim Johnson of The Standish Group. In that document Johnson refers to a study of over 35,000 application development projects which found that in a typical system 45 percent of features are never used and 19 percent are rarely used

The Poppendiecks note (p32):

Since customers often don’t know exactly what they want at the beginning of a project, they tend to ask for everything they think they might need, especially if they think they will only get one shot at it. This is one of the best ways we know to increase the scope of a project well beyond what is necessary to accomplish the project’s overall mission. [...] If you let customers ask only for their highest priority features, deliver them quickly, then ask for the next highest priority, you are more likely to get short lists of what is important. [...] This approach to project management may seem to lead to unpredictable results, but quite the opposite is true. Once a track record of delivering working software is established it is easy to project how much work will be done in each iteration [...] by tracking the team velocity you can forecast from past work how much work will probably be done in the future.

Chapter 1 – Eliminate Waste

waste = non-value added activity

value = customer perception

Tool 1 = seeing waste

* Partially Done Work
* Extra Processes
* Extra Features
* Task Switching
* Waiting
* Motion
* Defects

Tool 2 – Value Chain mapping

* Map process flow
* Value-added
* Non-value-added
* Prioritise improvements
* Repeat

Mindmap: JPEG [93kb], MindManager