Frank Schophuizen's blog

How to plan software as a configuration item

2010-01-06T07:29:00.004+01:00

Yesterday I got a question from a colleague about configuration items. In our projects we use a deliverable list to identify which items are being delivered by the project and which are being received from outside the project. To help projects plan their configuration items we have defined a deliverable list template.

The deliverable list template lists documents like various types of requirement specs, design specs, test specs, manuals, training materials, etcetera. It also contains an single entry for Software. Now the question was:

What software deliverables (and receivables) should a project plan for?

Obviously, the deliverable list template does not give much clues. But we know that the software consist of components, some of which are received from other projects or third party suppliers - and possibly modified by the project - and some of which are created by the project. Then, how do you know which software deliverables the project is going to deliver?

The answer is that it depends on the agreement with the customer of the project. The requirements agreed with the customer state what he will get, in terms of functionality, performance, quality and deliverables. And these deliverables should be listed in the deliverable list. If the requirements don't state the (software) deliverables, then apparently the customer does not care as a long as the functional and non-functional requirements are satisfied.
In that case, the architecture or high level design determines the software deliverables. Even more, the architecture determine which of the software components are reused from other projects or third party suppliers and which are created anew.

Okay, now that requirements and architecture/design define which software deliverables and receivables are applicable,

how do we plan in which release they are delivered?

For projects with a single (final) release, it is simple: everything is released and delivered at the end. For projects with multiple releases, like incremental development or iterative development, it is more complicated but still quite simple.

The total work of a project is divided in "work packages", chunks of work that deliver a number of (possibly internal) deliverables. These work packages are assigned to a release and this way it is determined that the deliverables of those work packages are delivered at that release. More precisely, the deliverables are packed together as a baseline and the baseline is released.

Now in many software development organizations, the work packages are handled just like problem reports and change requests. They are registered in the change control tool/database, and assigned to people and releases (or iterations). We could call them "work items"; the list of work items planned for a release or iteration (in a release plan or iteration plan) determines which software deliverables are released. You could list those deliverables in the deliverable list, but it is more practical and more accurate to generate a report from the change control database listing the work packages, problem reports and change requests assigned to a particular release or iteration.

SCM tools are not configuration management tools

2009-06-08T19:16:00.006+02:00

The main reason why most so-called SCM tools are not really SCM tools is because they don't support managing software configurations. Making software is more than writing source code and converting them into executable code and data models for databases. A real SCM tool would be able to capture everything that is important for deploying and maintaining the software. This includes requirements, designs, models, sources, tools, infrastructure, knowledge, skills, test scripts, test data, manuals, scripts and other information.

Most SCM tools are able to capture files in a structure and control changes to the files and the structure. New files and new versions of existing files are all merely new files. Typically, the structure is 3-dimensional:

Directory (or folders) structure
Version (or revision) structure
Branching structure

The directory structure may seem to be a 2-dimensional structure (i.e. nested directories and directory next to eachother at the same nesting level), but if we consider the pathname + filename as the single identifier for a file, then the directory may be considered as 1-dimensional. The version structure is 1-dimensional: the successive versions supersede their predecessors. How about parallel versions? Parallel versions are partial contributions to a single succesor version. The actual successor is a merge of these partial contributions. Branches look similar to parallel versions, but the essential difference is that parallel versions are partial contributions to a single successor while branches are full contributions (version structures) to alternative successors.

If we look at the implementation of these dimensions, then the most simple implementation is 1-dimensional: all 3 dimensions are projected onto the same implementation, e.g. as directory structure (or path+filename). The "version control tool" could be an ordinary file system. For example:

main/gui/generic/foo-v1.c
main/webgui/unix/foo-v1.c
main/webgui/unix/foo-v2.c
main/webgui/unix/foo-v3.c
main/webgui/winxp/foo-v1.c
main/webgui/winxp/foo-v2.c
R1.0.0.0/gui/generic/foo-v1.c
R1.0.0.0/webgui/unix/foo-v2.c
R1.0.0.0/webgui/winxp/foo-v2.c

The problem with this version control system is that path+filenames changes for every new version. So users and the build process have to do more work to figure out which version they should us.

The next better implemention would be a 2-dimensional implementation: directory and branching are combined into a single dimension (path+filename), and versioning is the other dimension. Simple version control tools like Subversion works this way. For example:

main/gui/generic/foo.c (versions: 1)
main/webgui/unix/foo.c (versions: 1, 2 and 3)
main/webgui/winxp/foo.c (versions: 1 and 2)
R1.0.0.0/gui/generic/foo.c (versions: 1)
R1.0.0.0/webgui/unix/foo.c (versions: 2)
R1.0.0.0/webgui/winxp/foo.c (versions: 2)

Advantage is that the path+filename remains the same for all versions within a branch. But for different branches, the path+filename is different. And since directories and branches are resolved in the same dimension (the path), it is not possible to distinguish between a directory and a branch. For example, are main and R1.0.0.0 different branches? Are unix and winxp different branches? Are gui and webgui different branches? Or are they different directories within the same branch? So users have to make agreements about naming conventions to distinguish between branches. The SCM tool only takes care of deciding (automated) which version is used.

One step further is a 3-dimensional solution, where directory (path+filename), version and branch are independent of each other. More advanced version control tools like ClearCase or Synergy are needed. For example:

gui/foo.c (versions: 1 on branch: main)
webgui/foo.c (versions: 1 and on branch: main; versions: 2 and 3 on branch: unix; versions: 2 on branch winxp)

Advantage is now that the path+filename remains the same for all versions and all branches. This simplifies the implementation of an automated build process and the description in design documents and models. But the counterside is that SCM has to have the information to decide which branch a user is working on in order to select the correct version for the user to work on. And the user may be unaware of the branch he is working on - introducing the risk that he is working on the wrong branch.
So on one side SCM makes life easier for the user and the organization (e.g. automation), but on the other side it introduces extra work to reduce the risk mistakes or to repair them.

As you can see, I have left out the baseline (R1.0.0.0) from the last example. In the first and second example (1 and 2 dimensional), the baseline was combined with the directory dimension. In the last example, the baseline could be combined with the branch dimension, but it could also be implemented as a 4th dimension: labeling or tagging.

And this brings me to the point where version control enters the domain of configuration management. An essential feature of configuration management is to identify dependencies. A dependency defines which objects belong together. There are many different dependencies that can be (or need to be) identified, for example:

Directory dependency: all files within the same directory tree
Branch dependency: all files on the same branch
Version dependency: all latest versions
Status dependency: all files with the same status (e.g. release R1.0.0.0)
Content dependency: all files with compatible content (e.g. requirements-design-code consistency)

The status dependency is typically modeled in a so-called promotion model. All files go through a predefined series of statuses, and files (versions) with similar status and context (e.g. branches, directories) belong together as a configuration. These statuses are for exampe: working, integration testing, system testing, released. Tools support promotion by branching (e.g. ClearCase/UCM by deliver and rebase, or Subversion by "smart" copying of directories called branching) or by selection rules (e.g. Synergy by reconfigure property templates).

But one of the biggest shortcomings in SCM tools that I know is the absense of support for content dependencies. How do you identify the impact of the change of the design on code, requirements and tests? How do you identify the impact of code changes on other code, interfaces, design models? How to maintain the content information efficiently? How to you know that the content dependency is compromised? How do you know that release 3.2 of product X does work with release 1.2 of the framework, but not with release 1.1 of the framework? How do you know that release 6.1 of product Y cannot work with product X because it does not work with framework 1.2?

Another big shortcoming of SCM tools is that they only support control on file level. They don't control requirements, components in the design model, test cases in a test specification, tool versions (e.g. compilers, IDEs, webservices), hardware versions (e.g. 32-bit architecture). Consequently, many organizations try to capture those items in files, e.g. by creating a requirement specification document that "baselines" a set of requirements. But then again, those individual requirements - although versioned in a requirement management tool - cannot be identified as separate objects in the SCM tool, let alone that dependencies on requirements level can be identified or that individual requirements can be identified to a baseline.

The only solution that I am aware of that comes close to an "SCM tool" is the Jazz platform, starting the Rational Team Concert, but integrated with the requirements, test and project management applications. Since all information is stored in a composite repository, where information objects are actually identified as objects (not as files), it becomes possible to identify relationships (such as dependencies) between objects (not only files). Yet, I doubt whether it will be capable of identifying dependencies between configurations, e.g. content dependencies between software packages.

Rational ClearCase is not an SCM tool

2009-06-08T18:53:00.002+02:00

If Telelogic Synergy is not an SCM tool and Subversion is not an SCM tool, it is easy to conclude that IBM Rational ClearCase is not an SCM tool either. Not even ClearCase/UCM is an SCM tool.

Telelogic Synergy is not an SCM tool

2009-04-04T23:09:00.003+02:00

In Januari I talked about Subversion being not an SCM tool. Now let's have a look at Telelogic Synergy, which has been acquired by IBM recently. Until recently, I did not have much practical experience with Synergy and most of it slipped away. Now, I am working with it quite intensively and I came to hate and love it.

So let me explain why I think Synergy is not an SCM tool either.

Promotion model
Since the introduction of the task-based, more or less as a replacement of the ancient object-based approach, Synergy has adopted the approach of change sets. Tasks are actually change sets.

In Synergy you can define almost any configuration regardless of how, where or when the objects are changed. There are a few predefined change models, e.g. Collaborative Development and Insulated Development. The difference is that with Collaborative Development all completed tasks come available to other developers, while with Insulated Development tasks are promoted manually by the build manager.

Using queries on the database you can define almost any configuration. Through (semi-)automatically updates of the configurations, objects are "promoted" to the configuration. So for this Synergy qualifies as an SCM tool.

Real baselines
With the introduction of Rapid Baselining, you can freeze a configuration of multiple components and subcomponents instantly. The resulting configuration are immutable.

So again, Synergy qualifies as an SCM tool.

No projects, teams and streams
Synergy structures a database into (what Synergy calls) projects. In fact these are not projects, but components that can be developed and released independently of eachother, of hierarchically if you wish. Calling them "projects" is misleading because they do not constitute an enterprise for an goal within an agreed timeframe, using a set of resources. Moreover, you cannot even assign people to a project (only to a database) or define a particular scope to a project.

Synergy does not know the concept of teams, or roles assigned to people in a project. It does define "roles" to assign tool privileges, but no roles in the sense of a project (e.g. project leader, librarian, developer, tester, release manager, etcetera).

