Tagged Posts: Software_Development
Developer.* has published Places To Intervene In a System by the late Donella Meadows, with an afterword by Don Gray applying the thinking to software devleopment. Thought-provoking stuff - Meadows herself cautions that the essay is not a recipe for finding leverage points. Rather it’s an invitation to think more broadly about system change.
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]
Technorati Tags: Software_Development, Systems
I’ve been trying to automate OpenOffice from Ruby to carry out a batch format conversion of approximately 100 documents. I’ve researched a fair amount on the web, especially here, here and here, but I’m still having problems.
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:
(more…)
Technorati Tags: OpenOffice, Ruby, Scripting, Software_Development
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.
Technorati Tags: BlogWalk, Organisations, Social_Software, Software_Development
“Extreme Programming and the Economics of Flexibility”:http://www.favaro.net/john/home/publications/xpecon.pdf [PDF] via “Agile Business Coach”:http://abc.truemesh.com/
Technorati Tags: Software_Development
“Chris Matts”:http://abc.truemesh.com/ “points”:http://abc.truemesh.com/archives/000306.html to a paper he co-authored with “Andy Pols”:http://www.pols.co.uk/blog/index.html on “Business Value-driven Software Development”:http://www.pols.co.uk/business-coach/BusinessValueDrivenDevelopment.pdf (PDF) Sounds like obvious common sense to me, which presumably means it doesn’t happen as much as it could in the real world! 
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.
Technorati Tags: Software_Development
Continuing to work through Lean Software Development by Mary & Tom Poppendieck.
*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
Technorati Tags: Books, Software_Development
Continuing to work through Lean Software Development by Mary & Tom Poppendieck.
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…
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.
Technorati Tags: Books, Software_Development
Started to work through Lean Software Development by Mary & Tom Poppendieck.
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
Technorati Tags: Books, Software_Development
Facebook
