It's me *smile*

James has new images of the OOP 2007 conference. The first picture shown here shows me in a talk with Georg Heeg.

Team communication

A few days ago I've talked about process patterns. Those are templates for the own work in a team to support successful processes. Most of them are generally usable, some are special for software development. Today I'll talk about one of my favorites and the most importand: communication.

Regardless of which role you have in your team your work needs an exchange of information with your colleagues and customers. You'll find many informations about problems based on missing or wrong communication. Very often managers don't really talk with their team, much of the process or a choosen architecture is poorly described and their is almost no direct contact between the development team and the customer. The results are decisions based on the wrong starting basis, misinterpretations of requirements or process instructions and the steady increase of existing conflicts.

So one of the first steps is to get a clear picture of your personal environment. Whom do you communicate with? When? How? How much? Which role does this person have and how is your relation? Often it is very helpful to draw a small diagram showing these persons and the factors mentioned above.

It is also helping to document their pesonality types. I've used the Myers-Briggs Type Indicator (MBTI) here. It knows 16 basic personality types based on the four criterias

• Favorite World (Extraversion (E) or Intraversion(I)),
• Information (Sensing (S) or Intuition (N)),
• Decission (Thinking (T) or Feeling (F)), and
• Structure (Judging (J) or Perceiving(P)).

All those are not black and white, so there are many nuances. And you don't have to use the MBTI, there are different ones and each one is also discussed very controversial. But it helps in communicating with different people if you've made some thoughts about their personality. You've got to take each one how he is. Beside the informations for the direct communication with you, it may be helpful if you try to get some informations about the relations and communication in between those people. Sometimes there are conflicts, or some are acting very good together while you've got a problem with one of them. The reasons may be in the company history, in the types or somewhere else. If you consider this during you communication you may change all your lines into green.

It is also very important to choose the right way of communication. Today e-mails are written very fast but they are also clinical. And they don't support a quick agreement on a common wording and understanding. Here are face to face discussions in front of a whiteboard very productive. But the result isn't very formal and lasting. Mails, letters or documents are much better for this. So you've got to choose the right way different for what you want to achieve. Additionally it is necessary to choose the right communication frequency. Not too often to annoy your partner, but also not too seldom. If you're responsible for a team there's the really good way of Management by Walking Around (MBWA). It advises to

• do it to everyone,
• do it as often as you can,
• go by yourself,
• incorporate subordinate managers,
• ask questions,
• watch and listen,
• share your vision with them,
• work with them,
• bring good news,
• have fun,
• catch them while they are doing good work, and
• dont be critical.

Try it, it really improves the communication and everyone gets a better understanding and a better feeling.

Switched blog software

tDiary is really a nice peace of software, but the documentation is really poor. Due to some problems I've had with it I decided to switch to Simple PHP Blog. Until now I'm very satisfied with it. I really like it if software tries to by as low complex as possible. So this software is installable by unpacking with a very simple initial configuration. And it also doesn't need a database behind it. All data is stored in text files.

OOP 2007 - Soft skills

The tracks on friday lasted the whole day. I've chosed "Social - never mind?" by Bernd Oestereich, Guido Zockoll, Uwe Vigenschow and Alexander Lenhard. They introduced into different communication models and techniques. Even if I've read much of it before it has been really interesting to hear it again. Beside communication basics the project environment, the technique of asking questions, typology, feedback and conclicts have been covered. All together emphasized my opinion that soft skills are really important for teamwork.

OOP 2007 - SOA governance and lifecycle management

The last track today has been about governance and lifecycle management as critical success factors of an SOA by Andy Wolf. I'm currently writing a concept for the development, introduction, and maintenance of service-oriented architectures. So I've allready covered serveral of the aspects presented in this track. But his papers are much more detailed and contain new or better formulated items. This will make my life more easy. *grin*

OOP 2007 - Bad smells in agile processes

Jutta Eckstein refered about bad smells in agile processes as an indicator for a misinterpretation. The agile manifesto defines the base ideas for a flexible value-oriented software development. So XP, scrum, or the crystal methodologies don't have to be followed strict. It is more important to interpret the idea behind it right. So she mentioned different known bad smells and made recommendations how to avoid them. She has a real good style in presenting and you recognize here experience immediately. I'm practicing agile processes - as far as it has been possible in my jobs - since 2000 and her track has been really interesting fo me.