It may sound strange, but Synergy does not know the concept of streams. You can create parallel configurations (called "parallel projects") and parallel versions, but the concept of "a flow of changes" (like a river meandering through woods and valleys) is missing. Configurations are more like cities (being somewhere, changing constantly but going nowhere) than like rivers (changing constantly and moving constantly). You can define concepts that look like branches or streams using the release value, purpose and platform, but they remain configurations not streams.
Even worse, Synergy is quite "parallel intolerant". There is no distinction between checking out the same version twice (with the same release/purpose/platform value) and checking out versions in completely different projects (with different release/purpose/platform value. Why would you be need to be warned that someone in another project is changing the same object as you are? I can understand why you need a warning if it happens within your own project team.

Change sets
As a wrote above, tasks (or change sets) are in the core of Synergy. It's more powerful and more comprehensively implemented than any other tool I know.

Components
At first sight, the so-called projects may be considered as components. However, since Synergy tries to be "smart" in selecting sub-project versions (or sub-component versions) there is a clash between using baselines of released components and using a development configuration of a sub-project/sub-component. Due to this smartness, Synergy sometimes selects the "wrong" configuration.

No roles
Yes, Synergy does define roles but only to distinquish between different tool privileges (e.g. developer, build_mgr, ccm_admin). Roles to separate responsibilities and authority, for supporting promotion models and release management are absent.
Although... you can define a change promotion model in Change Synergy that grants authority to promote requests. So in Change Synergy (control of requests) roles can be defined but in CM Synergy (control of configurations) you cannot.

Although some things can be customized, Synergy does not quality for SCM tool here.

Limited branching
Some branching can be implemented using release, purpose and platform, but it is rather a way to distinguish between different configuration than between different branches. Also, Synergy supports parallel versions but it is hardly sufficient to call it branching.

Conclusion
Taking all the pros and cons into account we can conclude that Synergy is a very powerful tool and it comes close to a SCM tool. Yet, it lacks several important concepts.

Subversion is not an SCM tool

2009-01-30T20:07:00.002+01:00

Subversion (SVN) is not a Software Configuration Management (SCM) tool. It is a Version Control tool. Basically, Subversion is nothing more than a versioned directory tree with a few version control features.

Let me try to explain why I think that Subversion is not an SCM tool.

No real promotion model
First think that is missing from SVN, and many other version control tools, is the ability to support only the most basic promotion model: promotion of changes from your private work area to the branch in the repository, and vice versa.
A real promotion model would allow you to promote between various areas as defined for your organization. For example:

Private work area
Private system build area
Team integration area (also called the "stream")
Build area (often running a continuous build)
Test area
Release area
Staging area

In a real SCM system, you can define these kind of area and the rules (criteria) to promote between them. In SVN you cannot. What you can do is use branches - which are actually just a copy of a directory - and create a script or application to automate it (or do it manually).

No real baselines
A baseline is a reproducible configuration that is immutable (you cannot change it anymore). SVN does offer "tagging" but in fact it is creating a branch - which is a directory copy. The tag/branch is reproducible, but it is not immutable! You can still check out and check in on it, which is the normal way of making changes. Again, there may be workarounds, e.g. to remove write access for all users on the tag or by writing a pre-action hook that prevents check out.

No projects, teams or streams
Many software development organizations run more than one project at the same time, and/or have projects consisting of teams that work simultaneously. Projects will make baselines and teams will deliver to other teams. In SVN you cannot define integration areas (aka streams) for different projects or teams that are isolated from each other.
Again, we could use branches as a workaround; project-branches result in project-tags and team-branches are integrated (merged) with other team-branches and ultimately with the project-branch.

No change sets
Here is something you may disagree with. In SVN you can submit your changes in the work area to the repository. SVN does not create a change set for it, but it creates a new revision of the (whole!) respository. Of course, the new revision will be equal to the previous revision except for the changes you submit, but still SVN does not make a change set out of it. Nevertheless, you might argue that the submitted changes form a unity, which could be called a "change set".
The problem is however, that you submit all changes from your work area as a single change set, while in fact you may have been solving a problem report and implemented a new feature. If you want to identify the solution for the problem report (i.e. the change set corresponding to it) you are unable to do that.
A real SCM system is able to identify change sets related to units that are identified as managed items (e.g. work items, problem reports, change requests, requirements). Using a diff between revisions might be solution, but if branches are used to separate different areas, projects, teams and streams, the sequence of revisions in SVN or not so obvious. And again, adding a script to automate the selection of revisions to compare it adding an SCM feature that SVN is missing.

No roles
An SCM system is supposed to support an SCM process. One of the characteristics of an SCM process is that people can have different roles. Depending on the role, the process is different and with it the SCM tool behaviour is different. For example, a project leader is authorized to assign roles and the scope of control of a particular team or individual, but only for the project he is responsible for. These roles assigned privileges to the members of the teams.
SVN is able to assign read/write access to users at path level, but offers no means for roles like project manager, integrator, librarian, build master, developer, etcetera. Of course, you can implement this by hooks and scripts, but again you are extending SVN with SCM features that SVN lacks.

SVN does offer branching
Branching means that from a certain configuration (or revision in SVN) you create two - or more - parallel configurations. Typically, branching is intended to update a configuration from the past that cannot be implement in the current configuration (aka trunk, main, latest), for example a patch of a baseline. This is something that may be considered an SCM feature, which is supported by SVN.

Finally, SVN offers branching as one of the few SCM features. But reading back, I notice that many lacking SCM features can be resolved by applying branches for different purposes. If you are going to use the same technical solution to solve conceptually different SCM features, it will be quite difficult to distinguish between them: is the directory a promotion area, a project, a team, a stream, a baseline, a product, a component or module, just a parent directory to cluster projects, teams, streams, baselines, products, components, modules or just a leaf directory to cluster a number of files?
An SCM tool is supposed to help you implement an SCM process and a structure in the database. SVN only offers a versioned directory storage system. It's not an SCM tool.

Getting Things Done (GTD) made simple

2008-10-17T08:05:00.002+02:00

For many years I have been looking for Getting Things Done (GTD) in a simple way. And now I have found one:

Monkey GTD at http://monkeygtd.tiddlyspot.com

It's a TiddlyWiki file with a very simple, very sparse user interface, yet extremely powerful and versatile. No wasted screen space, just plain and simple look-and-feel. Since it is a TiddlyWiki, it comes as a single (html) file, requires no installation except a browser supporting javascript. It works perfectly with Firefox.

You can create actions, ticklers and references. Actions are set next, waiting or future, ticklers are connected to a date at which they will appear on the dashboard, and references are just entries with no timing constraint. Each can be connected to a contactperson, a project, an area (e.g. a department), a context (i.e. a category) or a realm (e.g work, personal), and it shows and updates cross-relationships on-the fly. For example, if an action is connected to a person and a project, you will see the action from the person and from the project, but also from the area that the project is associated with.
Each of the entries are just tiddlers, with some additional features. A tiddler is a wiki-page in TiddlyWiki. This means that you can add (formatted) text, or change the title or other settings. And of course you can make ordinary tiddlers.

I also use it to first define an action (e.g. "Schedule meeting with Joe about CruiseControl"), then add my meeting notes (preparation notes and discussion notes) to it and finally change the action into a reference (e.g. "CruiseControl") or into a contactperson (e.g. "Joe Plummer"). This way I build up my own wikipedia, while also supporting GTD.

If you don't know TiddlyWiki, you definitely need to take a look since it is the simplest wiki in the world, yet extremely powerful and extended by macros and plugins.

Rational Team Concert and the future of ClearCase/UCM

2008-09-27T16:24:00.009+02:00

Now IBM Rational Team Concert (RTC) supports Software Configuration Management (SCM) and build management, I am wondering how this would affect the future of ClearCase and UCM. Will it replace ClearCase? Will it complement ClearCase? Will RTC only be for small organizations, just like UCM started?

Number of users

Currently RTC is suited for no more than 250 users. This number is significantly lower than the maximum number of users that ClearCase/UCM can deal with. But how will this change in the future.
The Team Concert application may be technically improved to support more than 250 users. However, RTC is particularly suited for Agile developments and in my opinion a team of 250 users is about the maximum for an Agile project. A team in SCRUM should not exceed 10 people because stand-up meetings will take too long and people are not made to listen and remember the daily stories of more than 10 people. Having a SCRUM-of-SCRUMs of 10 people means that you cannot bundle more than 10 teams of 10 people, which makes 100 people.
Give or take a little larger teams, or smaller teams and 3-level SCRUM, I cannot image to exceed 250 people significantly.

RTC replacing ClearCase/UCM and Telelogic?

IBM now supports 3 SCM solutions: Rational ClearCase, Rational Team Concert and Telelogic Synergy. Given the number of users, RTC cannot replace ClearCase.
The most obvious direction is to use ClearCase or Synergy as the enterprise backbone for SCM data. All major deliveries (e.g. major milestones, releases) will be kept by the ClearCase database. RTC will then become the user's front-end to SCM.

The way this is going to work is through the connectors of RTC. RTC will combine SCM, build management and work item management, which more or less bundles the management of activities and their results. The data is kept in a RTC repository, the Jazz Team Server, using a rich data model; more rich than ClearCase or Synergy needs. Through the connectors, the rich data is synchronized with the enterprise SCM backbone (ClearCase / Synergy).

The RTC repository (Jazz Team Server) will contain only the data that is needed for the project, no more, no less. The project is started by extracting (through the connector) the needed data from ClearCase/UCM. Since UCM supports streams and baselines similar the RTC, there is an easy match to the new project's stream definition, especially if the new project is a successor of an old project that delivered the data from RTC to ClearCase/UCM in the first place.
When the project is run it is synchronized with the ClearCase/UCM backbone system through the connector, at the events as defined for the company (e.g. hourly).
And finally, when the project ends the RTC environment is synced with ClearCase/UCM and the RTC environment can be removed.

This way, RTC will become the high performance, high features, integrated project front-end while ClearCase (and other enterprise systems, e.g. a planning system, a financial system, HRM systems) become the enterprise backend system for all current and historical data.

ClearCase and the Jazz Team Server

If RTC is the project's front-end and ClearCase is the enterprise SCM back-end through the connectors, then integration with any other SCM tool has the same (dis)advantages as using ClearCase as back-end SCM system. So it will be a matter of time until the competition has developed connectors. How will Rational safeguard its competitive position with ClearCase then?

I have heard that RTC and ClearCase will be integrated more directly. ClearCase (and many other Rational tools) will move towards the Jazz Team Server as the data repository. Using the data model of Rational Team Concert, there will be a more efficient synchronization between RTC and ClearCase than through connectors. This will be a significant advantage to the competition. And the competition will not move to Jazz Team Server integration because that creates a too tight dependency on IBM Rational, so they will stick to the connectors. That's pretty smart of IBM Rational!

ClearCase and Eclipse

The ClearCase Remote Client (CCRC) is implemented on Eclipse, allowing it to run in a single user environment in coexistence with other applications on Eclipse. Through Eclipse, the need for platform dependent clients (Windows, Linux) is removed since Eclipse takes care of platform dependencies.
The native ClearCase clients will move towards Eclipse. In fact, the CCRC is going to be enriched with ClearCase functions, not only to enrich the remote client functionality but ultimately to replace the native ClearCase clients. In short, CCRC will become the one and only ClearCase client.

And through the integration of all Rational products in the Eclipse environment, these applications will not only look-and-feel integrated - even if they are just separate applications within the same environment - but they also can evolve into a truely integration environment. And this is precisely what is happening in the Rational Team Concert, where different functions (not necessary different applications) are integrated into a collaborating set.

Where does it all come together?

RTC is built upon Jazz to provide the collaboration functions (instant messaging, hyperlinking, dashboard creation, etcetera). Jazz is built upon Eclipse to provide the UI and platform independence. Jazz is also built on the Jazz Team Server to unify all data, and Team Concert defines a rich data model to unify different data models.
The connectors of RTC allow synchronization with back-end applications in a controlled manner, possibly foreign applications. They also allow existing Rational tools to be connected as "foreign" applications to eventually integrate with the Jazz Team Server to high performance, high functionality integration.
The Jazz Team Server serves as intelligent cache between the back-end and the front-end.

Will everything become a plug-in?

One of the most persisting problems of software development applications for customers is the integration of applications that are not integrated by the vendor. Through the concept of connectors, external applications will be able to integrate simply by developing their own connector. However, connectors are not able to extend the data model of RTC.

So yes, all applications will be able to become a "plug-in" and fade to be background of the user experience, but only if IBM Rational allows them to - or if another application vendor will make an Team Concert-like application.

Won't IBM Rational lose ground?

IBM Rational will be the conductor of the orchestra to determine the direction of the (Rational Team) Concert. If customers want full integration, they will depend on IBM.

In addition, IBM Rational will be able to develop applications more rapidly than the competition that integrates with RTC for a number of reasons. First, they will be determine how the data model will look like and they can mold the data model to optimize integration with Rational tools. Secondly, they are much earlier than the competition because they can make use of the extended data model before it is released to the market. Thirdly, they can better integrate with or without connectors because they have all the internals information available.

And finally, through the above mentioned advantages IBM Rational will be able to bring higher quality integrations to the market at an earlier stage than the competition. The counterside of it all will be: will the customer be willing to pay for it, or rather choose for later, less functional but significantly cheaper - possibly free - alternatives. If IBM Rational will be too expensive, it is likely that an open source alternative of Rational Team Concert will emerge (just like Linux as an alternative of UNIX).

Why SCM is not sexy, and SCM-ers are nerds

2008-09-22T14:41:00.010+02:00

Software development is inherently difficult. One of the reasons is that computers are inherently stupid and persistent in doing the same thing over and over again. Computers do exactly what they are told (programmed) to do, regardless of whether that is what you expect them to do. They are not human! To make computers do what you expect them to do, you need to be very meticulous and persisting in telling them what to do and how to do it.

Software configuration management is also inherently difficult. One of the reasons is that people are inherently clever and flexible in doing the things differently every time. People do what they think they must do, regardless of whether that is what you expect them to do. They are not computers! To make people do what you expect them to do, you need to be very convincing and careful in telling them what to do and how to do it.
Another reason is that software configuration management has a lot to do with computer systems, which are inherently stupid and persistent. You need to be very meticulous and persisting in telling them what to do and how to do it.

Try being meticulous and persisting in telling people what to do and the effect will be exactly opposite of what you might expect: resistance against your attempts to convince them of anything.

"computers cannot be convinced and people cannot be programmed"

A software configuration manager needs to be blessed with both talents to be really successful in SCM. But these skills are almost opposites, so the combination of both in a single person is rare.
Many SCM-ers like writing scripts, setting up and adjusting SCM tools and processes, performing software integrations and builds reporting results on websites and tuning systems performs and interactions with other systems. These SCM-ers are systems oriented, skilled with abstraction and logic. If they are good are likely to become the technical nerds of an organization.
Other SCM-ers like working with people, communicating, coaching, leading, defining strategies, giving trainings and presentations, coordinating the work in projects and process improvements. These SCM-ers are people oriented, skilled with social intelligence. If they are good they are likely to become the inspirator to bring the organization on a higher professional level. This group of SCM-ers is considerably smaller since they are likely to move on to other - more respected and better payed - jobs.
And finally, there is the extremely small group of SCM-ers with skills at both ends of the spectrum. They have a large interests in systems, structure, organization and tools, and at the same time a strong urge to inspire people, coach, guide and lead them.

Now if its true that the majority of the SCM-ers lack the necessary social skills to "sell" SCM and many people needing SCM lack the necessary technical skills to "buy" SCM (from these non-sellers), then its not so surprising that SCM is not seen as a popular profession.

Auditing is not a primary CM element

2008-07-31T11:16:00.001+02:00

We can distinguish two types of auditing in product development projects. Process auditing looks into the project to find evidence that the (agreed) processes have been followed. Data auditing looks into the project and product data to find evidence that the data is correct. In which category falls configuration auditing?

The configuration management activities follow a process. Compliance to the agreed CM processes can be audited. According to CMMI, the process quality assurance is a PPQA responsibility.

Configuration management controls configurations, which involves aspects like storage, distribution and retrieval, status and promotions, traceability of changes, visibility of dependencies, etcetera. Compliance to the agreed CM definitions (storage locations, distribution databases, data reference links and other metadata) can also be audited by CM. But if non-compliances are the result of process deviations, it may be more effective to audit the process (by PPQA).

And finally, the correct content of configurations must be assured. This can be audited, which is usually called a baseline audit. According to the NASA, a "baseline audit verifies that a configuration item, or a collection of configuration items that make up a baseline, conforms to the documentation that describes it" and should be done by CM. However it is part of product quality assurance and therefore the auditing should be the responsibility of PPQA.

How much does that leave for CM audit? Not much!
Therefore, there is no good reason to consider auditing a primary element of CM. Of course, CM people may and often will assist PPQA people with executing the audits, in particular to find evidence (e.g. configuration records and configuration items). In this respect I agree with Anne Mette Hass in her book Configuration Management Principles and Practices that auditing is not part of CM.

Identification is not a primary CM element

2008-07-30T08:56:00.008+02:00

Although it is generally accepted that Configuration Identification is a basic element of Configuration Management (CM), I don't agree that is should be. Why not?

The core of CM is control of configurations. To know what configurations we are controlling, we need to identify them. To avoid confusing one configuration for another, we need to uniquely identify them. Equal configurations should not be identified differently. As you see, CM is interested in unique identification, but how the identification looks like is not relevant, as long is it is a uniquely. Of course we need naming conventions, but how it looks like depends on the requirements for humans, automation or (CM) tools.
As such configuration identification is a secondary requirement for CM, not a primary element. The identification process does not even need to be part of the CM discipline, in which case CM is a user of identifiers, just like most other people in a project, but with a different purpose than other people.

Identification and naming conventions
An important implication is that when using a version control tool or a CM tool - I assume you understand the difference, but for now that's irrelevant - the unique identification may be left to the tool. This often results in unreadable object identifiers (e.g. 23987sg2b.38h830okdh34.8827481) but this is sufficient for CM. Even if you do CM by hand, you may just keep a list of sequential numbers.

In practice it is more convenient to have human-readable identifiers such as file names or document titles (or document identifiers) and/or to have identifiers that ease automation (scripting). Also it is often practical to put semantic (meta-)information in the identifier, such as a file type or a component identification. Because identification is not primary requirement for CM, the definition of naming conventions does not have to be a primary responsibility of CM people. You may document it in the configuration management plan (CMP), you may assist in the definition of a naming convention, your may be involved in auditing the compliance to the naming convention and if you are responsible for automation/scripting you may have their own naming requirements, but ultimately you shouldn't really care (as long as identification is unique).

Identification of everything?
Another reason for not considering identification as a basic element of CM is that not every identification should be the responsibility of CM. In principle, only the configurations that are under configuration control need to be identified for CM - note the different between "for CM" and "by CM". Some identifiers are an attribute value without identifying a configuration. Attribute values are for example enumerated values that are used on forms or documents, database identifiers (e.g. PRCR numbers) or just names (e.g. person names, product family names). In practice the distinction between an attribute value and a configuration is not always clear.

So what?
The reason that this is important is that CM is often held responsible for naming conventions and for identification. Commercial names are the responsibility of Marketing or Product Management. Identification of a certain technology used in the product is the responsibility of Engineering. Identification of production lots is a responsibility of Logistics. Not everything that has to do with identification should be considered a CM responsibility. In fact, CM is not really interested in identification as long as configurations can be controlled properly.

International Certified Configuration Manager

2008-01-06T08:37:00.000+01:00

The international Certified Configuration Manager association (iNTCCM) is founded in March 2006, with the objective of setting the standard for professionals in configuration management. Recently, I joined the iNTCCM association as a member.

How is hardware CM different from software CM

2007-12-09T22:21:00.000+01:00

The last few weeks I have been more involved in hardware CM, or more specifically hardware CM for IC (chip) development. The design process for a chip if very similar to the design process of software.
To design an analogue chip, you first make a model the electronic circuits using an modeling tool where you connect signal and power lines between standard components. This model goes into a simulator where you "test" your design. For a digital chip, modeling is even more similar to software development: you write code using a programming language. A code checker is then able to calculate the output bits based on the input bits. So in both cases, you create source files to describe the system behavior and you run a build to check the code or model, and generate files needed to feed the (chip) fab. The different between hardware (chips) and software is what happens with the build result.

So I would expect that CM for the design process of chips would be similar or even identical to the design process of software. Well, in my present experience it is not! CM for chip design is as we did it for software in the 80-ies of the previous century, which is 25 years ago. There is hardly any parallel development and the only controlled versions are the current versions (/main/latest) and the baselines (tagged versions).

From a software perspective, absence of parallel development is hard to imagine. How come that chip design can do without, and still develop multiple product variants at the same time? The answer is: reusing block designs. A chip consists of a combination of (more or less) standard blocks. These can be high level blocks (e.g. an ADC, or a Bluetooth controller) or low level blocks (e.g. a transistor, an amplifier or a FIFO). These blocks are used to compose a chip design. The challenge is to combine as many blocks as possible, on a chip as small as possible, with the best performance as possible (e.g. low noice levels, minimum power dissipation, largest temperature range, etc.). The cost of a chip is determined by the size, but the market value is determined by the functionality (maximum number of blocks) and the quality (best performance).
One of the biggest challenges of chip design is how to place and connect the blocks and get still get the chip within spec. This is a 3-D problem - because a chip consists of multiple layers - and almost all changes in the design has impact on the complete chip. Therefore, you cannot change one part of the chip in one team, which another team works on another part, and therefore there is not much parallel development.

Development of those reusable blocks (e.g. making a smaller ADC using less power and with better performance) is done separately from the chip development. These blocks are called IP blocks. The designers of an IP block don't really care about placement and connection of the block on the chip; they care about the internals of the block, making the design possible. The only reason they care about other blocks on the (test) chips is interference: for example, what is the effect if we place the ADC next to a power management block?
Since almost all changes within an IP block have impact on the whole block, there is little use to designing one part of the block in parallel with another part of the same block. And if that is feasible at all, it is more useful to make them separate IP blocks which can be used (and designed) independently.

Now let's go back to configuration management. We have seen that chip design and IP block design have little use for parallel development. So CM does not need branching or streaming. If there is a need for (for instance) product variants, it is easy enough to just design them as separate product types, reusing the ideas of one product type for the other one. It may even be sensible to design them sequentially where the first product type takes several months to design and the next one only a few weeks after it.
If we look at software development, we may notice that the use of standard blocks is not "common practice". Designing a software system involves (1) designing the software blocks and (2) integrating them into a system. So what chip design does in two separated processes (usually also separate projects), is combined in a software project. This is possible because in software you have infinitely more freedom in interconnecting "blocks" and infinitely higher speed of changing the characteristics of a blocks. If a software designer has a block that "almost" fits in a system, it is often cheaper to change to block itself than to change the system around it to make it fit. In a modular design changing the block internally has less impact on the whole system than changing the environment of the block. And therefore, software blocks are often developed in separate teams that work simultaneously, using a (more a less) fixed interconnection called the interface architecture. Variants of blocks can - and do - exist simultaneously within the same system, where at compile-time, link-time, install-time or run-time is it decided which variant of a block is actually used.

The simultaneous and concurrent existence and design of software blocks, and the dynamics of integrating those blocks into a system is so much more complex than for chip design, that it requires a lot more complex configuration management approach. The SCM approach requires parallel development in branches and streams, both on block level and system level. It also requires a lot more flexibility of dealing with integration scenarios, variants and circumstantial differences. And last but not least, chip designs require an (expensive) manufacturing process that is very expensive to change once it is established, while software is the final product after the build. Consequently, the dynamics of change in software systems is much higher then for chip designs.

In summary I would say that although the design processes for chip design and software design look very similar, the configuration management requirements are of completely different magnitudes.

CM Platform in the Netherlands

2007-10-31T07:21:00.000+01:00

In the Netherlands, there is a new configuration management initiative called CM Platform [no link to a website yet]. The initiators are from Thales and KPN. Although it is still in its early stages of exploration, there is a clear need for more and better collaboration and sharing of the configuration management knowledge.

Other initiatives in the Netherlands are:

Dutch Rational User Group (HRUG), initiated by Bosch Security Systems and TOPIC Embedded Systems
CM workshop organized by TOPIC Embedded Systems and Philips Applied Technologies

Software-as-a-Service (SaaS) for CM systems

2007-10-30T21:33:00.000+01:00

In a podcast on IBM developerWorks, Dave Michell explains about Software as a Service (Saas):

the customer does not take ownership of the software, but they're going to rent this solution in a subscription model, and it's delivered remotely. And that's very different from the ASP model. In the ASP model, or the application hosting model, what the customer is doing is they're buying the software.
[...]
In the Software as a Service model, again, the customer does not own the software. They subscribe to an offering and they buy that offering in a subscription model per user per month. So there's no software purchase to be made.

And the other key point here is in the Software as a Service model, the customer really has no say over what the infrastructure is. They don't get to decide what the hardware is or the middleware or the database — and more to the point, they don't really care.

So in the SaaS model, the customer says "I want to buy that application functionality. I'm willing to pay this much per user per month," usually is their typical model. "And the service-level agreement meets my needs. So I'm going to acquire that application that way."

Considering a configuration management system, such as ClearCase, many customers struggle with configuring the system for optimal performance, setting up and configuring servers, network and client parameters. In many cases, the users don't really care whether it is ClearCase, Synergy or Subversion behind the scenes, as long as that can do version control, baselining (or labeling or tagging), parallel development (or branching or streaming), delivery, rebasing, releasing, status promotion, structuring, setting attributes, and all the other CM stuff. Users don't care about sufficient licenses, disk space, replication across sites and other IT issues; they just want the system to be available and to work properly to their needs.

So, the CM system seems a perfect candidate to be deployed as Software as a Service. Even more, if the CM service is offered as a Web 2.0 application, the internet will be the platform allowing local and global accessibility.

If in addition there would be a standard set of CM service features, the CM back-end could be supported by just any CM vendor that complies with this standard. The front-end could even be of a different vendor or proprietary to the customer, e.g. as a dedicated integration with other systems. Customers could then focus more on the tool-vendor that suites best with their organizational and IT needs, and users could better focus on dealing with true configuration management issues, rather than being hampered by infrastructure and IT issues.

Why wouldn't a product like ClearCase be offered an SaaS model, if IBM is such a promotor of SaaS?

2007-10-27T09:04:00.000+02:00

There are many definitions of configuration management, most of them containing four basic elements: identification, control, status accounting and auditing. Although formally correct, the translation into practice is far from easy for many organizations. I wonder why this is...

Let's have a look at a car for a minute. From a user perspective, a car is a way of transportation from point A to point B. From a technical perspective, a car is an system where you can put people and luggage in and that allows a controlled way of acceleration, deceleration and steering. Given the technical view, there is no way to define that a car brings you from any particular point to another point.
Now let's go back to configuration management. In fact, identification, control, status accounting and auditing are the technical view on CM. But what is the user view on CM? Why do we need CM?

I think that the main and possibly only reason why we need CM is that we need to communicate and share. The effectiveness of communication depends on the integrity of the information we communicate and the effectiveness of sharing depends on the integrity of the objects we share (work products). If the information and work products would be static, a (simple) library or stocking system would be enough. But in practice the information and work products are not static; they are evolving in a planned way (if the planning is followed). The integrity (or validity) of the information and work products also constantly changes.

Now because the information and work products are constantly changing, we need some guidance in determining what is correct and what is not. That's why we need concepts like streaming or branching to facilitate parallel development, we need the concept of tagging, labeling or baselining to determine the status of a particular configuration, we need the concept of promotion to visualize the state of evolution.

Communication of information, sharing of work products, and assuring the integrity of the whole while it is constantly changing, is the main challenge of configuration management. Hopefully, it is easier to understand configuration management from this angle than from its formal definition.

Is CM about maximizing change or about minimizing change?

2007-10-12T22:04:00.000+02:00

"Not every change is an improvement, but an improvement is always a change"

Configuration management is about managing change, assuring the integrity of the business assets during their lifecycle. This implies that the work products of a project are protected against loss or damage. Every change is a risk of introducing bugs, damaging the existing functionality or degrading the system's performance. A good way to assure the integrity is to minimize the amount of change: if you don't change it, you can't break it.
This is precisely what a CCB (Change Control Board) is doing. Every change request is discussed and only when the business value of the change is high enough, the change is accepted for implementation. Other changes are rejected. Thus, the system will undergo minimum change and minimum risk of degradation. A positive side-effect is that this approach leads to minimizing costs and to minimizing time-to-market: if you don't change much, it does not cost must money or time.

On the other hand, especially in a consumer market of retail or professional products such as mobile phones, audio and video equipment, medical diagnostics and treatment systems, transportation or manufacturing, the competition is tough. The game here is to maximize the amount of functionality, to maximize the level of quality, but at the same time to minimize the costs and to minimize the time-to-market.

Now what should configuration management aim for: minimizing change or maximizing change?

Well, in fact the answer is quite simple: that's not up to configuration management. Regardless of the amount of change being high or low, configuration management should manage the work products and their changes, assuring their integrity. The decision to minimize or maximize change is a business decision. This may be different for different businesses, but also for different projects within the same business. It may even be different depending on the time of the year (e.g. Christmas season). But of course, the CM approach must be different in both cases, so it must be aware of the business situation.

This implies that there is no single best CM approach; there is no one-fits-all solution. To find a common solution, we need to focus on the one thing that both have in common: change will happen! Any change may be an improvement or a degradation (or both). We must avoid that changes that we don't want are slipping through to the customer, and we must assure that changes we do want are actually brought to the customer, with quality and in time.
This requires at least a proper level of visibility, which bring us to the four pillars of CM:

What changes do we want, and what changes don't we want? (Configuration identification)
What solutions do we have, and which ones don't we have? (Configuration control)
At what stage is every change? (Configuration Status Accounting)
Are we sure about that? (Configuration auditing)

The most important job of configuration management is to achieve a maximum speed for propagating desired changes, for instance storage when the change is available, promotion when the promotion criteria (e.g. quality criteria) are met, distribution to the teams for the next processing step (e.g. verification) and communication for visibility (e.g. to enable project monitoring and control). But at the same time configuration management is to detect undesired changes as soon as possible (preferably before someone is working on them), and stop the propagation of solutions of undesired changes when they slip through or when we change our minds about desired and undesired changes.

So it is always a balance between speed and control, between volume and quality, between maximizing and minimizing change. Moreover, it is a constantly change balance too, which makes the profession of Configuration Management a challenging and interesting one!

Our iceberg is melting

2007-10-07T18:54:00.000+02:00

Last week I was one of the speakers at the 4th CM workshop organized by TOPIC Embedded Systems and Philips Applied Technologies. I spoke about how Web 2.0 technology will have its (change) effect on configuration management. As a speaker, we received a nice presents, a book by John Kotter and Enter Rathgeber:

Our Iceberg is Melting

Most of you know how I hate reading books. So at first I forgot about the book, leaving it in my suitcase for over a week. Today I started reading it, and finishing it! And I love it!
It reminds me of the book Peopleware by DeMarco and Lister which I also read in a single breath, and loved. Peopleware and Our Iceberg is Melting are the only books I read in the last decade that I absolutely love - and finished.

Now you probably wonder what is so special about these books. Well, first of all you should read them yourself. Both books are about people, in case of the Iceberg in the form of a fable with penguins. I had no difficulty whatsoever to project the story on a real life situation at work and real people from work.
Quite often I encounter people like Fred, Alice, the Professor, Buddy and of course NoNo. Unfortunately, I hardly ever encounter talents like Louis, a respected senior manager who knows how to manage how to manage people.

Anyway, take a look at The Iceberg is Melting, it is worth it.

Lean configuration management

2007-10-04T21:01:00.000+02:00

Jens Norin has written een article about Lean configuration management. There is a lot that I disagree with, but it also gives a lot of things to think about.

CM certification - sense or nonsese

2007-09-27T07:05:00.000+02:00

During a Configuration Management workshop in Mierlo, a little town near Eindhoven in the Netherlands, I had an interesting discussion about CM certification. The concept of certification is simple: if you comply with an amount of selection criteria, you get your certificate.

The discussion was what the added value is of CM certification. In my view, the may be - at least - two reasons why you need certification:

The distinction between professional and amateurs is difficult to make
The industry is using certification as a selection method

Currently, there is no common, generally accepted, understanding of what a configuration manager is. So if a certification institute defines certain rules and criteria for certification, it is arbitrary. There will be lots of good CM-ers that will fail and bad CM-ers that will pass, depending on whether your knowledge and work experience complies with those criteria. The result will be that within the crowd of certified CM-ers there will be good and bad ones, and within the crowd of non-certified CM-ers too.
In addition, the community of CM-ers is a small world. Bad CM-ers are easy to pick, and if someone is completely unknown within the CM community, it might be a reason to some extra screening when he or she applies for an assignment as a configuration manager.

So my argument was that the added value of certification of individuals within the CM world is too small. This does not justify the investments to set up a certification institution, not does it justify the individual investments to get certified.

I think CM certification is nonsense. It is useless to strive for a certificate unless it clearly boosts my career if I do, or damage my career if I don't.

Some links:
Institute of Configuration Management
International Certified Configuration Manager

IBM developerWorks CM space and wiki

2007-07-11T23:06:00.000+02:00

Recently, I have created a Configuration Management space with an underlying Configuration Management wiki on IBM developerWorks. Initial focus will be on IBM products (ClearCase, ClearQuest and UCM) and on CM concepts and practices. Later, it is my intention to extend it to other CM products too. The space and wiki are an extension to the existing discussion forums on dW.

The content is still in its initial stages, so bear with me to let it grow. For that purpose I am still looking for co-editors who are willing to put more content to it. Although wiki's are intended for open collaboration, I want to be careful with making it completely open for modification to the world to assure proper structure and quality.

For new events or other news and changes on the CM space portal, feel free to contact me.

Collaboration technology is coming

2007-07-07T08:19:00.000+02:00

Recently, I attended the IBM Rational Software Development Conference (RSDC2007) in Orlando, Florida. Apart from the typical presentations about the products, there was a lot of attention for Organizationally Distributed Development, or Globally Distributed Development (GDD). ODD/GDD is about crossing the organizational boundaries, which many people find scary.

At the RSDC they showed a prototype of a product called Team Concert, a tool to support collaboration between people to build software. It is based on the Jazz technology, which is

Jazz is a joint project between IBM Rational and IBM Research to build a scalable, extensible team collaboration platform for seamlessly integrating tasks across the software lifecycle.

New and exciting is that the Team Concert product is developed as a commercial product in an open source manner - see the press annoucement. People from the global community can join in to the development team. Thus, the project is deploying the potential of the global community.

Another exiting thing is that the Team Concert is a collaboration product, creating full transparancy and integration of technical and control information. And since this is a collaboration project, they use (pre-released) versions of Team Concert to support the development (globally distributed). So they are using the product that they are making.

But this is not the only thing that illustrates that IBM is taking collaboration technology seriously. On IBM developerWorks they have introduced spaces and wikis, next to the discussion forums that have existed for many years. For company communication this is not new, but what is new is that they also allow non-IBM people from the user community to create a space. The Configuration Management space is the first one.

Coincidently, at NXP Semiconductors (formerly Philips Semiconductors) there is an initiative to create a Common Collaborative Core (C3), a set of applications (e.g. wikis, forums, website, IM) to support the - internal - community with collaboration, sharing and building knowledge and competence. NXP happens to be the customer that I am assigned to currently.

Apparently, both NXP and IBM recognize the same thing - unleash the power of the mass instead of trying to build competences with the (small) recruited crew.

Transparent collaboration across organizational and geographic boundaries is a necessity to survive the ever growing technological and organizational complexity.

Nightmare of component based development (4)

2007-05-21T23:47:00.000+02:00

It has been a while since I posted about the nightmare of component based development. But, I promised to revisit, so here is another one.

Component based development may be a blessing to some product developments, but it can also be a nightmare to others. In part 1, I discussed the problems of finding a stable baseline as a reference for new development when developing multiple components simultaneously. Part 2 discussed the issue of reducing scale which resulted in both early and late integration. Part 3 focussed on the issue of ownership when developing multiple incarnations of a component simultaneously.

As the title says, component based development can be a nightmare. Complexity of systems and products continuously increase, and functionality originally designed and marketed as separate products, is being integrated. For example a camera in a mobile phone, GSP tracking in car navigation systems, medical monitoring in watch integrated with cellular communication, and much more. What originally was designed as a product becomes a component within other products. Components may be split or merged into other components. And what originally was marketing by company A may becomes an integral part of a product line for company B.

Even though component based development may be a nightmare - if not done properly, the need for componentization and flexibility with components is growing. It seems unavoidable that some day we have to face the problems of component based development anyway, whether we want or not. And this day will probably be sooner than we may expect.

Trying to integrate different products and components, that were designed with different architectures, is a challenge by itself. If there is time to do it properly, we may come with a proper solution, a new architecture. But there is never enough time to do it properly, so we need a way to at least control it in a proper way. It may even become worse when the need for integrating existing products and components exceed the need for new functionality. That may lead to a completely different approach to systems design and may redefine the term "reengineering".

Now what can we do?
Well, we cannot make a chaos-beyond-control first and then hope for a generic solution to regain control over the chaos. We don't have time to do that because the competition will beat us in the meantime. it must be a controlled evolutionary path.
This means that configuration management will become more important to control product development, and it may well become the most important control discipline. It will not only control the work products (inputs, intermediate work products and outputs), but also strategic roadmaps information and the information and knowledge of the company that is required for product development. It will be too difficult and too extensive to oversee all information by a single person or even by a team of people.

The "art of integration" will be a combination of product architecture and configuration (and knowledge) management, and these two will become even inseparable and indistinguishable.
Configuration management may even become more an integration of product architecture and project architecture (or more general, the architecture of an organization and its processes).

Writing a book like developing software

2007-04-20T22:13:00.000+02:00

In the article Writing a book is like developing software, Roy Osherove compares writing a book with writing software. Now let's assume that we would write books like we develop software.

Most books are written by a single author. Take for instance The Lord of the Rings by J.R.R. Tolkien. Suppose we would take up the assignment to write a sequel of this bestseller, but develop it like a software product. Suppose some of the requirements are

It must appear on the market in English, Spanish and Russian simultaneously
It must appear before Christmas 2007
It must equal or exceed the success of the current books

Given the short timeframe and the limited available of talented and experienced writers (scarce resources), we decide to write the book in as multisite project. We set up and English team in the America, a Spanish team in Europe and a Russian team in Asia. Given the global distribution, we can work round the clock.
To reduce intercontinental communication across timezones, we will assign different parts of the book to each team. Each team will write in its native language to assure the highest quality of writing. When one team finishes a part (or a preliminary version of it), it will be sent to the other teams for verification and translation.

The verification process will compare the story with the requirements. Which requirements? How do you make "exceed a previous success" SMART, if you cannot sell the book before finishing it? This is a job for marketing. They have to verify if the book will sell good enough.

We were talking about assigning parts to different teams. Which parts? If we divide the book into chapters, we can assign a chapter to a team. Which chapters will we have if we don't have the story yet? But the story is to-be-developed by the team. To divide into chapters we need the overall plot, in abstract form. But, who is responsible for the overall plot?

Okay, division into chapters seems to be a bad idea. Let's divide into characters (persons in the story), and assign different characters to each team. May be the cultural background of each team may even be an advantage for writing and for the overall result. But how can you write a story of characters in separate teams, if there is not plot that connects those characters? Characters need to interact in the story. Furthermore, different teams will be writing simultaneously on the same part of the story. So we need to integrate parallel updates, and we need to review the different story elements before integrating them.

Another issue is that during the story, we build up a history. If for example two characters meet in the beginning of the book and become friends, they cannot be complete strangers and enemies lateron.

Sigh! We need a story architecture that defines the development of characters and the development of time (history) across the whole book. It also defines the characteristics of the characters, the landscapes they visit, timing constraints (e.g. you cannot be at two different places in the same timeframe).

And we need configuration management to assure that the correct versions are reviewed, verified and translated. Especially translation is a dangerous one: if you translate an old Spanish section to Russian, the English and Spanish teams will not discover it because they cannot read Russian, except the people who translate from Russian. But why would a Spanish translator be bothered with reading a section that was originally in Spanish? So, CM must assure correct version and status handling.

I can go on and on, but probably you have lost faith that a book written this way will (1) be ready before Christmas 2007 and (2) exceed the success of The Lord of Rings. Yet, many companies develop their (software) products in multisite projects, with teams in America (US, Canada), Europe (UK, France, Germany, the Netherlands), Asia (India, China, Singapore), and without proper configuration management - except branched version storage and multisite replication.

Is multisite book-writing a good idea? And multisite software development?

Kathy Sierra blog - excellent!

2007-04-02T22:35:00.000+02:00

The blog of Kathy Sierra is really a recommended read when you want to get excellent insights in user community building and how this influences user's experience and perspectives.

For example, her blog entry about ultra-fast change explains how extremely frequent updates (of a product or service) help create user satisfaction because the user doesn't even get enough time to get upset about a broken feature. Due to the fast pace of changes, the fix or rollback is already available before anyone gets really upset about it. That's an enormous reassurance to the users.

Another one I like is Creativity on Speed. It explains how the best creativity comes forward when people have the least time to be creative. She is not talking about unrealistic deadlines (which kills creativity) but about needing a solution and needing it quickly. Under this pressure, people tend to rely more on their intuition and other subconscious parts of the brain, rather than rationalizing and trying to link logically.

I haven't read all, and I don't like it all, but her blog struck me.

Deliverable planning and control

2007-03-30T22:40:00.000+02:00

For many people Configuration Management is little more than controlling the versioned storage of work products, sometimes extended with Change Control which is little more than controlling change requests and problem reports. But both boil down to something like an sophisticated database with a sophisticated tool, sometimes not even sophisticated.

But the real added value of Configuration Management is that it helps manage and control the project. Let's have a look of a project in general first. In short every project is an enterprise, a journey, to establish a particular result of a particular quality, within the limits of particular resource constraints (typically money, time, people, technology, methodology, etcetera).

Every project starts with planning. Planning the result means expressing the results in items that will be delivered - if the project is executed according to the plan. Those items need to be identified (Configuration Identification), controlled (Configuration Control) and must be of a certain quality level expressed by a status (Configuration Status Accounting). So the first order planning of - the result of - a project already involves configuration management.
Secondly, these resulting items don't fall out of the sky; they need to be developed. So every item will require at least one task in the planning that produces the item. Some tasks may even product multiple items, that's OK. But every task needs input. So there we have a second order of configuration items.
Thirdly, these second order items need to be produced also, or they are inputs to the project from an external source. These can be requirement definitions, architectural definitions or even complete subsystem implementations from another project or a previous project.

Anyway, project planning strongly involves configuration planning, which is a responsibility of configuration management. In other words, configuration management is part of project management, at least during planning.

After the planning has been built up, which involves a lot of other things to be planned as well, the project is executed according to the plan. The tasks are being executed and the (planned) items are being produced as the result of the tasks. Some items may be produced iteratively, thus producing multiple versions of it. Anyway, these items (i.e. the versions) are stored in the CM system and status is assigned to indicate the progress of the item (how far is it "ready"? which is a quality attribute) and the maturity (how good is it? which also is a quality attribute). But controlling the versions and their status - and even the status of integrated items, which is a different thing than the status of the individual parts. This is all Configuration Management, which contributes to the Project Monitoring and Control of the project.

All I am saying is that the deliverable planning and tracking processes are both part of Configuration Management and of Project Management. That's why we should not consider CM in terms of the tools, databases, licensing issues, disk or network performance issues, branching issues, access control, etc. Those issues are not configuration management, but they are IT systems management issues. Configuration management is a project management discipline that is concerned with managing the physical work products of the project.

Behind Closed Doors

2007-03-22T07:35:00.001+01:00

Although I don't really like reading books, I started in Behind Closed Doors of Johanna Rothman and Esther Derby. It really is not a book about management, but about working with people as a manager. Easy readable and for a slow reader as I am - especially with the distractions that I have while reading - my progress is reasonably fast.

The previous book I read so easily - and finished - is Peopleware by DeMarco, a classic in management books.

Both books are about people and working with people.

Update 15/3/2007:
I have read the second chapter. It certainly is not my favorite - in other words - I don't like it. It's about matching roles and people. It assumes an amount of freedom to mix and match that - at least in my work environment - seldom exists.

Update 18/3/2007:
The third chapter about building your team started familiar with jelling teams. I immediately felt the connection with Peopleware. It was convincing until the subject of feedback was touched. Especially ending the chapter with the option of firing someone ruins the whole atmosphere needed to build a team. Overall, I was left with a very disappointed feeling.

Update 13/4/2007:
The chapter about managing day by day was about setting personal goals. A great deal of the people I encounter, especially bosses, talk about setting personal goals. "Where do you want to be in 5 years time?" or "What do you want to have finished by then end of the week?" It is a clear chapter (for those people) and may be an eye-opener for many. But for me, living to a goal has always been a struggle. I'd rather be focussed to a direction and a vision, instead of a goal.

Update 14/4/2007:
The chapter about discovering lurking problems is not about discovering lurking problems. It's about discovering the difference between an individual problem (for an individual person or an individual team) or a group problem that exceeds the scope of control of the individual (person or team). It is well written, from a practical angle rather than the theory. I liked it very much, as it appeals to many situation I encounter in my work.

Update 14/4/2007:
Building capablities is the chapter I am still reading. This is one of my favorite chapters as it addresses the human side of management, such as trust and appreciation. I find it very interesting what makes people "tick" and how to really connect to people as individuals. I have not finished the chapter yet, but I think it may be the best chapter in the book.

Update 27/5/2007:
It's now one and a half months later than the previous update, and I finished the book. Looking back, I wasn't thrilled about it as I hoped I would be. The style did not grab me like Peopleware did, and the secrets are nothing more than common sense in dealing with people, as a manager. To me it's a no-buyer, but fortunately I got it for free.

Second Life, a hype

2007-03-16T19:57:00.000+01:00

I am reading a lot about Second Life lately. Various companies are looking into it as a way to promote their and show their new products, even to have them tried out, yet withou really understanding or even visioning the business value that it might bring. I wonder what they are really looking for.

IBM for instance is planning to have meetings, lectures and trainings in Second Life. Recently Grady Booch announced that his virtual self is giving a virtual lecture in the virtual world. But I don't see my virtual self sitting in a virtual classroom looking at and listening to a virtual speaker and virtual peers. Not if there are non-virtual (first life) video conferencing applications available that show real people with real voices and, more over, real expressions. I don't see myself watching a movie sitting (virtually) in a virtual cinema - and sitting behind the computer in reality - if I can see the same movie in much better quality and performance using Media Player applications.
I don't even see my try out new Nike shoes just by looking how well they fit my avatar, if I can't try them on at my own real feet. Haven't you seen the fancy flash applications of cars, where they show intereriors, exteriors, engines, safety features, in-car entertainment systems. You don't need a complete virtual world where you can travel between islands to show those products.

Second Life is typically an application to build virtual communities: build social networks and interacting with people within your network. From that perspective it is nothing more - and nothing less - than an ordinary chatroom with a (3D) graphical interface.

IBM and other companies are going to invest in Second Life to explore the business potentials, but they hardly invested in exploring the potential of previous social networks. Take for instance the IBM DeveloperWorks "community": it's just a newpaper-like publication board with discussion forums. The community building primarily comes from the people who contribute to the discussion forum. Originally discussion forums were just Q&A forums, where a user could post a question and many users posted answers to the question. But already in the Rational days there was the Rational Developer Network, a thriving community where people not only posted questions and answers, but also shared knowledge and experience. And not only on the product specifics, but also more general about professional interests, such a configuration management, process management, modeling, etcetera.

In 2003, Rational recognized the value of user communities. They formed a group volunteers (called Discussion Facilitators) to foster the user community. The social community would be a (low-cost) extension of the support service, and at the same time be a promotional instrument more powerful than the sales force could be. There were plans to create a real user community, where people feel the social connection and support. And then IBM took over and the focus was completely turned to sales. Rational lost its position as methodology leader, products lost their top class position and the community slowly degraded into a simple Q&A forum and website.

And now there is Second Life, a virtual world where social networks are primarily build around dating and gambling. Like many 3D MMORPG (games) I think there is a future to it, as an entertainment platform. Some people may get rich from Linden Dollars, but as a business platform I think it's just a hype.

Excellent or famous?

2007-02-03T10:04:00.000+01:00

For a long time I though that being present on discussion forums and weblogs, being able to be a though leader on a particular subject, being able to write great articles, give excellent presentations, being involved in everything that is important to the business and to my profession, and also being excellent in your day-to-day work and life,

is necessary to be successful.

Well, it is not. It is fun to do it all, but being excellent in your day-to-day life is hard enough and sufficient. All the rest is the cream on the pudding.

Switch to new blogger

2007-01-09T07:27:00.000+01:00

Soon, I will be switching to the new blogger format. Unlike many others, I will not try to add a tag to all my old posts, only to the new ones.

Update 25-Feb-2007: Using a new template.

It ain't as simple as it seems

2006-12-15T22:10:00.000+01:00

What is perfection? Perfection is when it seems simple but it is complicated. At least, that's what I consider perfection when I play the piano. Famous pianists and other musical artists get a lot of compliments when they near perfection, when they play something complicated and seem to do it without much difficulty. Why? Because those people knowing about making music know that it is actually very difficult to do. They recognize the skills of the artist and know that it takes a lot of practicing and a lot of effort to get to that level of perfection.

Now if we extrapolate that to running software projects, it often worked the other way around.
A project manager that is able to run a very complicated project that almost everybody screws up completely, and stay within reasonable budget and time overshoots and within reasonable limits of functionality and quality, gets a lot of respect for it. The next project he will probably have less difficulty to convince management to grant the budget and timing constraints that he estimates.
But a project manager that is able to run the same project within budget, within time and still providing the functionality and quality that was committed, what happens to him? He will probably have more difficulty to defend his estimates on budget and timing, next time. In other words, he reached a higher level of perfection but he is punished for it.

So why this difference between software and music? One obvious reason may be that music is composed. A music composition is an accurate -- and often not so accurate -- recipe about how the music should be performed. Key, notes and rest, tempi, forte and piano, accelerando and ritenuto, punctuations, etc. are all written down by the composer. And still, in spite of all the prescriptions there is plenty of room for interpretation differences. Many performers are even recognized for their style, their signature of sound.
Now if we look at software projects within a particular organization, a particular business, a particular product domain, a particular market segment, we seem a lot of similar projects with similar kind of people. One similarity that surprises me every time is that "we are different", so the quality system or other organizational systems does not completely apply. In other words, even though the projects are composed in the same way (like a music composition), we do not follow the composition (quality system, portfolio and project management system, configuration mangement system, and other systems of processes, procedures, stuctures, guidelines, conventions, standards, methods and tools). We argue that "we are different" and the system does not apply. We not only apply our own interpretation within the prescribed recipe of the composition, we also change -- tailor -- the composition itself.

The most common argument is that business goes first. If we can save costs or increase benefits by violating the (management) systems, then project management is often easily convinced. After all, we are not spending to money to satisfy our own systems but to earn money, or add business value. If we would alter the 5th piano concerto by Rachmaninov to make it simpler on the musicians so that they would be able to play with perfection, few customers would consider it an added value.

Perfection is to overcome the challenges and to make it seem simple, not to reduce them until only the simple things remain -- that's called degradation or devaluation.

Development speed vs accelleration

2006-11-27T00:35:00.000+01:00

Some days ago, I had a discussion with some of my colleagues about what percentage of a project budget should be spent on "overhead" activities, such as planning, tracking, reporting, documenting, process improvement or configuration management. Some argued that it should be less than 10%, other said it could be up to 50% of the total effort spent.
The argument is that a development project is supposed to development a product, so the core activity should be on engineering activities. Sounds reasonable to me.

Then I read the article about process improvement at Toyota, where it is claimed that the core activity of the organization has become "improving the process of making products" and the production/development of the product is a side-effect of it. The idea is simple: you will win from any competitors if you improve faster and/or longer than they do. Or put differently:

Speed wins over distance.
Acceleration wins over speed.
Accelerated acceleration wins over acceleration.

Now I revisited the original question: "What percentage of the budget should we spend on 'overhead'?" The answer became very simple: increase the percentage if it increases your business value. When it reaches 50%, or 60% or 90%, it does not matter as long as it is good for business. As with Toyota, this may imply that the core competence of the company will change (from making cars to improving the way cars are made). If for example only10% of the company are technical experts contributing to making the product, the company becomes a non-technical company.

When extrapolating this to the career challenges, it does not really matter whether I am good at what I do or not. Good technical skills, good social skills are nothing to be jealous about. Good learning skills, especially the learning skills to improve your learning skills, are ultimately what's going to make the difference.

SCM Best of breed for embedded software development?

2006-10-24T14:49:00.000+02:00

The "Forrester Wave(tm): Process-Centric Software Configuration Management, Q4 2005" [PDF] reports in its overall conclusion:

IBM Rational ClearCase is both the strongest overall solution as well as the most widely used.

Although this may be true for corporate IT shops, I doubt that it is true for shops developing products with embedded software. The reports states about Telelogic's Synergy that it

has always been strongest among telecommunications, automotive, and aerospace and definese companies building products with embedded software.

Although it does not say that IBM does not focus on this area, it is my experience in the field and in communication with people of IBM that they don't.

In the technology markets - which include product development with embedded software and component development for multiple disciplinaries (software, hardware, mechanical, electrical, (nano)optical, etc.) - projects have some specific challenges that are quite different from the corporate IT projects, such as:

Exponential growth of consumer products and professional products with embedded software
Exponential growth of volume and complexity of embedded software
Excessive pressure on costs (price), quality (safety, health and security), and the time-to-market
Extreme competitiveness on new products and new features
Increasing demands for integration and connectivity between heterogenous products

This brings on increased demands for the configuration management solution, for example:

Transparant integration of within product lines and across product lines for different application domains (e.g. medical equipment and telecommunication), with different and evolving architectures, different CM policies/strategies and different product lifecycles
Integration, collaboration and seamless bilateral exchange of data and assets across different organizations crossing company borders, not only as sub-contractor but also as partnerships, with appropriate protection of IP (Intellectual Property) and proprietary information and assets.
Sharing through open-source and inner-source (i.e. open-source approach within an intranet) of components with appropriate CM control.
Integration or interconnection for CM solutions of multiple vendors

In my experience, there are no tool vendors that seriously dive into these issues, not from a methodological angle nor from a technological perspective. These are challenges that are less likely to emerge for corporate IT solution than for product development. The Forrester report shows that IBM has the highest scores on R&D (5.00) and Product strategy (3.68), but the report does not take any of the above considerations into account for the evaluation.

Nevertheless, these are the challenges that product development companies will have to face somewhere in the future to survive the competition (or to collaborate with the competition and partners). It will require overcoming methodological (process definition) and technological (tool implementation) barriers. And since it involve collaboration with other parties across the boundaries of corporate responsibilities and authority, I seriously doubt those companies will succeed on their own.
But if they must, I think they will use a low-cost, possibly open-source CM solution (e.g. Subversion) as platform to jump off, unless a commercial CM tool offers the methodological and technological CM solution out-of-the-box.

IBM has the best cards on R&D and Product Strategy, but has no focus on this issue. Telelogic has the best focus, but doesn't do much on R&D. The Open-Source community (e.g. Subversion) has the best availability, price and simplicity, but lacks the necessary product characteristics (e.g. process support).
Which way it will go, I don't know. But my expectation is that the growth on product development will exceed that of corporate IT solutions, e-marketing and webdevelopment, and that IBM will lose the battle of "best of breed" with ClearCase if they don't jump in.

See also the discussion Will IBM Replace ClearCase with a New Product on CmCrossroads.

Update 14/4/2007:
Added labels.

Development is not alike manufacturing

2006-10-18T16:56:00.000+02:00

After reading the article in the Rational Edge about Lean software delivery I am very much upset. The article regards software development as if it is a manufacturing process. For business applications this may be true, but for the technology world this is absolutely not so.

Being on the bleeding edge of technology means exploring new grounds, new possibilities, new opportunities and inventing new products. Manufacturing is about executing the same actions to create the same products and doing it over and over again. Development is about doing (possibly the same, but more likely) different actions to create a different product and doing it once. I would say that development is more like a social economy.

But what I am most upset about is that IBM/Rational and many other tool vendors are persistently ignoring the technology world and pretend that (software) development is about business processes and business applications. Of course, that's where the most money is so that's where tool vendors can make the most money from. But the technology world has very pressing demands for flexibility, development speed and control, and desparately need better tools allow the companies to keep up with the increasing speed of technological evolution.

"Waste" is not "any activity that does not directly contribute to the added value of the end product". If you eliminate all of those, a development organization in the technology world will propably not survive release 2, let alone be able to develop a product line.

What is a configuration item?

2006-10-18T09:12:00.000+02:00

There are many definitions for (software) configuration management and most of them rely on the term configuration item (CI). In general, the meaning of this term boils down to something like:

An object that is treated as a self contained unit for the purpose of identification and change control [Source]

These are nice words and I think that I understand what the sentence means, but do we understand what a CI is? Are we able to pinpoint all and every CI of a project, and separate the CIs from the objects that are not CIs (but still relevant objects in the project)?

Let's make a side step. Suppose you are going on vacation and you are taking with you a lot of items. Let's replace change control by entertainment, because development's purpose is to make changes while vacations are for fun. Your passport is a self contained unit for the purpose of identification (of you); it is not for entertainment by itself, but it is needed to get to the destination where you will find your entertainment. The maps are also self contained units for the purpose of identification (of the route and the geographic area), and also indirectly linked to the entertainment part. Same for the money you take with you.
But how about your shoes? If you plan to go walking, dancing or playing tennis, you need shoes. But you need different shoes for different activities. So should we consider shoes in general, or should we consider walking shoes separate from tennis shoes? And should we consider left and right shoes as different objects? They are all self contained, and they are all for the purpose of entertainment.
But... are they for the purpose of identification? No? Well yes! The shoes are for the purpose of identifying the contents of your luggage. Without the shoes the luggage would be incomplete. The same for other items in your luggage. Could we define "the contents of your luggage" as one item? Well, yes and no. First of all, your luggage may consist of several suitcases, so the contents needs to be divided. You must be able to identify which items go in which suitcase. Assume you only take with you the items that have a purpose for your holiday, all items are for the purpose of identification (of the content of a suitcase) and entertainment. So luggage may be one CI, but also multiple CI depending on how you look at it.
Now, is "luggage" a CI, or is "the content of a suitcase" a CI, or are they both? Are the suitcases themselves CIs? Are the "set of suitcases" that you hand-off as cargo at check-in at the airport a CI? Are tennis shoes a CI different from walking shoes, or is "the set of shoe pairs" a CI? Do tennis socks belong to the tennis shoes and form a single CI together, or are they separate CIs? Maybe you wear them only in tennis shoes, or maybe you wear them in your walking shoes too. And how does wearing them under different circumstances in different combinations require tennis socks to be separate CIs? They do not contribute to the entertainment separate from the shoes, do they?

You may argue that a vacation does not "produce" concrete items like a development project, it only "consumes" so you cannot compare vacation with development projects. Well, that's not entirely true. A vacation does not produce a lot items, but when the vacation is over you do take home items that you did not take on holiday with you, such as photos, souvenirs, presents for friends and family, etcetera. You add items to your luggage, which may be considered a way of producing them. These extra items identify the content of your luggage on the way back.
Note that the CI "content of your luggage" changes over time, not only by adding items but also by dividing your items differently over your suitcases.
You do not want forget items that are of value to you when you go home. When you do, you'll be stuck with some bad memories and that spoils the purpose of your vacation (i.e. entertainment).

As you can see, configuration identification for a vacation is not simple. But nobody really worries about it, nobody talks about it and everybody does it. The only things you hear are things like "Don't forget your hairspray!", "Watch for your passport and tickets" or "Which way is it?". Nobody worries about reviewing and approving plans, schedules, routes, documents or luggage, and nobody really worries the risk of forgetting some items or losing them as long as you have your risk mitigation measures in place (a credit card, a mobile phone, insurrance, friends travelling with you). Even without formally organizing it, everything is set up with common understand and agreement.
So although configuration identification (or CM in general) for a vacation is non-trivial, not simple but very important for a successful vacation, it is never a big issue.

Now let's go back to a development project. In fact, configuration identification for a development project is similarly difficult as for a vacation. What is a CI is dependent on context, time and perspective. Like a pair of shoes are irrelevant when being part of the luggage, yet important enough not to forget as item to take with you (unless you always walk barefoots). Everyone knows you need to have plans, schedules, requirements, designs, repositories and all the other stuff, and that you need approval to avoid getting in a fight and spoiling the good spirit within the team or with the stakeholders.
But if everybody knows that and if everybody has no trouble of organizing a vacation in a proper way and in good spirit, then why is it so difficult to make a list of those items for a development project? If we list all containers that can hold a bunch of items, and identify those containers (i.e. the suitcases), the content of a container (i.e. the luggage) and the items of the luggage (i.e. the shoes, socks, etc.) then we have all CIs that we need. Note that a container can contain another container (e.g. a suitcase can contain a bag). Of course, you don't have to go down until atomic level. When items are always held together (e.g. shoelace and shoe), then there is no need to identify them separately.

One final note:
Why aren't development projects like vacation to us?
Why aren't project teams like groups of friends going on vacation together?

Update 14/4/2007:
Added labels.

Amazing photos

2006-10-17T22:52:00.000+02:00

For some time now, I have been watching the amazing photos from nature by Remo Savisaar on his blog. This guy must be wondering around in nature with his camera every day. How can he capture the moments with his camera so often, that I cannot even see more than once in a few years, let alone being able to freeze it in a photo.

This for example is very nice shot!

Professional software development

2006-10-01T21:13:00.000+02:00

Recently I renewed my interest in photography. I read the Strobist blog with great interest, in particular his Lighting 101 series.

One of the great virtues of digital photography is that it has become very easy and very cheap to make many pictures, and that you have instant feedback about the result. But the effect on me - and on many others - is that I make more pictures than I used to, but also worse pictures than I used to. I take less time to make a picture, but as a result it takes me much more time to make good picture. Why? Because shooting 10 bad pictures doesn't make any of them a good picture, while spending the same time on carefully shooting 2 pictures does.

I see a similar effect in software development projects. The tools we (can) use to make software becomes increasingly powerful, making it easier to model requirements, designs and tests, write code and perform static and dynamic analysis on it, generate testcase from the models and analysis reports. We produce more requirements, more models, more designs, more code, more complexities, more integrations, more variability, more platforms and the projects require more people, more teams, more sites, more departments, more companies, more processes, more reporting, more feedback and more historical data,

... More, more, more... Moores law rules!

But like more photographs don't make better pictures, more software does not make better software. But also, when making software becomes easier -- to make us more productive in terms of lines-of-code -- we teach people to do without thinking or understanding. Making a photograph becomes a point-n-click, and making a software systems becomes... point-n-click.

Slowly, we lose our ability to be patient enough to think and think carefully about what we are doing and what we are making. Lighting and composing a picture is about using available ambience and organizing things (strobes, angles, positions, attitudes, etc.) to achieve a desired effect, not about installing the equipment and press the button for a split second. Similarly, making software is not about installing and configuring the tools, dragging around objects and diagrams and pushing a button to build and run the software.

It's all about thinking carefully about what you want to achieve and what the effect may be of your lighting and composition choices. It's okay to try and retry, to run (incomplete) test shots to see effects like background, lights and shadows. But ultimately, we're better off producing less results with better quality than an unmanagable volume of crap.

Changing CM systems is more difficult than you think

2006-09-30T00:10:00.000+02:00

Some days ago I was talking to a former development manager of a big technology company going through the transition to another CM system. His statement was that during the time he was development manager he encountered a transition to a new CM system twice. But times, this transition almost led to a disaster for the (software) development department.

Now, with the third transition it's the same story; the company is almost facing a disaster for the development department. Apparently, going to another CM system is a very risky project that should not be taken lightly and requires specific expertise to do right. I am not surprised by this conclusion, but I always have a hard time explaining it to my customers.

Succeed by giving up

2006-09-09T09:37:00.000+02:00

Everybody knows a project running a death march. The deadline is nearing quickly but the product is not ready by far. New problems pop-up every day, every change seems to make things worse, developers are doing overtime against their will, budgets have exceeded, requirements are slipping rapidly to make up for requirements that could not be finished in time.

This reminded me of what my daughter did when she was facing her final exams at high school. It was math that was troubling her -- or better, it was troubling us --because results were quite low. So she needed a good point for her final for Math to pass.

If I were in her shoes, I would start studying hard, really hard, to catch up with all the stuff that I had missed in the past months. The easy parts are easy to succeed, so I would not give them much attention, just look through it to refresh my memory. But the difficult parts, I would study -- for hours. But... my daughter did precisely the opposite.

"This, this and this I do not understand, so lets skip it", she said, "I will fail on those parts anyway so why waste more time on it." And then she started studying on the subjects she was already good at, paying no attention to her weaknesses. Why? "Because I'll mess up most of it anyway, so those parts are going to save me". And she passed her exams... not with straight 'A'-s, but she passed! And she was focussed and did not worry for a minute.

I admire her for this...

Continuous integration kills large projects

2006-08-27T10:28:00.000+02:00

Continuous Integration is an widely accepted approach in software development. Martin Fowler describes has written een great article about it.

However, for a large project it does not work. I will explain why not. Suppose that we have a big project of 100 software developers. Each of them is an excellent worker, and only 1% of their deliveries causes the daily build to fail. With 200 working days per year, a developer causes only 2 daily builds per year to fail. Can you beat that?

Now although this is an excellent achievement, with 100 developers this will cause about 200 daily builds to fail, which is... every day the build fails!

So every day, the build manager has to figure out what is wrong. And since each of the developers are excellent workers, the finding the true cause of the build failure is hardly ever a trivial challenge. So with the help of the developers that have delivered, it might well take the whole day before the problem is fixed. Then, the build has to be distributed across all development teams, all development sites and incorporated in the workspaces of the developers. There will be little time left for integrating the new build with the developer's changes in his private workspace. So... continuous integration leads to continuous build failures!

In addition to the continuous build failures, when a developer must stay in sync with the latest build he has to integrate the latest build with his own changes every day. If this takes 1 hour, he will spend 4 hours per week on synchronization, which is at least 10%, day-in-day-out. They probably will get frustrated about going through their old changes every day, just because "build management provides a new build". So... continuous integration lead to frustration!

But when developers get frustrated, they will get sloppy at their work. And when they are sloppy, they are more likely to deliver changes that cause build failures. Let's assume it increases from once per half year to once per quarter. That is 400 build failures per year, or 2 build failures per day. So build managers are confronted with more problems causing the build to fail, which probably requires more work to uncover and fix. One day will not be enough. So... continuous integration stops to be continuous!

What can we do to overcome this problem?

I think we can go in two directions:

Reduce the scope of the continuous integration to smaller teams
Replace continuous integration by iterative integration

You can reduce the scope of the integration by dividing the large project into smaller teams, for example sub-system teams. Each team then performs continuous integration in a local scope, independent of the build of other teams. Only when it succeeds, the changes are promoted to a higher level of integration, for example system integration. Then when the system integration fails you have a choice. Either get the "guilty" developers involved in fixing the system integration, thus extracting them from their sub-system team temporarily, or force the "guilty" sub-system team to incorporate the changes of the (failing) system integration build in their sub-system build.

The other approach is to go to a weekly integration, where all developers deliver to. It will be a "slow" variant of the continuous integration approach. With less frequent integration, the amount of integration problems will increase. But instead of some hours, you have some days to fix them. And developers lose less time on synchronization with the build since they only have to do it once per week. I have seen this work, but only for a relatively quick build. For a build that takes several hours to run, the cycles for fixing the build are too long and even weekly integration will get stuck.

So my conclusion is that for large projects, it is better to divide the project into smaller teams, each with their own continuous build. It requires a more thorough (layered) integration strategy, and propagation of changes will be slower than with continuous integration. Continuous integration does not work for large projects.

Updated 14/4/2007:
Added labels.

The Green Shift Anti-Pattern

2006-08-25T10:20:00.000+02:00

In Dr Dobb's Agile Newsletter of July 2006, Scott Ambler writes about the "Green Shift". I was reminded of the article by Jason Yip.

The problem is that the project status "green shifted" as it rose through the various levels of management. The people on the ground were very clearly reporting a red project status, our project manager wanted to play it safe so reported yellow status, and his manager was more political yet and reported green status.

Green-shift is a form of information "erosion". When rocks erode under the influence of wind, rain, sand and dust, the sharp edges of the rocks disappear first. Next the shape of the rocks will change and finally the rock will crumble into pieces losing its original form entirely.

Erosion of information is a natural phenomena in communication. Every time a story is told, it is changed a bit. This way insignificant events may become spectacular (red-shift) and alarming reports may become uplifting (green-shift).

I like the solution that Scott proposes that by holding scrums the green-shift can be reduced. Three elements may play an important role in this. First, direct communication instead of passing the information over several layers. Less layers means less erosion or green-shift. Second, frequent communication reducing the delays. Less delays means less (time for) erosion. And thirdly, a scrum adds non-verbal communication that (written) reports are lacking. This improves the interpretation of the information, and interpretation is one of the sources of information erosion.

The cult of overwork

2006-08-24T09:39:00.000+02:00

The weblog article The cult of overwork , one of the comments caught my attention.

How about skipping the whole “time” concept? I’ve stopped dividing my time into work and leisure, since it seems to overlap in great extend. [...] I still seem that I love what I do enough to get the jobs done par excellence. frankly I don’t know if I’m working more or less than 40 hours a week.

How about skipping the whole "work" concept too? That way, we can not only stop dividing time into work and leisure, but we can also stop dividing our life in duty and pleasure. Let's focus on creating happiness in whatever we do with our lives. "Work" sounds like postponing fun and happiness until you go home.

Cost of broken builds

2006-08-21T11:57:00.000+02:00

Somehow my blog editor Performancing managed to publish my blog instead of making it draft. I am sorry for the incomplete blog entry. I have removed it.

37 Days

2006-08-21T07:59:00.000+02:00

After reading the Why 37 days blog, which I found through Bloggers and Writing skills which brought me to The Happiness Project - long live the RSS feed reader Bloglines - I wondered what I would do if I knew I had only 37 days to live...

I think that more interesting than the answer to this question is the process of dealing with the question. Does it add to the quality of my life worrying about now?

Carpe diem!

Strong opinions, held weakly

2006-08-19T09:10:00.000+02:00

In his weblog article Strong Opinions, Weakly Held, Bob Sutton writes about a psychological paradox that to move forward in knowledge and wisdom, we need

A strong opinion to assure that we are inspired to find the best arguments to support the opinion, but also
Not be attached to the opinion to avoid getting blind for evidence against it

At first this felt weird. At work, I like to either take a firm standpoint for my opinion or take no standpoint at all and listen to others. It often confuses people when I play Devil's Advocate and stick to my opinion for the sake of the discussion just to challenge it. In other situations, I seem unable to make up my mind and form a opinion.

In the end, it's all a matter of communication...

Bob Sutton's rule of not being an asshole

2006-08-18T22:49:00.000+02:00

Today I came across a little video about Don't be an asshole by Bob Sutton explaining the importance of people learning to be indifferent at times to things that cannot be changed, and ignore those things. It struck me because I tend to get irritated or frustrated about things that I don't like and I don't seem to be able to change.

More on the Don't be an asshole rule on his weblog.

Are modeling languages useful for complex systems?

2006-08-17T11:46:00.000+02:00

In the August edition of the Rational Edge, Laurance Balmelli gives an introduction to the basic purpose and value of Systems Modeling Language (SysML), a proposed extention to the Unified Model Language (UML). An interesting article where he uses a simple system (Rain Sensing Wiper in a car) to explain some basic concepts about requirements modeling with SysML.

Reading through it I noticed that although it is a simple system to regard, it still requires a decent model to describe it. I was wondering how this would be for complex, real-time systems like cars, airplanes, shpace shuttles or medical imaging equipment. Those systems are so extensive and so complicated, that the requirements model will probably at least as difficult to comprehend as the system that is being modeled. But the purpose of the model is to make the system's functionality (and non-functional aspects) easier to understand that just using your (expert) vision based on years of experience with developing those kind of things.

If modeling the monster is about as difficult as comprehending the system without the model, then why bother? In practice, you do often see that modelling is only used to get an initial vision of functionality and architecture because no one has enough experience to build an intuition. But after several years of developing release after release, the models start to get out-of-sync with the implementation and the documentation. I see it all the time that first models are neglected and the modelling tools are degraded to drawing tools.

Does this means that the modeling languages (like SysML) serve no purpose for those large and complex systems? I think they do partially. As long as these modeling languages (even when they are visual languages) are general and very abstract, engineers with a lot of experience and with a specific and concrete mental picture of the system will probably outperform the modeling language. But once those modeling language are more dedicated to the application area, either by design or by heuristics that allow the language to adapt to the application area, I think those languages may become a more practical tool for extreme complex systems. It's a matter of being able to trust the models to be more reliable than the mental pictures of the engineers.

Update 14/4/2007:
Added labels.

Ideal employer is a volunteer

2006-07-13T11:35:00.000+02:00

An article in managers online (Dutch) about Organizational Citizenship Behavior (OCB) caught my attention. According to an article by Livia Markczy, OCB is defined as:

"Individual behavior that is discretionary, not directly or explicitly recognized by the reward system, and that in the aggregate promotes the effective functioning of the organization."

There are two types of behavior in OCB:

Active positive contributions
Avoidance of harmful behaviors

The original Capability Maturity Model (CMM) tried to achieve repeatability by eliminating the dependency of "heros" in an organization and replacing them by defined procedures and processes. In other words, anybody with the right skill-set ought to be able to do it.

The Agile approach however recognizes the value of people's contributions over formal procedures. Heroic behavior like OCB probably flourishes better under Agile than under CMM regimes. It relies on trust and respect, and as Brad Appleton writes "The first thing to build is trust".

At the IBM developerWorks Rational discussion forums, where I am discussion facilitator for the ClearCase forum, IBM staff and the discussion facilitators are trying to build a user community. Apart from technical means and resources to communicate and interact, such a community depends on people that contribute exceptionally, so called valued contributors (OCB type 1 behavior). They contribute positively to the customer satisfaction, which IBM values (or should value) because it is good for sales and saves service (support) costs.

But one of the concerns for IBM Rational is that the promotional power of a user community depends on avoidance of harmful behavior (OCB type 2 behavior). The big questions is how to foster this type of behavior? Open source communities show that it can be done, so I am optimistic.

On one side, I see that the business world is becoming hard and cold, revolving around money, stocks and stakeholders, treating people like assets. On the other side, I see more and more initiatives that are soft and warm, revolving around people, community building and trust, treating business as intellectual challenges.

Paul Grahams essays

2006-07-07T12:07:00.000+02:00

I recently found the blogsite of Paul Graham. He has a prozaic way of writing essays which reads like a novel. That's good if you like to read novels, which I don't. Yet, I do love reading his essays and I have not discovered yet why.

One thing I notice is that reading his work is very relaxing, and that the message sticks better in my head than reading the succinct things that are mostly written about software development. May be that's the reason that I also like reading Joel on Software.

Masters and apprentices

2006-07-05T10:52:00.000+02:00

A long time ago I heard an interview with a great musician. It may have been Isaac Stern or Yehudi Menuhin, or someone else. The interviewer asked him who was his example when it comes to learning new skills for extremely difficult passages in music. His reply was:

"I learn the most from my students"

He explained that students often do not follow the techniques or the instructions tought by their teacher, either because they have forgotten or because they think it is too difficult. Those of you having had piano lessons can probably confirm that using the "right" fingers is often more difficult than doing it your own way. Using a different approach than the teacher prescribes brings forward alternatives, from which the teacher can learn.

In my work, I too learn most from the people that are trying to learn from me. When I tell them, they don't believe me, but it is true. Seeing my approaches applied by someone else, in a different way, reveals possibilities and alternatives where I have blackspots.

This is one of the most important reasons why I believe in user communities and sharing of experience. Not only novice users will learn from advanced users, but also advanced users will learn from the novice.

Jerry Weinberg blogs

2006-07-04T13:51:00.000+02:00

I have only recently discovered Gerald M. (Jerry) Weinbergs weblogs on consulting and on writing, and with it his books. I am not much of a reader of books but after reading his blogs and the reviews at Amazon.com, I get the impression that it's worthwhile trying Jerry's book More Secrets of Consulting.

No worse manager than a human resource manager

2006-05-30T07:25:00.000+02:00

There are managers and there are leaders. And there are human resource managers. Managers organize the work by setting targets, getting the resources and coordinating the activities. Leaders give direction to a vision and strategies, providing the energy to a team to reach the targets and to overcome obstacles.

Human resource managers are a special breed. In fact, they are providers of resources, just liking a hosting company is a provider of diskspace and internet bandwidth (computer resources). For HRMs the resources happen to be humans. HRMs do not manage humans like real managers do, they provide resources. HRMs have power over their resources, because they have the authority of hiring and firing, they do the evaluation (not based on their own experience with the humans they "manage") and they claim to have better human skills than any of the humans they manage.

Because HRMs manage humans and because they have quite an influencial power over those humans, they are often regarded as very important managers, with a good sense of business importance, business priorities, and with a high esteme and a high salary. But in fact, they have no clue about the real work, the real challenges that those humans face, day-in day-out, to achieve the real business goals.

Disclaimer:
Anything I write may be my true opinion or an attempt to challenge my opinion (i.e. not my true opinion), or a combination. Any perceived correspondence with real people or real situations is purely coincidental.

What is Configuration Management

2006-05-28T14:13:00.000+02:00

There are many different definitions of Configuration management (CM), as can be read at Brad Appleton's website. I personally like the old and short definition by Susan Darts stemming from the 90-ies:

(Software) CM is a discipline for controlling the evolution of (software) systems

I like this definition because it implies a constant change of the system (evolution), but change in an orchestrated fashion (controlling), requiring distinct knowledge and teaching (discipline) to perform. Without change there is no evolution and there is no need for CM to control it.

The big difference with Project Management (PM) is that PM controls targets, resources and activities over the course of a project, while CM controls the changing system itself. The timespan of PM is a project, while the timespan of CM is the lifespan of a system which lasts until end-of-life (i.e. end-of-evolution) of the system. And when does CM start? Well, as soon as the evolution of the system starts to be controlled, which is at or before the start of a project.
So, CM starts before a project starts and ends until after the project has finished.

Featured community member

2006-05-20T09:24:00.000+02:00

Usually, I hate being put in the spotlights but in this case I feel very proud to be listed as Features Community Member at the IBM DeveloperWorks website. Follow this link.

20 percent time

2006-05-20T08:48:00.000+02:00

I stumbled across the Google philosofy that engineers all have "20 percent time" in which they can work on the things they think are cool to work on. I like the idea. In my experience engineers spend time on creativity and other activities that they consider necessary anyway.

Adopting TagCloud

2006-05-02T12:08:00.000+02:00

After reading about TagCloud at the blog of Grady Booch if decided to give it a try to. The tags of Technotari I find too difficult to maintain so I will abandone them.

Note added on July 11th 2006: For some reason, the TagCloud does not display a cloud of tags anymore, and there is no way I can find to login to TagCloud. Until I find an alternative, I will leave it.

Unconcious thinking

2006-03-19T20:08:00.000+01:00

Have you ever tried to look at a very faint light, a star or so? And did discover that you can see it better by looking next to it?

In a science edition of the NRC (Dutch newspaper) I read an article about unconcious thinking. In the article it was claimed that the concious mind is only suitable for simple decision, like buying toothpaste. But when it comes to really significant decisions, the complexity is too large for the concious mind. The unconcious mind is able to think much quicker and take much more complex thinking patterns than the concious mind. Decisions like buying a car or a house, changing your job or starting your own company are best left to the unconcious mind.

According to the experiment, a number of people were asked to listen to a large amount of unrelated information. Two groups were asked questions about the information after half an hour to verify what they remembered of it. One group was left to memorize the information and the other group conducted a numbering game that required them to use their rational abilities. It appeared that the second group was able to answer more questions correctly than the first group.

I was amazed by it, but it concurs with my own way of learning. If I absorb an amount of information and go do something else that takes my mind off the subject (playing on the piano or even studying a piece, for example), it is much easier to remember and see all kind of relationships in what I learned than when I try to stay concentrated and focussed. Sleep on it!

Technorati tags: Mind, Unconcious, Thinking

CM is a multidimensional problem

2006-03-17T11:56:00.000+01:00

Traditionally, software configuration management (CM) is concerned with version control on software modules. Many CM systems are very capable of handling source code files and files generated from those sources (derived objects) in workspaces that look very similar to the ordinary file systems.
Most of them are also able to control parallel evolutions of those files (branching and merging), attach attributes to those files as a status indicator (labels, attributes) and allow automation on particular events (triggers). Only a few CM systems support a higher abstraction level concepts like subsystems/components/modules, projects, streams, baselines, tasks/activities.

In most organizations that I have seen, there is a enormous gap between the CM for "code", the CM for "documents" and CM for "data" that is neither code or nor documents (e.g. requirements database or a test data set), not to speak of CM for physical objects (e.g. hardware components, mechanical components, books or CD-ROMs).

There are some some questions that I find very difficult to answer during development, but that I would expect a configuration manager to be able to answer. Of course, after product release, when all documents are approved and all functionality has been implemented these questions are easy, but not during development.

Here is a test system with this software baseline installed on it. What is the corresponding document baseline that describes how the system should behave and how it should working internally (in other words: which versions of which documents)?
Which versions of hardware boards en chips on those boards should we use?
Which version of each of the requirements in the requirements database correspond to those software baseline?
Which test cases, test scripts and test data sets should I use for testing, and which version of them?
Which tools have been used to make this software baseline, and which version of them? Which tools and which versions of them should I use to analyse the system's behaviour and data output?
Which versions of the plans (project plan, configuration management plan, quality assurance plan, integration plan, test plan, etc.) apply?
Which problem reports apply to indicate the known problems?

May be the default answer is: the latest version. But if I am using the software baseline of last week then the latest versions will not correspond to the software baseline because those versions did not exist yet when the software baseline was created. The latest set of problem reports contains problems that were not known or that have been solved now but were still unsolved at the time of the software baseline.

May be the default answer shoul be: the latest version at the time of the software baseline. But possibly (and probably) some of the documents or other objects were out-of-date at that time, and some of them were already updated for the next baseline. Of the set of problems that time some solution may not (yet) be that particular software baseline, since the source versions stem from some time before the software baseline.

Another issue is that various individuals in various teams work all in parallel. Project assets (i.e. code, documents, hardware, data, knowledge and other assets and information) are evolving asynchronously. So it is not trivial to draw a timeline across all running activities to capture exactly the right versions of everything that belongs together as an overall baseline. To do that, there must be a system that manages not only the relationship between every (physical or informational) asset that plays a role in development , but also the relationship across versions of every asset.

Configuration management is actually a multidimensional problem and a "baseline" is a line in the multidimensional space. Some examples of dimensions are:

Identification of the controlled items (a.k.a. "configuration items" or CI)
Logical decomposition/clustering
Storage locations, directory paths
Versions
Variants
Branches
Maturity or quality level
Competence area
Department, division, third-party supplier, team, site/location

The most difficult issue that CM has to deal with is that during development a change can (and often will) happen in any of those directions. For example, an update results in a new version, a move results in a new location, a generic item may become specific for a particular variant or vice versa. But in addition to the change itself, the relationships between all those versions and items must also change. For example, when a requirement is changed or added, all design documents and models, hardware, mechanics and software modules and other dependent items must still relate to the previous set of requirements. But as soon as any of those items is updated for the changed requirement it must relate to the new set of requirements. But... in the meantime another requirement change happens, and also design changes, code changes, hardware changes, data set changes.

Everything constantly changes during development!

Because it is a multidimensional space that is constantly in motion, it is humanly impossible to maintain a constant overview of which (version) of all thousands of items belongs to which (version) of any other of those thousands of items. It's like making holographic pictures of an N-dimensional waterfall.

Did you notice that I did not take into account that organizations are constantly changing. For example turnover of people, responsibility shifts, process improvements, policy and strategic changes, marketing fluctuations, business objectives changes. But also people are changing constantly by their motivation, knowledge level, moods, etc. The effect on the configuration management is rather indirect, but for example the interpretation of a design decision may be different when the another architect is in charge, or another set of documents must be updated when the production of a certain piece of hardware is subcontracted to another supplier.

May be you do not consider all of this as "configuration management" but the whole conglomerate of interdependent physical and informational items (and all of their versions) must be maintained somewhere. Because this is too complex a problem for a human to comprehend and because nobody has ever invented a (CM) system to cope with this, we still rely on the collection of human brains with shared knowledge, logic, communication, perceptions and opinions.

Technorati tags: Configuration Management, Software, Management, Development

Why pilots don't run airports

2006-02-26T19:55:00.000+01:00

May be it is not obvious to many people, but the Captain of an airplane is the highest authority on board. When he decides that a plane is going up or down, left or right, faster or slow, it will be done. Not even the CEO of the airline will overrule him. Yet, no captain or pilot will land an airplane on an airport unless they have clearance from the Air Traffic Controller (ATC) in the tower, not even when the airplane is hours too late, hundreds of passengers are waiting for transportation or deadlines for lucrative cargo contracts are at stake.

Now suppose, 5 other planes are first in queue and none of them is delayed or has an emergency. The airport is using only 1 of the 2 runways for landing because of maintenance.

Captain: "Tower, AA123 is requesting immediate landing clearance"
ATC: "AA123, what's you're emergency"
AA123: "Tower, you have caused us delays. AA will lose a 200 billion contract if we don't arrive within the next 30 minutes. AA123"
ATC: "Negative AA123. Continue approach in sequence. You're number 6 to land"

Would the captain dare to respond with:

Captain: "Tower, I am captain of this Boeing 747, and I have clearance from the CEO of AA. We're coming in on runway 24L, AA123"
ATC: "AA123, runway 24L is under maintenance"
Captain: "Tower, that's your problem. If you were operating 2 runways, we would not have gotten this delay. We're talking big money here!"

Now translate this to a late software project. It's a Friday before the summer holidays and everyone is eager to take some days off after the project has hampered due inconsistencies in the CM repository, caused by late and hurried integration of some changes making the build to fail. Some of these changes need to be undone and some other need to be fixed, before new features can be added responsibly. The configuration manager says No, can't do but the project manager is in a hurry to release the product to a customer with a 200 billion dollar contract.

Technorati tags:
Software Development, ATC

Waterfall conference 2006

2006-01-29T09:55:00.000+01:00

There is a new talk of the town, the Waterfall Conference 2006.

Technorati tags: Waterfall, Software

Is software development a commodity

2006-01-03T08:31:00.000+01:00

IBM goes for open source. At first I could not believe that a company like IBM would ever consider giving away anything to anyone. But with Eclipse they do and by donating a subset of the Rational Unified Process they are doing it again. Why?

It's like fishing. They throw out the bait to catch the big fish.

IBM goes for the big money. And where is the big money: information management. A way to achieve that is (1) by penetrating enterprises at corporate executive level and (2) making companies totally dependent on products of IBM. One of the most powerful ways to create total dependency is by giving away for free. But IBM is not giving away Eclipse or RUP, they are giving away software development technology, what used to be Rational. IBM is making software development an engineering commodity, like a mobile communication (which started off by giving away mobile phones) or car navigation systems.

This is a very smart move. Microsoft has become big by giving away commodities like Internet Explorer or Windows Media Player, and by condoning illegal copying of Windows and Office for a long time. Now Microsoft is trying to make money with .NET and IBM is slowly giving away software development technology. Which one to choose: pay for Microsoft or use for free from IBM. Giving away technology and binding customers to your products that make use of that technology, that's a way of creating a competitive edge!

Technorati tags: Software development, Methodology

Configuration Management: ICSA or PICSAR

2006-01-02T17:21:00.000+01:00

It is generally accepted that configuration management consists of 4 components: identification, control, status accounting and auditing. However, while working on an introductory presentation about configuration management, I came across the activity of writing a configuration management plan. But what is a plan without any planning? In other words, you not only plan what you're going to do, but also when, how often, who's going to do it, etcetera.

Another issue is the factor is that a software development project is a finite enterprise. Once the goal has been established, the project ends. This also applies to configuration management, so there must be an end to configuration management. For configuration management the activities end as soon as the final result has been established, i.e. releasing.

In other words, wouldn't configuration management consists of 4+2 components?

Planning
Identification
Control
Status Accounting
Auditing
Releasing

I wonder what the acronym PICSAR really stands for... ;-)

