Christophe Thibaut on models
Ecris le 21 janvier 2006
Dans la catégorie Web surf | Laissez un commentaire
Concluding a quite animated discussion on the French XP mailing list, Christophe Thibaut offers us a superb deconstruction of the word “model”. Christophe, I think you should open your own blog now 
Sustainable pace
Ecris le 2 décembre 2005
Dans la catégorie Articles | Laissez un commentaire
One of the well known XP practices is “sustainable pace”. Until now, I saw it as the idea that the team members should not overwork to avoid to be too much tired, otherwise the moral and the quality will decrease. This is obviously true, but there is more behind this practice.Imagine a project going in a fixed-time mode.
Quite a common situation. Imagine that some technical choices would have been done at the beginning of the project that have as consequence that the team productivity is 50% lower than expected. Suppose now that the team members accept to work nights and days, and to come during the week-end to recover the productivity. The question is: what is their limit? Until which point can they overwork before the collapse. The fact is that nobody knows, even them. Nobody can predict when an overworking team member will stop working.
This shows that a project where the pace is not sustainable is by evidence not managed. If you are in a situation where you have to overwork to finish your project, this is obviously because the project is poorly managed. On the opposite side, if you are in a situation where you ask somebody else to overwork to finish the team-work, ask yourself if your are not putting on him the default of your bad organization.
Hence, never accept to work beyond your sustainable pace. If you do so, you will not help yourself, you will not help your team, and you will not help your manager.
Beyond Java and Seaside
Ecris le 15 novembre 2005
Dans la catégorie Uncategorized | Laissez un commentaire
Two very nice articles have been posted into the Smalltalk community, following the Bruce Tate’s article on IBM web site about Seaside.First, the reaction of Avi Bryant on his blog, where he explains how he came to continuation and to Smalltalk.Second, there is a very nice interview of Bruce Tate on Weekly Squeak.
Metaprogramming and clean, dynamic languages are the future. The Smalltalk community is inspirational to me, because it’s not the world’s most popular language, and the users don’t care. They know it’s one of the most productive languages. We all need a competitive edge. If Smalltalk is yours, so be it!
The frontier
Ecris le 2 octobre 2005
Dans la catégorie Uncategorized | Laissez un commentaire
My favorite recurring ?big theory? is that information management systems are very particular animals compared to scientific or industrial systems. Their main purpose is to automate into a machine some processes which are by nature ?human? process. Computer languages are often by nature quite from the scientific field. It is all by about manipulating numbers and characters with big precision and it is admitted sometimes that to be a good computer scientist, you need to have a good scientific background. However, we all know persons who are not scientists and who turn out to be very good computer experts, maybe better than scientific one. For instance, we know that persons who did philosophical studies can become very good computer specialists.So, we have on one end human processes and we want to automate some of them into a machine on the other end. I think that designing and constructing information management system is all about this task of selecting some human processes and put them into a computer system. They are now two questions:
- Which processes should I automate?
- How should I automate them?
The second question is all about software design, and a lot of energy has been spent on this topic since computer exists. We know for instance that the Object Orientation approach is a very good one to help this design, and its implementation into code.The first one is more complex. It asks actually where we should put the frontier between human processes and computer processes. Peter Williams has a very good example of this dilemma. I strongly encourage reading Peter?s post to better understand what kind of problem I am trying to address here.We often encounter situation where the implicit goal is to put as much as possible into computer. It is considered as a progress when computers are taking more and more tasks which were done by humans. Most enterprises seek this goal and call this quest ?improving the return on investment?. I am not so sure that this is a good quest. For sure, humans feel better of not doing some tasks, which in turn should be left to our computers, but some tasks should be left to humans. This frontier between human processes and computer is not easy to design, and it is also moving. The study of its nature and the understanding of how it should move is a very interesting topic that I am currently trying to explore.
Object orientation enlightenment
Ecris le 17 septembre 2005
Dans la catégorie Uncategorized | 4 commentaires
There is something that annoyed me until now with Smalltalk: the code browser.I give here a sample of this famous GUI, which is the Squeak code browser (other Smalltalks have very similar code browsers).
The Browser has two main parts. The upper part is four listbox allowing to select the method you want to edit. From left to right you have classes packages, classes, protocols and methods. Protocols are just group of methods. The other part of the browser is the code of the selected method.
Yes, you can see the code for only one method. If you want to see the code of two methods, even of the same class or same protocol, you have to open another browser. This limitation was really annoying me. I was used to editors showing, at least, the code of one class as one piece of text. I give you as an example a screenshot from Java Eclipse. Actually, editors for most of other languages, including C, C++ and even Ruby, have this design: you can see and browse as a document the whole code of your class.
I really did not understand why Smalltalk kept this simple and apparently stupid single method browser, since 25 years. It was really a puzzle for me because my experience is that Smalltalk is a highly distilled environment. Nothing is there by coincidence and current Smalltalk are really designed the way they are because that’s the best design available.
And today, I realized what I missed.The important part is not the code: it is the upper part with classes, protocols and methods. Programming with Smalltalk is actually creating meaningful classes names, meaningful methods names and organize them into self explicatory protocols. Jeez, those guys understood every thing 30 years ago!!
When you program with Smalltalk, don’t thing first about writing code, think first about designing methods and protocols. The language syntax by itself is not important here, what is important is the name of your methods. That’s why Smalltalk has so little basic syntax and such a huge library: object programming is producing meaningful classes and methods names.
I probably read it in some books but this is such a paradigm shift compared to other languages that I did not understand it… until today.
XML Simplicity
Ecris le 11 septembre 2005
Dans la catégorie Uncategorized | Un commentaire
Blaine Buxton delivers again a jewel thru its Positronics vibration blog. He shows us how simple and easy it should be to handle XML documents. Indeed, XML is just a complex and verbose way of representing lists, which have been nicely done since 40 years in any Lisp flavor. Blaine’s implementation of its XML renderer comes back to this simplicity.
I do love that!
French Smalltalk party 2005
Ecris le 9 septembre 2005
Dans la catégorie Uncategorized | Laissez un commentaire
Serge Stinckwich is organising one more french Smalltalk party. The previous one was a great opportunity to meet other enthusiasts and discuss Smalltalk in general and Squeak in particular. Seaside was a great subject of discussion and I hope it will still be at the center of the demos and discussions.
Come and see you there!
Agile incremental construction: some tips
Ecris le 31 août 2005
Dans la catégorie Uncategorized | Laissez un commentaire
Since some time now, I help my customers to design and build their Information System by an incremental approach. I noticed that obviously the term “incremental” does not mean the same thing for every body. For the most common case, the team try to slice its system into layers and build each layer one after the other: for instance the data layer comes first, then the process and finally the GUI. This slicing is driven by technical constraints as you can see in the future application where the database will stand, and when the associated tools will be used to build this particular part.
The drawback of this approach is well known by the agile community: if you fail to finish one of the layers in the planned time and budget, you can be sure you will exceed the project budget. Unfortunately, if your budget was fixed, you project will be a total failure for one problem on one layer.That?s why the agile approach suggests slicing your project into iterations, but also that all iterations must be functionally and technically coherent to be production candidate. That mean each iteration should have a little bit of data, a little bit of process and a little bit of GUI.The question is: how can I slice my big project into coherent slices (or iterations)?
In most case, after some study, or not, the project is launched for a given budget, estimated with more or less precision (generally, the precision is very low at this stage). Let say your budget is 1000. You want to slice your project into 5 iterations of 200. The approach I follow generally is to apply the following simple algorithm:
- Suppose your project budget was only one iteration (200 is this example)
- Determine what you should do for 200: this is your first iteration
- For each following iteration, determine what you should do to improve the application by adding features, or refactoring, for a value of 200.
- Stop the algorithm when your budget is reached.
The idea is that if you burn all your budget (1000) on the first iterations, at least, their functional scope has been designed to have the highest value for the customers. XP calls this practice “the planning game”. Of course, downsizing a 1000 project to a 200 one is not easy and request to have a strong knowledge of the domain to know what is REALLY the core of the business. Domain Driven Design can help you during this process.
Anyway, slicing a project in such a way is a difficult task, but that’s the cost of monitoring your risk efficiently: nothing comes for free!
Agile Web Development with Rails: the book of the year?
Ecris le 28 août 2005
Dans la catégorie Uncategorized | 5 commentaires
Dave has the pattern “study the classics” where he states:
There are an amazing number of programming books out there. Distinguishing the good ones is a critical skill because reading the right book at the right time is priceless.
I can tell you that Agile Web Development with Rails is one of those ones.
This book is amazing. Actually, the mix of Rails and the book is amazing. As you know, I am from the old pragmatic school. All the gimmick and technical sugars of J2EE and following never appeared quite compelling to me. As a consequence, I never get the point of having ORM or MVC Web framework and such things, as it appeared to me to be a heavy weight load of complexity where much simpler solutions exists, and have always existed.
The big Java project I am starting those days confirmed me my impression. We are going to use a corporate web Java framework build in house. The thing is heavy, complex, and do very simple tasks (managing JSP pages) with such a numbers of layers and complex acronyms that I know the project teams are going to be slowed down just to understand what they have to do with that beast.
Rails is another animal, and Dave?s book does a wonderful job at explaining why. Suddenly, web flow management becomes simple, ORM becomes useful, and test frameworks are so easy to use and explain that one does not understand why we did not work that way since the beginning.
Really, if you plan to become an acceptable web object programmer, I think you should get that book, even if you are working with legacy technologies such as Java or .Net: it will show you the direction you have to follow for the next few years.
Nicolas Reimen on Wittgenstein
Ecris le 19 juillet 2005
Dans la catégorie Uncategorized | Laissez un commentaire
Yesterday, I had the opportunity with other colleagues from OCTO to listen to Nicolas Reimen conference on the philosophical origins of Computer Sciences.
Nicolas is both a philosopher and an IT manager with many years of experiences in both fields. This allowed him to conduct a quite amazing analysis of how Turing and Von Neuman have influenced the common way of designing IT systems, and why this might lead to current difficulties in the way IT projects are managed.One of the central ideas I think I have understood is that Wittgenstein had discovered as soon as the 50s why applying only Turing/Von Neuman approach to rationalize and unify digital processing leaded us to a dead end. This objective is simply impossible to achieve and does not make sense. By extension, trying to improve IS quality by producing documents describing and analyzing IT systems lead also to a dead end, and should not be the primary objectives of IT managers.
I will not try to explain furthermore Nicolas?s ideas, as I don?t feel I have the philosophical skills and background that enable me to try this exercise today.
However, I hope I have created interest for you to have a deeper look to Nicolas Reimein work. I think I should try myself to read more from this Mr Wittengstein
References:http://www.lwmis.org/http://www.pathways.plus.com/isfp/businesspathways/issue16.html