OOP 2007 - Architecture is like decathlon

Peter Hruschka compared architecture to decathlon in his track today. The disciplines are design, decide, simplify, evaluate, verify, document, implement, communicate, balance, and consult. In his opinion it is not enough to hold the world record in one discipline, even beeing very good in several disciplines isn't enough. To be top you have to be real good in every discipline. I like this comparison.

OOP 2007 - SOA case studies

Today two case studies for service-oriented architecures provided a deeper look into real live tasks and problems. Both environments, LifeSensor and VR-Services, have started several years ago due to different reasons. The requirement for felexibility and customizable communications with different service providers where common.

Interestingly they both made some equal experiences and choosed equal ways. So there is much communication needed due to the many involved teams when discussing the different topics. The spreading of operating department, IT department, management, and more reflect the spreading of the owner of the services. Also there is currently no good tooling for development, refactoring, version management, and automated testing. Know procedures from the usal programming aren't usable here. This is one of the reasons why I'll continue to think about Smalltalk as an SOA platform. Adapters to web services and other data sources or service providers can as easily be developed as business processes or transformations.

Both also created normative messages representing the business objects. But the discussion to standardize them between all service providers are difficult and last long. For a better acceptance of their solution they created high level APIs which encapsulate aspects like the communication, the message creation, error handling, and encription.

So the conclusion has been positive. But it takes a long time and much effort to establish an SOA. Everyone should keep this in mind.

OOP 2007 - Smalltalk for modelling

Highlight today has been the traditional Smalltalk evening, this time covering a project of the Heeg eK and SAP. It is called Explorative Modeling (xM) and describes an agile process for a better specification of what the user needs. The explorative modeling is placed between analysis and design as an iterative sub-process. The base idea is that the customer and the developer are speaking different languages - see the track of Chris Rupp above. So the explorative modeling shall help to understand the application domain by examples. Typically customers are more informal and UML is a good language for a detailed design specification but not really appropriate to talk about the requirements with him. Both need a mutual agreement on the model. So they need a way for an interactive and fast communication.

The way xM tries to achieve that is the iterative process of building a model in a suitable language, conduct experiments for the verification of the model and - when every one is satisfied - document it for the design specification. This is a simple step, typical forms like the UML and/or documents are possible. The language to build the model should be simple and executable to create more than just prototypes and mockups. The needed qualities are a non-technical, barrier free scripting style, it has to be meta-programmable, interactive, and concept-oriented. So the Heeg eK and SAP choosed Smalltalk.

The first pilot has been the Duplicate Analyzer to find double invoices. SAP tried it with a NetWeaver application using their TREX. But it found too much false positives. The first step with Smalltalk has been a reimplementation, only with an own rule engine. Even if they had no other rules they now had the base for experimenting. First runs had an execution time of 1h on a notebook for 120.000 invoices instead of 6h on the SAP server system. *grin* But it has the same amount of false positives - no wonder, the rules didn't changed. After that they talked with the users to get a better understanding of the domain and experimented with the rules. Very fast they've been able to change their model to find less false positives but new real duplicates due to the better knowledge. All that has been done in one week of Smalltalk training and seven days of development.

After that success phase 2 of the evaluation has been the project xCarrier for logistics. The rule engine should help to find the right distribution channel. The application has been used stand-alone during customer interviews and the response has been very good. So SAP started phase 3, again with xCarrier, but now directly integrated into SAP with the new Cincom Smalltalk for SAP NetWeaver and with a pilot customer. Also here the feedback has been very good.

So the conclusion is a high confidence on the customer side. The very fast feedback cycle in a dialog is a strong advantage. A typical sentence is "This is the model we want.".

Beside the new SAP integration the concept of explorative modling using Smalltalk as the modeling language can be a door opener for new Smalltalk projects. While it is only used as a modeling tool customers don't have to be afraid of a new unknown technology. It is strongly seperated. But when he recognizes how fast developing the right thing with Smalltalk is, he'll possibly takes a deeper look. And, when SAP uses it, it can't be so bad. *smile*

OOP 2007 - VisualWaf in the VisualWorks repository