Technorati tags: SCM

RTFM! Whose time is really being wasted?

2006-01-02T08:14:00.000+01:00

After reading the You are what you read blog by David J Andersen, I was attracted to the editorial comment RTFM! Whose time is really being wasted?, written back in 2000. As you probably know by now, I hate reading books but that's not the most important reason why I like the article. What I like about it is the idea of designing out the problems.

If a product does not need a manual, you can save time and energy on reading it and on writing it. And if problems are designed out of the product, the product in inherently more suited for use by the customer which creates customer satisfaction, boosts the product vendor's reputation and improves the competitiveness of the product (and thereby the product sales). In addition, the product vendor's can save on the support organization because less customer problems need to be solved.

Technorati tags: Support, Product Development

Configurations, Streams and Control

2005-12-31T09:59:00.000+01:00

At CMCrossroads I wrote that configuration management needs three things, which is explained in more detail by Brad Appleton.

Configurations, being the current content of a workspace. It may be complete or incomplete, but it contains everything the developer needs to work on or work with.
Streams, to evolve configurations from their current state to a new state closer to the final state (the product release state)
Control mechanisms to assure that the configurations evolve toward the goal in an efficient and effective way.

In a reaction Robert Cowham wonders what a component is and what a stream is. From a scientific point of view we may need unambiguous definitions before we start reasoning about them, but as a practitioner I rather use fuzziness to create a common understanding and interpretation first. Afterall, we are not writing lawbooks here, nor scientific dissertations.

