|
|
I’m reading the downloaded Thinking Forth PDF by Leo Brodie.
The preface to the 2004 edition starts off a bit strange:
- in the 1984 preface he disses object oriented programming
- in the 1994 preface he apologizes for that, after having worked a bit with an OO Forth
- in the 2004 preface he partially retracts his apology and notes that he by no means has sold out in favor of full-blown OO languages, because “there was no need for garbage collection etc” in the OO forth
- and then he disses Extreme Programming. Some people have noted parallels between Thinking Forth and XP: iterative development, incrementally enhancing code that works, not over-solving the problem. But XP does no conceptual design, from what he’s read about it. He concludes the preface with: “But the irony in comparing Thinking Forth with Extreme Programming is that some developers of the XP stripe (and who of course have never heard about this book) don’t even see the value of a spec! Ah well.“.
Ah well.
But there’s a lot of stuff that resonates (again) with thoughts about DSLs:
“An important result of this approach is that the entire application employs a single syntax, which makes it easy to learn and maintain.
In fact, you shouldn’t write any serious application in Forth; as a language it’s simply not powerful enough. What you should do is write your own language in Forth (lexicons) to model your understanding of the problem, in which you can elegantly describe its solution.“
And on design:
Forth is a design language… In Forth you can write abstract, design-level code and still be able to test it at any time by taking advantage of decomposition into lexicons… Using this philosophy you can write a simple but testable version of your application, then successively change and refine it until you reach your goal.
How very much unlike design in XP!
And on planning:
Forth programmers spend less time planning than their classical counterparts, who feel righteous about planning. To them, not planning seems reckless and irresponsible. Traditional environments force programmers to plan because traditional programming languages do not readily accommodate change.
The book mixes Brodie’s views with interviews of people using Forth and of Forth’s creator Chuck Moore. The advice they give is often contradictory (plan more, plan less), as each gives the advice that is applicable in their situation. I remember that at the time I first read this book, one of my colleagues (who liked Forth) said he hated the book: “Can’t they make their minds up? They constantly contradict what they said a few pages before!” 🙂
I especially like Moore’s bits. One of the tips is: Don’t write your own interpreter/compiler when you can use Forth’s
Moore explains it thus:
If you write your own interpreter, the interpreter is almost certainly the most complex, elaborate part of your entire application. You have switched from solving a problem to writing an interpreter.
I think that programmers like to write interpreters. They like to do these elaborate diffcult things. But there comes a time when the world is going to have to quit programming keypads and converting numbers to binary, and start solving problems.
Take that you evil purveyors of badly designed programming languages disguised as configuration files or (the horror!) XML files!
Today was a book day
What did I find on my doorstep today? A big box full of books from Dorset House Publishing.
 |
Inexplicably, most of Gerald Weinberg‘s books are very hard to come by. He has written excellent books about Systems Thinking, the psychology of programming, congruent action, requirements, consulting… His books are required reading. So, I sent off an order directly to the publisher for myself, Laurent, Marko, Vera and Nico.The stack of books sitting now on my desk covers a lot of subjects: productivity, walkthroughs, requirements, systems thinking, measurement, psychology and organisational maturity. The two most ordered books are “The Secrets of Consulting” and “More Secrets of Consulting”.More on a few of those books later. |
 |
And on top of that box was another book: the paper copy of the Ruby on Rails book I’ve been reading in PDF pre-release form over the past month.We’ve started up development of an application to manage the registrations, payments and communications around the XP Day Benelux 2005 conference. This application uses Rails. We hope to see through the hype and learn if RoR is really so “Agile” as it claims. |
 |