I've had interesting talks with Georg Heeg and Andreas Tönne today. Topics have been their project with SAP - I'll write about it below - and the AMD fab. Their control software for the chip fabrication in Dresden is based on VisualWorks. Here processes are developed and maintained in Smalltalk after they have grown too large to handle them with a visual modelation tool. The software controls the workflow communicating to the ERP and the roboters with different kind of adapters. So it's allready a very special kind of EAI/SOA.

Georg Heeg also told me that they will publish their VisualWaf framework for web applications in the Cincom repository when VisualWorks 7.5 will be released. It will be free for non-commercial usage. Andreas Tönne showed me how it works. It is more traditional than Seaside allowing to use SSPs for the presentation. But it is also possible to generate HTML programmaticly. VisualWaf is also more desciptive than Seaside. The developer has very much control about many aspects how the application behaves, which flows are possible and how it reacts on illegal calls. Additionally it supports I18N. So I'll take a look at it to get a better understanding.

OOP 2007 - Requirements engineering and contracts

The track of Chris Rupp covered the influence of the requirements engineering on contracts. She pointed out that there often are communication problems between customers and developers. So a good formalized requirements documentation is not enough. It only helps to do things right but not to do the right things. Both, customer and developer, have to find the same wording and need knowledge of each others domain. Also there are requirements that are subliminal to the customer. So contracts which allow to specify requirements during the realization are needed. To get an individual method for each project she presented RCDA which stands for require, commit, deliver, and accept. Require and accept artefacts are delivered from the customer to the contractor, commit and deliver artefacts from the contractor to the customer. The exchanged artefacts for each step have to be clearly defined in the contract. Different ways are possible, e.g. strict of fluffly requirements in the request and according to that a detailed or simple commit.

So the contract is very important, but not everything. And there are no perfect requirements. There are many concerns which have to be controlled by both involved parties to let them not be controlled by those concerns.

OOP 2007 - Type indicators the satiric way

The keynote of Gunter Dueck today has been great fun. Based on a typification of nerds, managers and salesman he refered about the appropriate breeding of techies. His self-reflection and observations hit the nail on the head. Basic idea is that techies think with the right half of the brain, managers with the left one and salesman with the stomach. *smile* So they all have different kinds of thinking patterns and levels of recognition. It's no wonder that they often aren't able to communicate with each other. It's difficult to describe how Gunter Dueck writes and talks about it, it is an intelligent but also philosophical and satirical. E.g. he pointed out that managers are only able to handle three types of data structures: lists, tables and org charts. *smile*

Currently I've got two books of him, "Wild Duck" and "Lean Brain Management". And I know I'll definitely buy more.

OOP 2007 - How to get an agile contract?

Clients for software projects should mostly be interested in the realization of their business requirements for a fair price. Agile processes try to achieve that working with strong communication with the customer and re-priorization of the requirements with each timeboxed iteration. But often project contracts are fixed-priced with an also fixed set of requirements that are seldom complete enough to build the system right. This is only suitable for products with only few changes over the lifecycle. To achieve an advantage for individual software which may change often and is very important for the business model the process needs to be more flexible. So one idea is a master contract with sub-contracts for each iteration, or a regular contract and many change requests. Both have many disadvantages. So a different model could be a kind of maintenance contract. This is an existing construct which only needs few modificationes and has almost no bureaucratic overhead. But also here it will be difficult to convince the client. I'll think a bit more about this idea.

OOP 2007 - SOA is a paradigm, no technology

Major part today have been three tracks about SOA. All three pointed out that SOA is no technology. It is a paradigm for scalability, flexibility, and fault tolerance. Services are lose coupled and have different owners. It is a long-term journey to establish a service-oriented architecture, starting with small projects, and needing full management support. A central team has to control the services without acting as a bottleneck. There are many more aspects, I'll cover them in future.

But there have been two interesting issues for me: The first is the discussion of CORBA against SOAP as the transportation protocol. CORBA doesn't seem to be dead, even if the WS* hype gives the impression. But for many people XML often seems too bloated. This is no statement against XML, but it has to be used the right way. Also SOAP is stateless what is a big minus for many people. The advantage on the other hand are technologies like XSLT for transformation or XPath for navigation inside an XML based message. Also XML schema provides constraints so that the data can be validated automaticly. But even if these are strong arguments I'm more pro CORBA, I don't know why. *smile*