The 4+2 view of SCM principles as explained by Brad Appleton contains 6 different views:

Project
Environment
Product
Evolution
Process
Organization

Each of these views contains 3 aspects to consider:

Static instances (i.e. physical reality),
Dynamic interactions between these instances (i.e. birth, life, growth and death) and
Rules (i.e. laws of nature, traditions) to which the instances and interactions must obey.

For example, a Process view consists of practices (dynamics, the actions how things evolve into different things) which are written down in procedures (statics, how things are at a certain time and place) which require level of competence and motivation before people actually apply them (rules, the laws of nature and reality for things and actions).

Let's assume that a development project is a single goal: a product that satisfies a particular set of requirements for a particular set of stakeholders. Or in more practical terms, a set of executables and manuals for the customer, and a set of source code, models and development documents for the development organization (for further development and maintenance). So the final configuration (static instance) is known. And suppose the project is starting from scratch, so the initial configuration is also known, you might think...

Wrong! The "initial" configuration does not contain a assets (static instances) to perform action (dynamics). We need to hire developers, acquire computers, install and configure the tools, set up and fill databases with our so-called "initial configuration", set up the organization of the project (roles, responsibilities, agreements, commitments), etcetera. Only then, the configuration is filled with everything a developer needs to work on or to work with, which makes the initial configuration. Yet, the initial configuration still is a set of static instances.

