Small Is Beautiful
5 comments Latest by Shane Vitarana Tue, 06 Jun 2006 20:07:53 GMT
Some people have habits that are hard to break. Mine is that I tend to pick up books off of our bookshelf…okay…90% of the books are my fiances… but I’ll take one and just open it and start reading. The problem with this is that I really don’t make (or find) enough time to start at the beginning and finish each book. I often end up just opening up to a random section and reading a few pages until I realize that I’m totally lost or until I find something interesting to think more about. Occasionally… I finish the book.
One such book that I am reading is Small is Beautiful by E.F. Schumacher, which was written in 1973. The topic of the book? “Economics as if People Mattered.”
The other day I read a section about developing nations, which has always been a topic of interest to me. I’m going to take a step away from the topic of the book and extract something that the author said that caught my interest.
“We tend to think of development, not in terms of evolution, but in terms of creation.”
When I read this… I know that this isn’t referencing application development but development of third-world nations… however it got me thinking. Is it our tendency to try and plan things the whole way through so that we can follow through and create the definitive and ideal solution in one try? This is exactly how some development processes work. Gather requirements, develop one monolithic plan, and implement it. This process can take a half of a year to several… depending on the size of the company. Perhaps there is very little difference between the three year project and the three month, except the smaller team and lapse of time. Could it be that when we admit that we know that requirements will change over time and if we take an iterative approach that we will be better prepared and more open to change?
...and perhaps the following quote could be applied to the topic of good usability...
“An entirely new system of thought is needed, a system based on attention to people, and not primarily attention to goods. . . .” - E.F. Schumacher
Development should be an evolutionary process… and real people should be where we focus our attention to.
...what are your thoughts?
Enjoying the content? Be sure to subscribe to my RSS feed.
One of the repeated themes in Brook’s Mythical Man Month is that you don’t get to find out if your ideas are wrong until you implement. Do to much spec work upfront, and you’re spending time producing artifacts that are likely to be irrelevant once you get around to using them.
The other day I wrote that Every line of code is a liability because they’re static promises made against a dynamic world.
I think that applies equally to application code and specifications. Specifications are debts that require regular payments: time spent keeping the spec in sync with the real world.
There are perhaps some exceptions, domains where hard specifications that remain valid for years or decades are more common, such as in embedded world. There the monolithic plan may be a viable strategy.
It’s been so long since I read Small is Beautiful, I had almost forgotten about it, but this is now the second reference I’ve seen in the last 2 days. Must be a sign I need to pick it up again.
It occurs to me now that there are some similarities in the thinking of both Schumacher and Christopher Alexander. Even though Alexander is well known for the patterns work, what’s always stuck with me more about his work is the focus he puts on the “enduser” and the way he talks about buildings and living structures developing through use rather than through an initial architectural “vision.”
How the hell did you manage to connect a book about Buddhism and economics with application development? I haven’t read that book in years!
God (DHH) created Rails in seven days.
”An entirely new system of thought is needed, a system based on attention to people, and not primarily attention to goods. . . .” – E.F. Schumacher
This quote also fits well with the Agile tenent of putting people over process.