The second issue are the different opinions about a common data model between all the services. It enables a simple communication if it is defined for a specific application domain and all involved services support it. But this standardization is also the big problem. It is really difficult to define those common structures if the ownership of the services is distributed. So the other opinion is to use only very simple data types, if possible no structures, try to keep the services generic and use mappings and special document schemas for the transportation between two partners. I'm currently evaluating the first idea. We'll see how it work.

OOP 2007 - How software as a service changes everything

I arrived at the conference in the late afternoon. After checking in I looked around a bit and then took part in my first nightschool. It has been "How Software as a Service Changes Everything" by Brian Behlendorf of CollabNet. Based on their experiences he described how the business model of SaaS works, what to consider and where he sees it in four years. He has a very wide idea of what services are. So it's a kind of enhanced outsourcing what he describes. But when speaking about their own products it is the collaboration suite based on SVN and surrounded with web applications, e.g. for issue tracking. Especially those closed systems are very suitable. Together with the idea of providing every functionality also as an API service, e.g. a web service, could be a good base for service-oriented applications developed and maintained by the customer.

OOP 2007 reporting

This afternoon I'll depart to the OOP 2007 in Munich. I really look forward to it. The interesting tracks, high skilled speakes, friends and last but not least the Smalltalk evening by Cincom and Georg Heeg. You'll read about it here, so stay tuned.

Parallels between basketball and software development

Yesterday we've been at the German major basketball league game of our EWE Baskets Oldenburg against the TBB Trier. It has been a very good match, Oldenburg has been on rank 10, Trier on rank 9, both fighting for a place in the playoffs. We won with 99 to 61 and are now on rank 9.

What makes this so interesting is the fact that Oldenburg started this season with an almost completely new team of the youngest players. So they've lost a lot of games in the beginning. But the coach - Don Beck - and his staff managed it to build a great new team, very committed and with a clear goal.

Thinking about it today I found that there are many paralles in leading a sports team and leading a team of software developers to success. You need to build a team, give them a clear vision and heading, improve their abilities with training, show them to choose the right way on their own, learn to live with setbacks, find new ways when the situation is changing, and don't lose the faith into the own possibilites over a long period. And there is is much more. So if one compares all those aspects he will find some similarities which he can adapt and use in his own projects. They are patterns.

So I'm now planning to browse my experience - and other information sources - and collect a set of process patterns here.

The eBay architecture

In a presentation at the SD Forum 2006 Randy Shoup and Dan Pritchett showed interesting details about the eBay architecture. They demonstrated how the requirements in site stability, feature velocity, performance, and cost changed from the beginning in 1995 to now with about 212 million registered users and 26 billion SQL executions per day. *wow* A really impressing and thrilling paper. You'll find it following the related link below.

TDD helps developing the ODBMS

As our ODBMS approaches the beta status I've found the memory footprint on disk is still relative high. The reasons have been very simple:

• the object identifiers have been GUIDs, which are very long,
• the full qualified type have been stored with each instance and
• technical timestamps have been stored in a human readable format.

So the solutions seems realy simple: change that. *smile* And it has been done in just five net hours.

To do this I've decided to change the root name management into a common database control that additionally generates individual object identifiers and provides a registry for the persisted classes. It has to realize a storrage mechanism which should work like the stores. Everything has to be integrated into the transaction class, the analyzer, the file I/O utility, the base file I/O strategy, the entities and the value holder.

What has helped me to do these changes are the powerful Smalltalk development environment and the fact that I'm doing TDD.

The Smalltalk environment with the integrated refactoring browser helped to easily perform renamings, find senders and implementors, add almost similar new methods through editing an existing one and submit it with a new name (as an intermediate step without breaking implemented behaviour), starting the unit tests, switch direct into the debugger for failed tests and to change the code immediately in the debugger. Together with the very simple language and the missing overhead of static typing everything has been done very fluently.

As allready said above I'm doing TDD. Not the kind of writing tests first for each and everything. But with the time I devised a good feeling for a very practical approach of what to test. Those tests accompanied me and growed the whole development time of the Tideland SOS. Without them many design changes - like above - or refactorings would have been much harder.

Both together, Smalltalk and TDD, are a very strong pair.

OK, the new blog is installed

I've decided to use tDiary as it is a lightweight system, easy to install in Debian, with no database backend and using ruby. This all sounds really good. Now I'll try a bit how to use it and how to make it fit a bit more into the Tideland look and feel and then I'll start to tell you more about my ideas and opinions around software development.