Then the teams start working. Basically, all they do is taking a configuration and transforming it in another configuration. If we consider a configuration a "point in time and space", then the continuous evolution of configurations as a "line in time and space", which we call a stream. Conceptually, each team or even each individual within a team (or project) has a separate set of streams, where at any moment in time a stream can be split (i.e. two actions on the same configuration resulting in two new configurations) or joined (i.e. an action is performed on two configurations resulting in one new configuration).
If this happens completely organically, following the rules of reality to perform the dynamics, without any level of control, it is likely that a Darwinistic evolution takes place where is it unpredictable when and whether any configuration comes anywhere close to the project goal within a reasonable time. Very likely, psychological and sociological rules will dominate economic and business rules.

So we need a form of control to assure that a (final) configuration matches the project goal. Typically, there are two dimentions to control from a configuration management perspective: content and quality. By combining them into a single attribute, we come to value. A rule of nature is that a stronger species survives a weaker species. For configuration management, we can translate this in: a configuration of a higher value survives a configuration of a lower value.
To take this more in a practice way, we can say that a team (or an individual) that is degrading the product, the environment, the organization or any other of the 4+2 views, then the resulting configuration should be rejected by configuration management. Of course, project management would be wise to not even allow a team to spend time and effort on a degrading activity, but sometimes (for example, when prototyping to determine added value in an empirical way) a team result may produce a degraded configuration compared to what they started with.