And then a question about Domain Specific languages made me look up some more information about the Forth language. Forth was (a long long time ago) the first language I used that encouraged the programmer to build domain specific languages. Forth itself is a very primitive and simple language. But it allows you to create slightly higher level language elements or “words”. There is no (visible) distinction between those new words and the built-in words. And then you use those words to build slighly higher level words… Until you end up with a language that makes it easy to develop your application.So I went to look for Leo Brodie, whose books “Starting Forth” and “Thinking Forth” really made me understand this weird language and its even weirder way of programming. I wanted to buy these books for a long time, but they were out of print. And now I discover that “Thinking Forth” can be downloaded from Leo Brodie‘s site and has been re-published. I sent my order off to Amazon. Can’t wait ’till it gets here. Until then I’ve got some other books to keep me busy. |
A potential new bottleneck
Last week we noticed that some of our users didn’t know some features were available or were unsure how to use the new features in the previous release. So, we spent some time explaining some of the features.
This is a timely warning: our ability to effectively transition the software into production use could become a bottleneck. This is both a good and a bad thing:
- It means that our bottleneck, the development team, has been elevated to a level that’s nearer the capacity of the users to accept new features. This is good: our efforts to elevate the constraint are starting to work.
- Our capacity to train users and the user’s capacity to accept new features might become the new bottleneck. This is bad news: we don’t want the bottleneck to get out of our control.
This is a typical pattern for agile processes: the development team is elevated and after a while the customer, who subordinates to the development team (as the XP customer does), becomes the bottleneck. Suddenly, the customer can’t write stories fast enough to keep the team occupied; releases are implemented so quickly that the users can’t keep up with the flood of new features.
What to do?
Before the users become the new bottleneck, we need to take measures to elevate them so that the bottleneck doesn’t shift. What are we going to do?
- We have regular meetings with our key users who follow up new developments. We need to make these more “hands on”: show the users how new features work, let them experiment some more.
- Training and transition to a new release is handled by people in the users’ organisation. We can support them more during final acceptance testing and transition to the new release.
- We can hold an “end of sprint demo”, like Scrum prescribes to show the new features (and how they’re to be used) to a wider audience than the key users.
- Each release is focused on one group of users. For example, the current release contains mostly features for the commercial people. They will need some training to use the new release. Other groups will see only a few minor changes, so that for them the application doesn’t change too much.
Release less often?
Some have suggested that the problem is caused by us releasing too often. We release every two months. Should we release less often? I don’t think so: we used to release every 6 months and that caused big acceptance, transition and training problems. In comparison, today’s problems are insignificant.
I would suggest to release more often, establish a regular rhythm of changes. Have each release contain fewer changes, changes that appear shortly after the users ask for them and they’re fresh in their mind. Get a regular rhythm going on the “drum“, increase the “takt time”, level the load to reduce the waste due to unevenness.
Making change routine
People don’t like to change. They like routine and predictability. How can we make change easier? Regular “Kaizen” events, regular retrospectives to steer the process establish a rhythm of change. If you review and improve your process each month, every month, people become accustomed to the change.
If you want to change the routine, make change routine
The project burn up/down chart
Our team has a very public burn up/down chart. This is where we stand today.
 A short reminder:
- The red line tracks the burndown of estimated story work to do
- The green line tracks the delivery of estimated story value
What happened in the past two weeks?
Two weeks ago, both graphs went sharply up/down. The value chart a bit steeper than the cost chart, because we work on the highest value stories in the beginning of the project
Last week the chart was flat. No story completed this week. Oooops….
Why?
- One story counted two weeks ago turned out to be incomplete. Added some more tests to make the problem apparent, completed the implementation. No extra points, as they were already counted. If we hadn’t completed the story before the end of the week, we would have subtracted the effort and value.
- We’re all working on big, 4-5 point stories. When these complete we’ll have another big jump on the chart. That’s another disadvantage of big stories, they don’t help us level the load and they make tracking less smooth. Maybe we’re in trouble, but we won’t see quickly. We’ll only know next week, when these stories are expected to finish.
- Some of our users seem to be unclear on what new features are available and how to use them, so we spent some time explaining how the application works.
Lessons learned:
- Spend more time on tests, especially acceptance tests
- How could we have broken down these stories in 2-3 point parts?
- User acceptance of new features could become a bottleneck. Read more….
Big VISIBLE chart
People passing by and looking at the chart came up to me and asked “Hey, what’s wrong? Your graph is flat.“. Now that is instant visibility into the state of the project. Passers-by know at a glance when we’re doing well or badly.
Not bad for a tool that cost almost nothing and takes 10 minutes a week to update…
|
|