Another example of a degraded (lower value) configuration may occur when two teams create a new configuration of a higher value than their initial configuration (which makes both configurations acceptable for configuration management), but joining results in some many issues that the joined configuration is of lesser value than the initial configuration. In that case, we have the option of accepting one of the configurations and reject the other one (in spite of its added value), or work on the degraded (joined) configuration to created enough added value so that the overall value is higher than the initial configuration.
The mechanisms of controlling configurations and streams in a strategic manner is what makes configuration management an interesting profession. This way branching strategies, workflow strategies, integration strategies, etcetera are born.

Technorati tags: SCM, Software Development

It's all a game

2005-12-30T00:38:00.000+01:00

In a blog, I read how IBM enters the gaming world and this brought me the idea that there may be more commonality between software development and online gaming then we might expect, such as

Team game
Strategic approach
Online community
Common goal
Common set of rules
Computer infrastructure
Continuous learning

One of the nice things about strategic games is that the game vendor has created a virtual world that contains almost every capability to face the game challenges in order to achieve the ultimate goal of the game. You can give instructions, set assignments, get status report of all kind of aspects, do what-if analysis, and much more. Everything is represented in colorful, 2-D or 3-D graphics, accurate reposiories of artifacts, drag-n-droppable, interactive, on-line multiplayer and joyful to do. And how much does this game cost? A few dollars or euros. How much time to install it, get it working, learn it? A few hours, or may be a day or two.

Compare this to the software development environment that an average software development organization provides to its developers and the costs and efforts that are involved in setting this up, determining the rules of the "game" (procedures, practices, workflows, quality criteria, etc.). Expensive CM systems, SDE tools, a lot of in-house made scripting to achieve automation and reporting in spreadsheets and intranet sites.

What if we would create a software development environment à la Command & Conquer or Pharao? What if we would make an interactive, on-line multiplayer game for software development? My first intuition says that it can't be done or else it would have been done before. My second intuition says that if we spend billions on movies and games in the entertainment industry and find millions of people enthousiastic about it, then apparently that's the way to get people moving.

Comment or blog?

2005-12-30T00:04:00.000+01:00

If you're reading someone's blog and you would like to comment on it, you have the choice to add a comment on it, or write a blog entry at your own blog with a reference (link) to the blog your are commenting.

I wonder which one is the best approach. If you comment to an existing blog, you probably lose track of all your own contributions leaving your own blog empty, or you have to repeat yourself in your own blog. If you comment in your own blog however, the comment is probably not read by the writer of the article.

So, I tend to have a slight preference to write your own blog entry and put a link to it in the comment of the other blog. It would even be nicer to have a "link" that works by value instead of by reference.

Technorati tags: blog

Continuous integration with extreme builds

2005-12-11T00:47:00.000+01:00

A known best practice in software development is Continuous Integration. It is better to integrate often than it is to integrate rarely because the effort to resolve integration issues grows exponentially with the volume of change that is integrated.

Now let's do some math. Suppose we have a project that runs a complete build (including a smoke test) in 10 minutes. Given an exponential growth of integration issues with a growing volume of changes, suppose the following average times to resolve integration issues:

1 hour interval: 10 minutes to resolve integration issues
2 hour interval: 40 minutes
3 hour interval: 90 minutes = 1 hours 30 minutes
4 hour interval: 160 minutes = 2 hours 40 minutes
8 hour interval: 640 minutes = 10 hours 40 minutes

So when running a nightly build, it is not possible to resolve the integration issues the next day anymore.

Now suppose we have a large system where the build takes 1 hour to run. So the minimum build interval is 2 hours. But a large system also has a large development team, so the volume of change in 2 hours results in more than 40 minutes to resolve integration issues. Let's say it takes 50 minutes. So the build runs for 1 hour and the repairs take 50 minutes. So you have 4 runs per day, some of them will not even result in a successful build before the next run.
You can probably imagine what happens if the build+repair time starts exceeding the build interval: the project will become instable because nobody can trust the build anymore. Increasing the build interval will make things exponentially worse!

This may seem like a theoretical problem, but I have worked for several organizations where the build run takes more than 1 hour to run, sometimes even 4 hours. There you have the challenge to make the organization productive in software development that I am involved with...

IBM Rational Discussion Facilitators

2005-12-04T00:24:00.000+01:00

Marc Siegel, IBM Rational's community manager, has introduced the IBM Rational Discussion Facilitators in an article on IBM DeveloperWorks.

Many customers may have noticed that since Rational has been taken over by IBM some years ago, the communication between the customer (including the responsible IT and Development managers, and the actual users working with the tools) and IBM Rational (including sales and support) has changed considerably, not for the better in most cases. User to User communication is an emerging (support) strategy for customers, and it has proven its effectiveness for open-source software for many years.
However, User-to-ToolVendor communication has been difficult in the past and will become more difficult in the future due to cost-saving on service organizations. For that reason, I think that IBM has made a smart move to institutionalise the use of Discussion Facilitators for direct communication with Product Management, as they are not on the payroll of IBM (i.e. they are ordinary customers themselves) while they provide a bilateral service to the user community.

The IBM Rational discussion forums are the discussion forums for users of Rational products. The IBM website, including the DeveloperWorks website, are rather difficult to navigate through so you'd best go to it through the direct link.

Software development in healthcare

2005-11-17T08:35:00.000+01:00

In the Rational Edge e-magazine of November 2005, Tony Bosselait, IBM Business Executive for Worldwide Healthcare Industry Software Sales, and Dr. Ben Amaba, IBM Rational Public Sector Industry Solutions Executive are interviewed.

Although it is an interesting article about healthcare IT, it struck me that the real challenging side of (software or system) development in the healthcare arena is avoided. The advanced technological challenges concerning systems for diagnostics, imaging, treatment and therapy are left out of the equation in the article.

It is in this area that extremely complex real-time systems, advanced technology and advanced clinical application meet the critical health and safety requirements of patients, medical staff and scientists. It is in this area that business, technology and society truely meet.
One of the challenges that IBM (and software tool vendors in general) should address is not only to provide the tools to do modeling, architecture & design, coding, integration, verification and validation, configuration management, etcetera, but to do it with extremely large datasets of system assets/artefacts, in an extremely flexible way (e.g. refactoring, rapid prototyping), for extremely large systems with extremely complex, real-time behaviour, for extremely large development projects that cross not only geographic areas but also enterprise boundaries (multi-company collaboration to bundle pluriform competences) and extremely transparent across all of those disciplines (business modelling, requirement management, etcetera).

It has been evident to me that IBM is avoiding these real challenges and focusses more on the "big money" business (i.e. enterprises). Stakeholders like that! It is a large market and there is a lot of money going around. However, technologically large and complex systems are emerging into society with agressive speed (such as health, home/entertainment, automotive/aeronautics, semiconductor, (tele)communications, etc.) and e-commerce depends on it for its growth. Afterall, you can't sell what you can't make. Society is more and more relying on protection of health and safety in a automated, transparent, even invisible way, not only in a military way (e.g. counter terrorism) but also in an everyday situation like healthcare or traffic-safety (e.g. car safety). More and more, we rely on the correctness of automated guidance systems, surveillance systems, monitoring systems and even systems that take over our actions to cope with emergency situations.

Development of those systems require the most sophisticated and advanced development tools / methods. Tool vendors like IBM Rational do have a responsibility to society to enable the technological means for (software) development. I do understand that IBM rather goes where the most money is, but ultimately the industry needs far more sophisticated tools and methodologies than what is currently available in the marketplace.

A vision on future software development environments

2005-11-09T10:40:00.000+01:00

Recently I contributed to a discussion (on a restricted discussion group) about the (lack of) user-friendliness and user-required functionality of a discussion forum website. It is the website of a tool vendor that sells software development tools. Apparently, this company is more interested in selling software tools than in applying them to give their user community a good user experience with them. You probably guess which company I am talking about, or at least consider two candidates.

One of the things I was wondering was that if they are not willing to invest in providing a strong, flexible and properly equiped website facilities, but the users do want a strong, flexible and properly equiped website facilities, why not let the users themselves develop it. This would perfectly fit in the open-source approach that this company (claims to) support.
Even more, if this company would provide all their development tools (requirement tool, modelling tool, design tool, configuration management tool, defect management tool, test tools, deployment tools, project management tools, etc.), in an integrated software development environment, fully operational with licenses and databases, then they only have to find trusted users who are willing to invest their free time in it (or their bosses time).

This is one side of the story that is about to come. The other side is that there are a lot of companies in need of good (software) developers and there are a lot of companies that hire good software developers on contract basis to those companies. The problem is that with the globalisation (of which outsourcing to India and China is an exponent) the "good" people are available at the wrong place. So either they have to move or travel, or they have to be able to work remote (or by multisite replication and data interchange). This brings an extra burden on the software development environment (and the management) and since it is not a core business process the senior management is unlikely to invest a lot of time, effort and money on it.

But... if we look at the open-source development community, they have a different approach which I envision as the future for (commercial) software development too. For open-source development, the "foundation" either provides a downloadable software development environment or a website (or conglomerate of websites) that provide a remote software development environment. This way, the foundation provides the means for software development and brings it to the people working in software development, rather than bringing the people to the software development environment. This way, the development community can be (and usually) is distributed globally, yet forming a single development group.

Given that it is becoming more and more difficult to setup, maintain and evolve a mature software development environment, with state-of-the-art development methodologies, state-of-the-art tools, perfect integration and interaction between the various parts of the facilities, streamlined information exchange between different data bases, I expect that the future of software development lies in software development hosting companies. These companies are similar to email hosting, website hosting, blogger hosting, search hosting, portal hostings, etc.

SDE hosting companies provide a complete software development environment, consisting of tools and database for business modelling, requirement management, architecture and design modelling, coding, testing, deployment, configuration management, project management, continous integration/builds, etc. These tools are licensed, integrated and able to exchange and share information and upgrade with the pace of the tool vendors.
SDE hosting companies provide a (probably limited) set of development paradigms, from RUP to Prince2, Agile, SCRUM, XP, Waterfall, Spiral, Incremental and other "standardized" methodologies. They watch the trends and upgrade with the pace of knowledge/competence development in those areas.
SDE hosting companies work for a (probably limited) set of application domains or market, such as web-development, financial products, health, security, automotive/aeronautics, etc. so they can tailor the methodologies and tools towards it. They will probably also specialise in small, medium, large or extremely large (and complex) products.
SDE hosting companies provide (restricted and secure) access to the software development environment from all over the world, through web-clients, VPN or other secure means, possibly with multisite replication behind the scenes to improve local performance. This way, multinational companies, teleworkers and travellers and open-source works can make use of it.

In particular technology companies often require quite fundamental hardware development (new chips, dedicated equipment, etc.), mechanical, optical and physics developments (miniturising in semiconductors, radiology science in health and treatment, encryption and recognition in security). So the SDE hosting companies must also provide hooks to (automatically) transfer, install and test on in-house equipment outside the SDE host environment and feedback information to the SDE host environment.

Client customers, i.e. companies that actually do the software development to make their products, will hire the SDE from a SDE hosting company and will be relieved of setting up all the different tools, databases, exchanges between database, etc. and don't have to "invent" and maintain the methodology based on "some guy who has read the book about it" or a consultant who is more interested in making managers happy, avoid company politics and get his money than in achieve the best solution and overcoming the resistence and politics do achieve that (and risk his reputation and the reputation of the company he is representing).

So the SDE hosting companies will only provide the means in terms of tools, databases and processes, but do not do the actual software development with it. Because they are specialised (or will become more and more specialised) in tools, databases and processes, and since they service various different customers, they can pay explicit attention to optimizing the software development environment by using specially configured servers, performance tuning, load-sharing facilities, fault-tolerance and fall-back, etc. while spreading the costs over a multitude of customers. The customers will save the overhead of "all those servers doing almost nothing for 70% of the time and being overloaded for 30% of the time", outage due to maintenance, upgrading, troubleshooting, etc.

Using this approach, we will separate how to develop software from what software to develop. For decades, many large and complex companies have been so arrogant to say that they are "different" because the software they make is so much different, and thus refusing to comply with the "same" way of software development. For decades, the tool vendors have been so arrogant to say that their tools and the methodologies that lay behind them are the solution to make software development more productive, more reliable and predictable, cheaper and faster, without actually being able to help when even with the tools the customer is not able to get it out properly ("You are using it in an inefficient way, because of ... your architecture ... your processes ... your company culture ..."). I think the time has come to accept that how to develop and what to develop are two different fields of expertise.

Hate to read books

2005-10-09T22:34:00.000+02:00

Let me tell you about a very nasty disease I have:

I hate reading books
I hate spend money on books I don't read

The latest book I read completely was Peopleware by DeMarco, about 6 years ago. It changed my way of thinking quite considerably. I got In Search of Excellence by Peters as a present, but was unable to finish it. Same for Gödel, Escher, Bach which is one of the most boring books I have ever looked into. I wish I had read the book A Mythical Manmonth by Brooks. I read Alice in Wonderland on the little screen of my Palm V, but forgot about most of it.

My wife and kids love to read. Many of the people I admire are addictive readers and I wonder where they find the time to do it. My problem is that I can't read while driving a car, I can't read while working as a consultant for a customer, I can't read while I am playing the piano, I can't read while eating and I can't read while reading or writing on the internet. And I can't read in airplanes on business travels because I do not travel enough and when I do I am too interested in listening to the cockpit radio (I think only United Airlines has an audio channel with the cockpit radio) or preparing for the meetings to come.

If any of you has any idea how to cure my disease, then please tell me... thanks in advance.

Fonts on LCD displays

2005-09-27T11:39:00.000+02:00

Modern LCD displays can display very high resolution. But instead of using it to improve readibility, I typically use it to squeeze even more information on a single display. Writing a text using different sources fills up my screen with multiple windows.

But... become older my eyesight is degrading slowly, so I need larger fonts to keep things readable. With Microsoft's ClearType tuner I have improved readibility significantly, with the same font. It works especially good LCD displays since they have less "smudge" than CRT displays.

Configuration management, what is it?

2005-06-04T13:55:00.000+02:00

When talking about configuration management, are we talking about the same things? Or are we just using the same words, the same terminology, the same vocabulary with a completely different picture in mind?
When I talk about configuration management, I usually mean configuration management for the development project of a product. CM for deployment of products and services is a completely different profession. But even within a development project, there is the same distinction between development and deployment. I will explain.
During the development project, there is a (software) development environment consisting of various applications that are needed to develop the software. In this development environment, new applications and services come available, for example a new compiler (or a new version), operating system upgrades and patches or modelling tools. The development environment is managed by an IT department, but even within a development project special scripts and tools are maintained to tailor the development environment for project specific optimization. That is called configuration management.
But the development environment does not develop a product; people do. And while people develop the product they make new artefacts, derived from other artefacts. For example, a design is derived from requirements and design constraints, code is derived from design and requirements, etcetera. And since this is performed in some sort of stepwise process (waterfall, spiral, iterative, incremental, agile, you name it) many artefacts are produced in different versions. These versions need to be managed, which is also called configuration management.

So we have already 3 types of configuration management:

Configuration management of the deployment environment
Configuration management of the development environment
Configuration management of the project's products

Management or environment?
Now, when you are talking to the SCM-er of a project, who are you talking too? Is he responsible for assuring the the SCM system's availability and performance is within acceptable limits? Is he responsible for resolving database inconsistencies, like stale versions and branches, hyperlinks pointing the wrong way, data that is not replicated correctly to remote sites? In that case, he an SCM environment kind of guy.
Is he responsible for authorizing promotion of changes based on promotion or delivery criteria, deciding in which workspace which changes need to be made based on the development plan, who has access to which parts of the system, which versions need to be used for integration and testing, reporting the "status" of the product during its development? In that case, he is a configuration management kind of guy.

Unfortunately, we have seldom make a distinction between the name of these roles. And unfortunately, many of the issues that these people are dealing with are similar. But confusing these roles makes it difficult to communicate effectively.
For example, a project leader needs to start a new project to develop a product variant of a product that is still under development. He instructs his CM-er to create a development branch.

If the CM-er is an environment oriented person, he will probably create a branch using his knowledge about the CM tool from the LATEST version of the product development. Whenever a developer needs a change from one branch to another, he can merge using the CM tool mechanisms, possibly with the help of the CM-er. Introducing inconsistencies, quality risks and other degradation phenomena is not the concern of the CM-er.
However, if the CM-er is an management oriented person, he will probably worry about how to control the isolation and integration of changes happening in parallel. What if product development makes a change we need, or vice versa? How about merging dependent changes we did not ask for? Which tests must be performed before accepting a change we get from another branch? How about changes that we deliver to another branch? How do we know the exact content (requirements, bugfixes, etc.) of our configuration?

The environment oriented CM-er is often an expert with the CM tools, while the management oriented CM-er is often more an assistent project manager. Many non-CM persons do not see the difference, and do not understand that when having one person or the other makes a great difference in the responsibilities that the project manager and the developer carry.

Perceptions, presumptions and practice.
In my experience, a project manager (or project leader or team leader, whatever name you give) is often assumed to take responsibility for the configuration management issues while he lacks the appropriate knowledge and skills to do it. Project managers usually are skilled in negotiations, managing people, setting up plans and delegating work according to plans, but not with managing configurations on a day-to-day basis. Developers usually assume they have no configuration management responsibility, except for checking out and in files (and making appropriate changes to them) and delivering changes from to other people (and getting changes from other people). The CM system is considered more a burden than a blessing. Satisfying promotion criteria and following predefined change flows is bureaucratic overhead, "only" delaying the change flows, delaying developers and delaying the project. In other words, the CM system performance is really bad, not to speak the build performance.

The CM-er is squeezed in the middle. On one side he is made responsible for assuring that the environment is available and working properly with high performance, and support people using the environment to maximize their productivity. He builds in all kind of automated mechanisms to assure data integrity (or database integrity) and to rule out human mistakes. On the other side, he is made responsible for guarding the consistency and integrity of the data in the CM system without having the authority to hold or delay changes that violate the rules. Many times I have heard that development is delayed because the configurations are not managed properly, while the CM-er spends a lot of overtime (evenings, weekends) to recover the integrity of the configurations he did not mess up in the first place.

Is there a solution?
As for every problem, there is probably no one-best solution. A solution often chosen is by using a "simpler" CM tool. They are cheap (in money terms), have a good performance, have an intuitive and easy to use interface, are integrated with the rest of the development environment, etc. But this "solution" is typically an environment approach, made from an accounting perspective (money talk) or a convenience perspective (lazyness). But it hardly ever solves the management problems that configuration management suffers.
Even worse, changing the environment typically introduces so much additional environmental disurbances and issues (installation, tuning, customizing/tailoring, integration, training), that management is completely focussed on resolving them rather than the configuration management issues that hamper the development productivity in the first place.

In my opinion, the best approach is to keep the development environment as stable as possible allowing people to build up (high performance) routines of co-operation, and having a close look at the total development process flows. This involves data flows (e.g. change flows, document flows, code flows, notifications, reporting) and control flows (e.g. planning, scheduling, assignments, decisions, control boards, RACI definitions, progress tracking, exception handling), but it also involves policies and politics (e.g. authorities, responsibilities, "kingdom building", ownership, discipline and mentality, culture).

Configuration management or a versioned file system

2005-04-18T23:42:00.000+02:00

Configuration management systems, like all computer applications nowadays, are become more sophisticated and more extensive in functionality. In the "old days" organizations had to consider carefully about processes and customizations of CM tools because it took them large investments in effort and time to tailor to organization specific needs. A positive effect was that organizations did actually think before they implemented a solution, and we eager to stick to it because of the difficulties to tailor the processes and tools differently.

Nowadays, CM systems are so easily customizable and tailerable to changing needs that many organizations have stopped thinking carefully about their way of working and are completely focussed on tool performance and using the features of the CM tools anyway they like. Tool vendors wisely anticipate on this trend by making it more and more easy to adapt the tool and adopt whatever process model the customer wants.

Unfortunately, CM is become more and more tool oriented rather than having focus on the underlying concepts of CM. CM systems have become versioned file systems that only perform storage and retrieval of data, support random changes by random people, copying and merging all over the place and losing track of any quality or content attributes. It is become increasingly difficult to convince engineers and managers to apply solid configuration management principles as a means to manage risks. Tool performance, database availability and uptime, reliable backup, restore and data transfers are become increasingly more important than data integrity (which is not the same as database integrity), control of configurations, correctness of status (quality, state in the workflow, responsibility, availability, etc.) or traceability of changes.

"Who care how we got here? As long as we can make money out of it, we're OK!"
"Why bother about [your] configuration control processes? We are responsible for the results, not the configuration manager!"

With pain in my heart I have to admit that the professionalism with respect to configuration management is decreasing, as a result of CM tools making it (too) easy to do everything.

On a crossing with 8 directions you have 2 times more chance of taking the wrong direction with the same amount of consideration as on a crossing with 4 directions. If you than think less because it is very easy to go any direction and return to the crossing, it is even more likely to take the wrong one. If you then have to explain to the people coming next which direction to take, you are likely to tell them a confusion story about which is the "best" direction. Finally, every generation will degradate to a level of trail & error, instead of rational thinking.

Nightmare of component based development (3)

2005-04-18T23:09:00.000+02:00

With component based development comes parallel development. Different components are developed simultaneously, and different product integrations may be performed simultaneously. This leads to the problem to determine which development activity has the highest priority. One product development (or integration) may be higher priority than another, but the technology roadmap of a component may have a long-term impact on product developments to come and thus requires a higher priority.

So even though component based development is a way to achieve efficient development, priorities may be conflicting even beyond the scope of authority of the responsible managers. In principle, the upper manager should decide, but he may have insufficient insight in the all the relevant factors. In my experience, marketing usually dominates technology and thus short-term gains dominate long-term losses.

To protect the value of technology roadmaps, many organizations adopt the concept of ownership. In my opinion, this is an artificial solution as it gives more or less unconditional priority and authority to a single department, which places a rational decision on a political agenda. One of the counter-effects is that the owner of a component does not allow anyone else to modify the component, or even access the internals (source code) of the component.

This introduces another undesirable effect, on configuration management. The owner of a component claims proprietary ownership of the component and thus any change must be performed by or authorized by the owner. But if different product developments run in parallel, product-specific changes to a component (or prototyped changes) are delayed because of limited resources (and thus prioritizing of activities) require the owner to make choices. So, the "product developers" will ask for a preliminary copy of the component to make their own changes, put those changes in the product and only if they prove that the change is viable (i.e. the customer is satisfied with it), they submit a change request at the component owner.

But since the component owner has limited resources, the (prototyped) change is likely to be "reused" and taken over almost entirely without much re-engineering to comply with the architecture. Even worse, the prototyped change may have been developered in a non-standard CM system using non-standard processes (e.g. a quick & dirty implementation). Thus, the perception grows that the standard processes are very inefficient (late results). And since the component owner does not allow "hacking" into his CM system (which increases the risk for instability of the entire code base), the perception is grown that the CM system does not support parallel development in a safe way.

In other words, component based development may be perceived as less efficient and less effective because the efficiency and effectiveness is limited to strict compliance with the rules. As a result, breaking the rules will make component based development even more ineffective and inefficient which encourages the decision makers to reject the approach altogether.

Is component based development doomed to fail by its success? How can we prevent that from happening?

Nightmare of component based development (2)

2005-03-25T23:48:00.000+01:00

Before going into some ideas for the integration process, let me tell you something about the history. The previous project was a monolythic system developed on a single branch. Although the intention was to have a daily build, practice showed that it was not feasible to make a stable system configuration every day. So, the cycle was delayed to a weekly cycle.

However, since we were facing a large development team (and a large system), all changes made in a week was too much to make a stable configuration on a weekly basis. Delaying more would probably make it worse.

So that is why we came up with the idea to reduce the development scope to subsystems rather than the whole system. Architecture was changed and SCM was changed too, into subsystems. But now we are facing the problem that there are too many trajectories running in parallel and delivering every week a new subsystem configuration for system integration. In addition, the number of dependencies between subsystems became unmanageably large.

So we came up with the idea to reducing the amount of configurations by clustering those subsystems, not into a single system (as we hard in the past) but into four or five subsystem clusters. For each cluster, we can make a weekly or even daily build and for integrating those clusters together we can make a weekly or (bi-)monthly cycle.

However, this approach implies that witin the clusters there is early integration, while across the clusters there is late integration. This implies that the clusters must be chosen such that the number of inter-cluster dependent changes are minimal. However, when we have an inter-cluster dependent change, it must be developed within two or more clusters at the same time and pre-integrated (and tested) before it is officially integrated at overall system level. But crossing the boundaries of clusters will increase the managerial complexity again, possibly forcing clusters to be deliver simultaneously to system integration.

As you see, the problem is not very simple. If you have any idea how the next step could look like, don't hesitate to send me a comment.

Nightmare of component based development (1)

2005-03-24T08:12:00.000+01:00

At one of the companies where I work, they have introduced component-based development. The total system is divided into subsystems and each subsystem is divided into components: (1) the subsystem's external interface and (2) the subsystem's internal "body". The project is divided in a number of sub-projects, each responsible for a number of subsystems.

After several months of experience with this approach, we do not seem to get the integration process right. The primary reason is that each subsystem is developed against a "stable" system baseline, where the system baseline is the integration (or composition) of individual subsystem baselines. But each of the subsystem is evolving in parallel with the other subsystems, so when trying to integrate newer baselines of all subsystems, the configuration is a composition of subsystem versions that have never worked together before.

Some consequences:

Build failure
Smoke test failure (verifying only basic functionality)
Regression test failure (verifying former functionality, but not new functionality)
Integration test failure (verifying new functionality in an integrated environment)

As a result, subsystems must be rebuilt against different configurations and possibly need some extra modifications. Even more, those small modifications may (and do) result in additional inconsistencies, some formerly obscured by other problems, some introduced by the new modifications. This causes delays in the system integration. Consequently, the next "stable" system baseline is delayed and consequently the subsystems can not develop against it (unless they develop against an "instable" configuration).

Our struggle is how to get this right, so if you have ideas then do not hesitate to give me some suggestions. I will follow up on this subjects in my blog.

Company blogs behind firewall

2005-01-29T09:50:00.000+01:00

Information sharing is one of the more difficult issues in modern companies. Many hours are lost in meetings to tell people about important information that they could have read in 5 minutes. Time is wasted because people are out of sync with the real status of the project.

I read an interesting blog from Michael Conté called Enterprise blogging in practice about his experience with introducing blogs within the company and on the Yahoo! group Scrumdevelopment is requested for reactions.

Gmail account for free

2005-01-12T08:01:00.000+01:00

If you are looking for a free gmail (Google mail) account, then drop me an email and I will send you an invitation. I have 10 invitations left.

Music is some kind of soft-ware

2005-01-09T17:51:00.000+01:00

Making software, making software development processes and making music have a lot in common. To me it gives excitement and joy to do it, and it helps me relax.

On december 12, 2004 I played at a small concert in the public library of Eindhoven. They also made some photographs.

Software is knowledge, not a product

2005-01-06T08:23:00.000+01:00

In a post on the Extreme Programming Yahoo! group there was a mention about an article The one minute risk assessment tool. In this article it is claimed that one of the main risk for failure of software projects is the perception that software is a product instead of an embodyment of knowledge.

Software Factories

2004-12-31T09:58:00.000+01:00

Brad Appleton reminded me of 4 articles about Software Factories on the Chicago Agile Developers forum.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/softfact3.asp
http://theserverside.net/articles/showarticle.tss?id=SoftwareFactories
http://allconsuming.net/item.cgi?isbn=0471202843
http://www.sei.cmu.edu/SPLC2004/

In particular the article from Jack Greenfield of Microsoft seems interesting. It is a 4 part series, so soon I will have a look at the other parts.

Managing complex projects

2004-11-15T22:31:00.000+01:00

Next Thursday, November 18th, there will be an event organised by Bits&Chips about managing complex projects. Sure, it will be mostly in Dutch but it will be interesting anyway.

The challenge for software projects is to increase the productivity significantly; not by 10% or 50% but with 10 to 100 times or more. Will current process improvement initiatives achieve that? I doubt it. In my opinion, we need to reduce the size of projects instead of increasing it, we need to replace manual work and communication by machine work.

Process shift

2004-10-15T09:06:00.000+02:00

Motorola has determined through data analysis that processes tend to shift over time. They can it Long-Term Dynamic Mean Variation. They claim the shift is between 1.4 and 1.6.

See http://www.isixsigma.com/library/content/c010701a.asp

Measurements and reports

2004-10-06T22:11:00.000+02:00

Today I was confronted with a question what SCM measurements we would need and what SCM reporting. Although measurements are often put in reports, our objective was quite different for the two.

The SCM measurements were intended to give us information about the SCM processes. By measuring some primary indicators we want to get an idea about how accurate SCM processes are followed and how efficient the SCM processes are. For example, suppose a subsystem baseline is created more than 10 times a day, there probably is something strange going on.

On the other hand, SCM reporting was intended to support the operational project execution. For example, to support the integration process the integration managers need to know what changes are made in the new baselines compared to the previous baseline that was integrated. Managers may argue that this is listed in the baseline report, but the author of the baseline report has to get the info from somewhere. As the SCM system keeps track of all changes made to the product, SCM reporting may provide the info the integration manager needs.

Other examples of SCM measurements are:

Number of parallel streams that are used
Number of deliveries from a developer to the integrator, per day
Number of changes per delivery
Amount of time to get a change of one developer to another, going through all the formalities, quality checks (build, tests, reviews) and data transfers (deliver, export, import, install)
Number of problem reports solved per week, and the trend over the past year.

Other examples of SCM reporting are:

Changes made in a baseline compared to a previous baseline
Problem solutions present in a particular stream
Problem Report and Change Requests found a particular release
Persons accountable for creating, testing, integrating a particular change
Evidence of a particular SCM promotion step

I do not claim that the distinction between SCM measurements and SCM reporting is universal. But that is what I ran into today.

The best solution is not always the best solution

2004-09-27T21:43:00.000+02:00

It has been a hard week last week. Being involved in a large process change process for a software organization, I have been foreseeing a great deal of problems that are now materializing in reality. We are on the go for several months now, preparing new process definitions, changing software architecture, changing software archive structure, changing build processes, changing supportive tools and scripts, training people, etcetera.

One of the issues I have expected is that the people are just continuing their old habits, their old ways of working, in the new environment. But the new environment has far more flexibility on one side, and more control mechanisms on the other side. So what happens is that the new flexibility is not used, or it is used in an inefficient way and the new control mechanisms are more and more getting in the way. The result is that process are becoming less efficient and less effective, even though the objective was (and is) to gain development speed, to gain management ability to steer in the right direction and to gain visibility of the process.

Now I am wondering: Should I have taken action earlier? In fact I did, but nobody listened. Why did nobody listen? Because they did not have a problem yet. One of the hardest things for a (change) consultant is to change something that is not a problem for those who have to change. They simply are not open for change, even though they may want to. Resistence is not a matter of attitude (although it often is), but it is a natural byproduct of being inexperienced in changing. Even worse, many of the quality programs aim for reproducibility, predictability and repeatability, not for change in spite of the term Process Improvement".

But now they know! Now they are confronted with many different things that do actually go wrong, and that have to be corrected immediately because the project is suffering delays. Of course they blame the new process! And they know it should be address right now, a solution must be ready by yesterday. In other words, time is right for change now, although we do not really have enough time and opportunity to make the change because the project is delaying by every day. And in the past, when we had the opportunity to change things, it was simply impossible to do so.

For many, many years I have fought against these windmills, trying to change people, processes and the organization to prevent them from running into problems, before the time was right. It was a hard and endless struggle and in many occasions my evaluation and my carreer suffered from it. Now I have learned that knowing the best solution is a handicap sometimes, since it is not always the best solution at the time. I have learned not to try to convince people too hard to do something about it, but just to prepare them that it will go wrong. And then, I have learned to be patient until time is right. Act too early, and you will spoil the opportunity to make the difference.

If it's possible, it's allowed

2004-09-19T09:14:00.000+02:00

Last week I had a meeting with a customer that is in the process of implementing a new configuration management system. We had a tough discussion about building in security measure to protect the system from malpractice of software developers.

Surprisingly, they were very much concerned about deliberate, intentional misbehaviour of their software developers. For them it was even more an issue than intentional, accidental faults. The argument was that intentional misbehaviour may be very difficult to detect because the engineers try to be extremely smart on that. The risk they are concerned about is that after delivery of those changes, the integrator may not discover problems in the system through the build and smoke test. So the problem is propagated to system level and may be even to the customer.

What they try to do is maximise the security mechanisms to make it is impossible for developers to bypass it. In my opinion, it is absolutely foolish to even try it. First, you will never outsmart those saboteurs and try it takes extreme costs and efforts. A better approach is to build in logging and detection mechanisms. Then, if someone runs in an unintentional malpractice you can build in protection mechanisms, but if someone deliverately hacks the system he should be warned first and fired next regardless of his other competences and knowledge level. It is better to spend the money on finding the right people and on try to secure the system against those terrorists.

What do you think we should do about it?

Dirty hands

2004-08-31T22:02:00.000+02:00

Being a consultant on software configuration management I am involved in investigating, assessing processes, talking to people to find out their needs and their favorite habits in their work and the reasons behind it, discussing about possible changes or improvements, reading documentation and reports, writing reports, considering and discussing ideas and possible options, alternatives and impact, convincing people, training or guiding them, etcetera etcetera.
In short, it involves a lot of talking, thinking, listening, writing and reading.

How nice it is to, now and then, be operating the keyboard to work on the commandline of a CM system, write trigger scripts and witness them actually working and doing what you want it to do, and get out the data you asked for.
How nice it is to be working in a flow, concentrated for several hours forgetting all notion of time? That's the real work!

Sometimes I wonder how managers cope... doing nothing the whole day long, day in day out, bearing heavy responsibilities and taking hard decisions. I am so glad I am a consultant, not a manager.

The Art of Software Creation

2004-08-28T23:50:00.000+02:00

To me it is highly arguable whether software creation is an art. In the early days, the challenge of software was to find the most efficient or the most effective algorithms to crack a mathematical problem. Nowadays, most of the creative art has made place for crafted engineering: integrating existing concepts and technologies into new systems.

Nerds and wizkids, able to work in isolation and inventing the most unexpected solutions have been replaced by architects and engineers working together in efficient social structures to build and integrate predictable results in a predictable way. Beauty and cleverness have been replaced by control and productivity.

Did all the fun disappear then? No, it has changed. Instead of being a soloistic challenge (like athletics), software development has become a team challenge (like football). And instead of breaking world records time after time, the objective is to play in the champions league beating the competition. It requires completely different strategies and tactics. To me, being in a winning team is more fun than being better than everybody else.

Software should be about change

2004-08-23T21:43:00.000+02:00

It has been said many times before: "If there is one constant in nature, it is change."

Yet, in many software development organization people are striving for reproducibility, predictability and (management) control. Plans are made and approved like they are carved in stone. The software architecture is designed to prepare for extension of the product, allowing it to scale for more functionality, but the software architecture itself is hardly ever designed for change. A a certain point in time, a major refactoring is needed to get the architecture going again.
The software implementation is often rigid and optimizations for performance have often lead to various unexpected side-effects when the implementation is changed. However, to accomodate for new and extended functionality, the software must be able to change.

And then the people. Products are becoming so complex and extensive that nobody has a total overview of the system. Only a few veterans still know the original ideas behind a lot of the concepts and principles that are used and never questioned, and above all never changed. And they are not changed because you should not fix it unless it is broken.
Not even the crew working on the product development can bear much change. The learning curve of newbies is too long and the risks of losing valuable knowledge are too high. And manu people resist change of habits simply because they don't like to change their habits.

What was the advantage of software again? It is much easier to change than hardware, much more flexibility. It is software. But in practice, software is hard to change. And when it needs to change, business demands a solid statement of profitability. Entrepreneurs are hardly found under established organizations.

In some occasions companies are lucky: they get into business trouble through the way they are organized and the lack of change. Managers are forced to accept change, to invest in entrepreneurship. But again, only very few learn from it to design the product and the organization for future change.

Need a memory extension

2004-08-23T07:52:00.000+02:00

Don't you have that all the time? Laying in bed, half awake, half asleep, thinking about the things that keep you busy during the day. All of a sudden, you have a smart idea, an idea you did not think of before. Still having your eyes closed because it's still too early to get up, you try to memorize this idea. Then, you fall asleep again and when you wake up the only thing that you remember is that you had a smart idea... But you lost it.

Only once in my life, I had the courage to get up and write it down. It turned out to be a smart, but impractical idea.

But the worst thing is that these kind of things not only happen during the night, but also during the day. No, I am not sleeping during meetings but I do get all kind of smart ideas during meetings, conversations, driving my car, dinners or having a walk with my dog. And every time I am unable to remember them afterwards.

Wouldn't is be a good idea to have a memory extension that would record these thoughts?

Reproducing old configurations with tracking info

2004-08-22T21:51:00.000+02:00

One of the duties of configuration management is to be able to reproduce old configurations. For this purpose, configurations are baselined, labelled or committed. When you need the configuration, you just create a workspace that looks at the old baseline. Using branching, one could even make changes relative to the old configuration (if the CM system supports it).

Now surprisingly, to me at least, in the old configuration the supportive (meta) information is not reset to the old state. For example, the database of Defect records is not set to the old state. If we have solved a problem recently that was already known (and left unresolved) in the previous release, the defect remains in resolved state even though we have a workspace where the problem still exists. Isn't that plainly a wrong representation of the reproduced state?

If we then decide to resolve the problem on the old release, we need to make a new defect record. This new record will have a submission date after the release we try to solve it in although the problem itself was discovered before the release. Wrong representation of the truth again!

Wouldn't it be correct to have other (meta-information) systems support reproduction of old configurations and branching in the same way as the configuration management system does?

Developers want to be dumb

2004-08-20T21:42:00.000+02:00

Today I got another confirmation that developers aren't dumb, they want to be dumb.

We have defined a development process with several promotion levels. The system is divided into subsystems and baselines of the subsystem need to be promoted to published before other subsystems are allowed to use it. Today, one of the integrators came to me asking whether it was possible to prevent developers from using baselines at a lower level.

"Why", I asked. The reason is that if developers use baselines at a lower level, they may submit extra problem reports about the subsystem they use. "But they know they use a baseline that has not been published for use yet!", I replied. But developers simply do not care! They will take any baseline from the other subsystem, regardless of it being released for use or not. And if they run into problems doing that, they will blame SCM for it:

Motto: "If it is possible, it is allowed"

Developers aren't dumb, they just act dumb and do not care about empowerment, responsibilities or plain professionalism. How can we ever protect them against themselves?

First entry

2004-08-19T22:02:00.000+02:00

Every journey starts with a first step. I have never been confronted with Blogs before so I am curious how it is to make and maintain one. A lot still has to be done to make this a decent source of information.

My objective is to use this blog to capture my thoughts and experiences at work, possibly as a means to share it with other people, possibly just as a reminder for myself.