Mike MacDonagh's Blog

Somewhere in the overlap between software development, process improvement and psychology

Tag Archives: development

Collective nouns for software development roles

An embarrassment of Project Managers

An impasse of Architects

A confusion of Business Analysts

A mob of Developers

A silo of Testers

A brethren of Scrum Coaches

A waste of Lean Consultants

A conspiracy of Process Improvement Consultants

People are important, not roles! But recently I saw a weekly team meeting for a project that had 12 project managers! I thought it was a joke at first.

Can you think of any others?

How to make real progress in a software project

I’ve not been blogging much this year because I’ve been crazy busy writing software (more on that soon I hope). As you might expect I’ve changed my ways of working more often than process improvement consultants change the name of the process they’re selling but one key thing always seems to drop out whether I’m working on my own, with a team, a team of teams or a globally distributed team.

Do the top thing on the list, whatever it is.

Don’t do anything else until it’s done.

Or in process speak: “Reduce the WIP and clarify the Definition of Done“.

Too often I fall into the trap of doing the most interesting thing from the list, which normally means the most complex. And far too often I get carried away with the next interesting thing before finishing something. Both of these lead me to have far too many things in various states of progress all interfering with each other and me with no idea of how well I’m doing. And that’s assuming I actually know what “finished” means.

Software is complex enough without us making it harder with processes, remember the KISS principle?

Linux GUI Development: Lazarus 1.0 Review update

A while ago I wrote a review of Lazarus 0.9.30 and it came out with the 63% mainly because the installation process was so horrible. Well now it’s almost a year later and v1.0 has been released so it’s only fair I update my comments…


It’s still not exactly shiny but, and it’s a huge but, it is simple and it works! 🙂 To install on Linux I had to download 3 .deb files (1 for Lazarus, 1 for the compiler, 1 for the source) and then I could install them by simply doing:

doing sudo dpkg -i *.deb

It’s worth tidying up any old Lazarus installs first which you can do by running my script here.

Downloading *.deb files and installing them is pretty normal for linux users so although it’s not a shiny wizard installer or single command it is simple and most importantly it just works! I’m going to upgrade this from 1/19 to 8/10

First Impressions

A lot of the little niggles have gone away and it’s a much more stable, solid feeling environment. It does still load up with a million windows (Delphi style) and feel a little old fashioned (a lack of wizzy GUI controls and UI customisation, single window mode etc.) but being open source and written in itself I can change these things if I want to reasonably easily. In fact loading up the AnchorDockingDesign package makes the IDE a docked single window affair and there’s plenty of 3rd part controls to download and play with.

Normal multi-window interface for Lazarus
Lazarus as a single window IDE

There’s still no multi-project support and recompiling the IDE to get a new component on the toolbar feels a bit weird even if it does work perfectly well. I’m going to stick with 6/10 for those reasons.

The GUI designer and Code Editor haven’t really changed since my last review and so they stay happily at 9/10.

Language features

The handling of generics has improved since I last looked at Lazarus and all seems to work pretty well now 🙂

Otherwise nothing much has changed, no  multicast events or garbage collection but those things don’t really slow me down much. That’s why I gave it 6/10.

Despite the lack of some of these things the language has always been and still is quite elegant (other than the nasty globals), it’s got an excellent simple OO implementation and it’s really easy to quickly put an app together – oh yeah and it’s cross platform.

Cross-platform and backwards compatible

Lazarus works on windows, linux and mac. You can write a bit of code and natively compile it on each platform making for lightening fast code with no external dependencies. Write once, compile anywhere. You can already (partially) compile for android and other platforms are possible – anywhere the fpc compliler can be ported your code could work. That’s pretty impressive and it just works brilliantly.

Similarly all that ancient Delphi code can be loaded up edited and compiled and largely just works. Brilliant again. For that reason I’m going to bump up the language features to 8/10. (9 when android is working well).

I’ve not tried the feedback process again since v1 so I’m going to leave it at 7/10.


Despite it’s old fashioned feel in some places it’s simplicity is elegant and actually quite powerful. If you know the Object Pascal/Delphi language then it’s so fast to create good looking cross platform apps that it’ll knock your socks off.

When I pick up a new language I tend to do a challenge to load an xml file into a multi-column listview and create a details form to edit the selected row. In Java, something so apparently simple is a massive pain due to the imposition of the MVC pattern on everything. In C# it’s pretty easy, I can go MVC or not. In mono it’s reasonably easy too, although not the same easy and not as easy to get away from MVC.

In Lazarus it’s really easy, and it works fast and well on 3 major platforms. That’s a killer feature.

Category Score
Installation 8/10
First Impressions 6/10
GUI Designer 9/10
Code Editor 9/10
Language Features 8/10
Feedback process 7/10
Cross-Platform 10/10
Overall 81% – Easy to use and powerful

In my previous review I said I couldn’t really recommend it, and that made me sad. Now I can recommend it, in fact it’s quickly becoming my technology of choice for linux gui development, because it’s quick to put things together and they look good. Just maybe Lazarus is living up to it’s vision and bringing Delphi back to life, but bigger and better than it was before!

SimpleGit is developed in Lazarus

Process vs. Tools

What’s more important: Process or tools?

I’ve sat through numerous arguments with people trying to work out whether process or tools are more important to their software development effort. The arguments go along the lines of:

Process Geek: Tools are just the things you use to do the process, the value is in the process. Let’s do a process first roll out.

Tools Geek: Tools are the things people actually use. Process is academic and is constrained by the tool features anyway. Let’s do a tools based roll out.

Sadly both of these are real life quotes from people I’ve worked around in the past. I won’t embarrass them by naming them because they’re both really wrong. For me the real value is not in the tools or the process but in the people. Process and tools are something that you add if the people need them.

Minimal Tooling

For me the best planning tool is a whiteboard. The best architecture and design tool is also a whiteboard. I like to capture some info about what I’m doing and how close I am to achieving my goals, some really simple measures. The best tool for that is probably Excel, despite my love of Open Source. Other than that I need to manage some lists of things like requirements (stories/use cases whatever), defects and whatever other bits the team thinks are important. They might fit on a whiteboard but typically we want to have some attributes on them, be able to sort them and link them. The one downside of a white board is the lack of drag and drop. I’ve used a few different types of smart board and active touch screens but none of them have really given me the smooth experience I want.

The one bit of tooling I really need is my IDE + SCM + Continuous Integration.

Minimal Process

This is potentially a can of worms if I go into things like process kernels and ideological arguments about different agile approaches and practice collections. There’s no such thing as a process silver bullet so for me though it’s all about the team and being effective. Teams need to:

  • Have Clear Obligations
  • Have Clear Business Priorities
  • Seize their autonomy
  • Have the relevant technical skills and resource availability
  • Be active in actually doing their work (seems obvious but it’s something a lot of processes seem to hinder rather than help)
  • Demonstrate visible progress (via working software not a tracking gantt chart)
  • Continuously improve themselves (because no way of working is perfect)

This list based on the 7 Habits of Agile Teams by Roly Stimson

So why go more complicated?

Unfortunately life is rarely simple. Many teams work in complex environments where a number of factors might make them choose to need more than this kind of minimal set including things like physical distribution; audit, regulatory or security constraints; cross-team interaction in system of systems environments, more people etc.

When faced with increased complexity it might be appropriate to add more powerful tooling or development practices. The more people involved in a project the harder it is to herd all of those socially complex cats into working together.

This is why ALM suites exist ranging from plugging together some open source bits like git, SimpleGit, jenkins, agilefant, bugzilla etc. to commercial vendor products like IBM Rational RTC (which does agile planning, work item management, scm and build in one tool) and other IBM Rational Jazz tools – it’s worth noting that you can also get RTC for free for just 10 users or for academic/research use on jazzhub.

Alternatively there’s Microsoft TFS for source control, work item tracking etc. tying together existing Microsoft stuff like MS Office, Visual Studio and sharepoint if you’re a more Microsoft focussed development house.

Of course you can also mix and match this stuff to a greater or lesser degree with various integrations. No toolset is a silver bullet however and each have their own problems.

So what’s my point?

My point is that process and tools need to reinforce each other, that both should be selected based on the needs of the team and the environment the team has to operate in. In the process vs. tools argument both lose out to the people. People in a development organisation create value, they just use tools and process to do it.

Scaled Agility: The Project Forum

This blog is an extract from the Project Forum practice: Holistic Software EngineeringThe Project Forum

When it might be appropriate

  • In situations where multiple competing stakeholder groups with different agendas are required to work together
  • In situations where multiple product groups need to collaborate on a bigger outcome
  • Where there is a conflict in direction, resource management/ownership or scope between collaborating groups
  • System of systems development

What is it?

The Project Forum is an application of agile philosophy to large project structures. Rather than impose a hierarchy of decision making from the Project Manager downwards the Project Forum is a virtual team in the middle of all stakeholders.

The Project Forum is a self-organising democratic group that balances competing voices and concerns, owns high level scope and architecture, runs the high level release train and performs integration activities for the product.

Use of the Project Forum practice does not prevent any communication directly between contributing groups it only provides a vehicle for that conversation when it’s relevant for the wider project.

From Traditional to Agile at ScaleThe Project Forum practice is an example of Agile at Scale combining social business practices, technical software practices and ways of working to make a simple way of doing big complicated bits of work.

Read more of this post

Simple software project measures

I’m not a big fan of metrics, measures, charts, reporting and data collection. I’m not terribly impressed by dashboards with 20 little graphs on showing loads of detailed information. When I’m involved in projects I want to know 3 simple things:

  • How quick are we doing stuff?
  • Are we on track or not?
  • Is the stuff good enough quality?

There can be some deep science behind the answers to those questions but at the surface that’s all I want to see.

Organisations need to know that teams are delivering quality products at the right pace to fit the business need. To achieve this goal teams need to be able to demonstrate that their product is of sufficient quality and that they can commit to delivering the required scope within the business time scales. If the project goal may not be achieved then the business or the team need to change something (such as scope, resources or time scales). This feedback mechanism and the open transparent communication of this knowledge is key to the success of agile delivery.

The goal of delivering quality products at the right pace can be measured in many complex ways however, when designing the Project Forum agile at scale practice we looked at just 3 measures. In fact I should probably call them 2.5 measures as the throughput/release burnup can be considered mutually exclusive (if you’re continuous flow or iterative). The most important measure is people’s opinions when you go and talk to your team.

Simple Measures Dashboard

Note: in the measures section I often refer to “requirements” as a simple number, this could be a count, a normalised count, magnitude, points, etc. it doesn’t matter what’s used so long as it’s consistent.

Read more of this post

What does “Agile at Scale” mean?

There’s a lot of talk in the process improvement industry about the meaning of “agile at scale”, devops, lean and agile for a number of reasons. One reason that I’ve seen in successful agile organisations is that as development maturity increases with true agile adoption bigger problems present themselves. This is the natural progression of the science of development, what used to be considered complex (like Object Orientation) is now normal, a commodity. Innovation in ways of working is happening at the organisational, cross-team, cross-product level.

For me agile at scale (I’ve got fed up of the quotes already) means a couple of different things:

  • Repeating agile successes embodied in a team across an organisation (scaling out?)
  • Applying agile thinking to cross-product projects
  • Applying agile and lean thinking to development organisations
  • Applying agile and lean thinking to high assurance environments like medical, security, financial, safety critical, audited, regulated businesses.

Agile and lean? Yep, both with lower case letters. I’m not particularly interested in ideological approaches to software development, I believe strongly in taking the best bits of whatever processes, techniques, practices etc. you find externally, mixing them up with internal practices and ways of doing things to develop simple, pragmatic approaches to ways of working. Both agile and lean schools of thought promote minimising unnecessary work, shorter delivery cycles and higher quality, continuously learning lessons and empirical decision making.

The agile manifesto gave us:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Some great practices have evolved for applying agile and lean thinking like scrum, kanban etc. However all of the complex organisations I’ve worked with have found that there’s still space for more thinking in terms of how to run a software business, how to deal with big complex system-of-system problems, multiple competing stakeholder sets, programme and portfolio management etc. Not surprising really because the agile movement wasn’t about trying to do any of that stuff.

However organisations who are successful with agile transformations want to apply the successful open and honest philosophy behind the agile manifesto to other parts of their business as well as bigger and bigger projects and programmes because the results of “doing agile” (I promise I’ll stop with the quotes soon!) are so attractive when it’s done well, namely:

  • Shorter delivery cycles, higher quality
  • Deep engagement between customers and development teams leading to respect, collaboration and better morale
  • Quick identification of when things are starting to go wrong

Consider the following model, not uncommon amongst large organisations:

Diagram of nominal large inter-dependant organistion structure

This represents a typical software department or vertical section of a software department with a portfolio that provides the funding for work. Big portfolio’s are normally broken down into a number of programmes which in turn may levy high level requirements onto organisations (organisational sub-divisions that own multiple products) which may affect both legacy and new product development. Often within a vertical section of a business there will be many cross-dependencies in terms of requirements, technical dependencies etc. For many large businesses this picture is overly simplistic, indeed I’ve not included things like projects, component teams and a variety of business organisation constructs like product centres, feature teams etc.  So how do you apply agile and lean philosophy to this lot and more?

You can’t simply repeat the same practices recursively throughout an organisation to deal with larger scale complexity.  Imagine a chain of scrum-of-scrums, daily stand-ups at every level (at the same time, or staggered to allow representation up the chain?), sprint plans at programme level etc. What about if the business is regulated, audited, security focussed, high risk financial, safety critical, etc.

Ok, so what’s agile at scale then?

Agility at Scale is applying the spirit of agility and lean thinking if not the letter to these bigger problems. It’s about:

  • Valuing individuals and interactions, encouraging collaboration, reducing layers of communication over processes, tools and hierarchy
  • Valuing working software in the form of quality releases from short development cycles over comprehensive documentation, business analysis, enterprise architecture documentation
  • Valuing customer, business, developer and operations (see DevOps) collaboration over contract negotiation
  • Valuing good governance, transparency and honesty in progress, plans, costs and impediments over regular reporting
  • Valuing responding to change over following a plan at all levels of the business

(Borrowed from the Holistic Software Manifesto)

Agility at scale is focussed simply on reducing unnecessary bureaucracy, reducing time to market and improving value.

So how do you achieve it?

The application of:

Of course each of those (and more!) is a complex can of worms in itself. A lot of these higher scale practices are only just emerging from high maturity complex (post-)agile organisations but in time more of those things will turn into links.

A good example of  “Agile at Scale” in action is the Project Forum practice

As always this blog is  a stream of consciousness so please, let me know your opinion?

How to do maven releases with Jazz SCM

I’ve previously blogged on structuring maven multi-module projects to work well with m2, eclipse and Jazz SCM. In this post I’m going to write about how to do releases because it’s not as straight forward as you might hope and expect. This blog is explicitly about using maven 2.2 and IBM Rational Team Concert although it will apply to various other previous versions. Later versions of RTC should (I hope) alleviate some of the problems and the Jazz SCM Maaven plugin is being actively work on.


During development or maven projects we start with a label such as 1.0.0-SNAPSHOT which reflects the current development build. Over time the development snapshot might be occasionally pushed to a maven repository as a “snapshot release”  if it’s roughly stable so that dependant teams can get the dev version if they really want it. In time development gets stable enough to release the definitive 1.0.0 so the -SNAPSHOT is stripped from the label and the version is pushed to the repository as a proper “release” for other teams to depend on. At this point a new number is selected and development continues on the new label such as 1.0.1-SNAPSHOT which might be occasionally pushed etc.

Diagram showing how releases and version numbers work with maven

The problem

This process works pretty smoothly in a lot of contexts as the release is done by issuing a command line as simple as mvn release and maven’s smart enough to work out the rest. The problem comes in the context of Jazz SCM for a couple of reasons:

  1. The Jazz Maven SCM plugin is still in early development so doesn’t do everything well and some things not at all
  2. The Jazz Maven SCM plugin incompatible with the maven release plugin because it requires the pom scm tags to be written in a way that the release plugin can’t read
  3. The jazz scm plugin insists on outputting your password in cleartext all over the logs so you can’t do it as part of an RTC build without exposing the build user password (which depending on your organisation might not matter or could be a huge deal)
  4. Both maven and rtc use the word snapshot for different purposes and other terms like “baseline” and “tag” are synonymous

The solution

Write a little script to work around the problems with the following requirements:

  • All published version numbers in the maven repository must be reflected by RTC scm snapshots
  • The process of releasing is simple to use

To make this work I’m actually dumping the use of the Jazz Maven SCM plugin as it’s not yet developed enough to be useful. Instead since every build happens in RTC occurs in a snapshot here’s the process:

  1. Green Build in RTC (optionally promoted to RTC Release) with a known snapshot name e.g. v1.0.1 release
  2. Integrator/Releaser/Committer/Nominated dev runs custom mvn-release script on their local machine
  3. Sits back and watches, feels good

Here’s the pseudo-code for how to do it all. One of my clients is developing this currently and I’m reasonably optimistic that they might open source (or allow me to) the full script. However if you’ve got a bash monkey working for you it shouldn’t be hard to develop this up pretty quickly.

Currently this process needs some parameters which could be passed in or the user could be prompted. I prefer to pass in and prompt so that the script can be invoked from a remote process (like a build server) passing in properties or can be interactive if a user invokes it. Parameters required at least somewhere along the way are:

  • rtc user name and password
  • is this a snapshot release or proper release
  • rtc build snapshot
  • new version number to base label (if doing a proper release)

CURRENT_VERSION = getCurrentVersion(pom.xml) //1.0.0-SNAPSHOT

//If just doing a basic snapshot release
scm create snapshot "CURRENT_VERSION"
scm checkin & deliver
mvn deploy

//If doing a full release
PROJECT_NAME = getCurrentProjectName() //basename of current directory
NEW_WKS_NAME = create new rtc workspace in /tmp/rtc/workspace/RTC_SNAPSHOT_NAME/
load temp workspace with contents of RTC_SNAPSHOT_NAME
cd /tmp/rtc/workspace/RTC_SNAPSHOT_NAME/PROJECT_NAME
//Generate Release
mvn versions:set -DnewVersion="RELEASE_VERSION"
scm create snapshot "RELEASE_VERSION Release"
scm checkin and deliver
mvn deploy

//Generate new development starting point
NEW_VERSION = AskUser(); //1.0.1-SNAPSHOT
mvn versions:set -DnewVersion="NEW_VERSION"
scm create snapshot "NEW_VERSION Initial baseline"
scm checkin and deliver
//don't do a mvn deploy as that would be the user choosing to run this script choosing the snapshot-release option

//Tidy up
scm delete workspace NEW_WKS_NAME

The advantage of running this script creating a temporary local workspace and running from there is that you can do this from the command line without closing eclipse (or invoke from Eclipse as an external tool configuration). Also it isolates the release process from any possible local changes in the /Releaser/Committer/Nominated dev’s workspace.

Until the Maven SCM plugin comes of age I hope this helps.

Working with Maven multi-module projects in RTC Jazz SCM with m2

I’ve been working with Maven projects with m2 for a while in RTC Jazz SCM so thought I’d post some notes. For reference this post covers using RTC v3.x things may change in the future. If you’re not using m2 then I’d suggest you read this blog by Philippe Krief.

First of all it’s important to understand that RTC v3 has limited support for Maven. You can setup a build definition which can call a maven goal (such as a local install) easily enough but that’s about it. The RTC build mechanism is basically a cron job with a nice web (like Hudson/Jenkins without the plugins) and Eclipse front end, it doesn’t have a deep understanding of Maven.

The whole point of Maven over Ant is that it does a lot by convention rather than specification, however in most advanced Maven project I’ve seen pom files are as big as equivalent Ant + Ivy files. Regardless I still think Maven with the excellent Sonatype Nexus is awesome (although I also like the structured bash/batch like nature of Ant as well).

Most serious Maven projects are multi-module. This is because component based development is a good thing (shameless employer plug, but it’s true, it is a good thing). Most (tending to all) multi-module projects have the following structure where “O” is a folder and “-” is a file, considering a hypothetical ProductX:

– pom.xml (the parent pom for the master/uber/product build, lists child modules)

– various files at the root of ProductX

O ModuleA

– pom.xml (for ModuleA)

– various ModuleA root files

O various ModuleA folders of stuff (such as src)

O Module B

– pom.xml (for ModuleB)

– various ModuleB root files

O various ModuleB folders of stuff

If you want to work with this stuff in RTC Jazz SCM then you need to balance the constraints of Maven m2, RTC and Eclipse. If you’re considering doing this then you’ll probably be considering moving existing Maven projects to RTC, in which case you may find a previous blog on a manual migration script useful. The only edit to this I make for Maven is to separately import the parent from the children if flattening the structure (although in most cases I wouldn’t recommend flattening).

The constraints playing against each other are:

  • Maven and plugins expect sub-modules to be in child directories as in the tree above
  • RTC doesn’t allow both an Eclipse project and root files to be at the root of a component
  • The simple case of Eclipse and RTC SCM interacting during a load from the server restricts Eclipse to only seeing projects which are represented as folders at the root of the local Eclipse workspace containing .project files.
  • Eclipse doesn’t really support parent and child projects.

I’ve found there are a number of approaches, none are perfect:

1. Flatten the structure (my opinion the worst option)

You can edit the parent pom.xml to reference the sub-modules as ../ModuleA etc. although the Maven release plugin (amongst others) don’t play well with this. Also, and somewhat fundamentally, you shouldn’t have to restructure your code based on your SCM tool.

2. Only load the relevant bits (my opinion is it’s sometimes ok)

You could just load the child modules you’re currently working on and then unload (remember to delete local files or you hit a bug) and then reload the parent when you want to do a “big” parent build. Frankly this is unacceptable from a developers perspective and will fail anyway if there’s a dependency on the parent from the children. Although in theory this may be frowned upon it’s quite common and so needs supporting by the scm tool.

3. Load then import, with auto-refresh (my preferred option)

This one is going to be more than one paragraph….

Prediction fulfilled ;p Anyway… Currently your developers may be used to a scm system where they load/copy/access files from the scm system on the local filesystem and then do an Eclipse -> Import Existing Maven projects to get all of the various goodies.

If you import the multi-module project as above but with a root folder (as an eclipse project) so it has the following structure:

O Product X


– pom.xml modules)

– various files at the root of ProductX

O ModuleA

– pom.xml (for ModuleA)

– various ModuleA root files

O various ModuleA folders of stuff

O Module B

– pom.xml (for ModuleB)

– various ModuleB root files

O various ModuleB folders of stuff

Then when you do a load from Jazz SCM you’ll get in the Eclipse Project Explorer (or equivalent) ProductX correctly detected as a Maven project (or an Eclipse project with a Maven nature for the pedantic amongst you).

You can then do a normal Eclipse -> Import Existing Maven Projects based on your workspace/ProductX/… (taking care not to select “Copy projects into workspace”) You’ll then get in Project Explorer (or whatever):

ProductX (info about rtc scm links)



In this view ModuleA and ModuleB exist in two places: as projects referenced in the workspace but apparently outside of RTC SCM control; as a folder structure under ProductX/ModuleA and ProductX/ModuleB.

This has the following advantages:

  • Cross-project dependencies resolve
  • You can run the parent/uber pom goals and the child pom goals without reloading anything
  • You can shift focus between the child-modules and parent structure without reloading anything

If you edit files in ModuleA and ModuleB under the folder hierarchy of ProductX then Pending Changes will keep track in the normal way but if you edit a file under the apparent “root level” ModuleA and ModuleB then Pending Changes won’t unless you do a “deep refresh”.

Alternatively just go to Eclipse -> Window -> Preferences ->  General -> Workspaces -> Refresh automatically (er… I think, I’m doing this from memory, hence the lack of screenshots). You can then add “edit files tracked by Pending Changes at either Product or child module level” to the advantages above.

So this option sounds great so far, what are the downsides?

This solution maintains the hierarchical structure between ProductX and it’s child modules and as such constrains everything from ProductX downwards to be in the same Jazz SCM component as eclipse projects can only be seen (without far too much fiddling) if they’re root folders in components. This may not seem like such a big deal but components are the lowest level of baseline (or label) in Jazz SCM. In a tightly coupled cohesive single architecture this might not be a problem but if you want to reuse any of these modules (at a code level) or have a separate ownership it will be a problem. It’s also very common to have dependencies from child modules to parent projects (which may initially seem to resolve if they’re in the local ~/.m2 repository).

Having said that source code dependencies between components lead to brittle architectures, binary dependencies are far superior, and made much easier by the use of things like Ivy/Maven and Nexus.

Other considerations

The point above above binary vs. code dependencies can be argued until the cows come home and go out again (an extended metaphor), especially if you consider project/product/team/release boundaries. I’m not going to pretend to answer those with an academic silver bullet here, the important thing I hope you take away from this blog is that there are pros and cons to all of these approaches, balancing those with the needs of your team/architecture/project/organisation are not easy. Shameless plug: Give me a call if you need help

Eclipse refactoring isn’t dealt with well by Jazz SCM, especially between Eclipse projects in and “out” of source control (advocated by option 3 above). Expect a lot of “remove/add” combinations if you are doing anything more than a trivial set of file changes. This is also a problem for the ClearCase <-> RTC automatic synchroniser developed by the excellent Samecs however I know that I, others and Samecs are pushing for improvements on this from IBM.

This post has been very scm focussed but what about build and release? The RTC build engine understands maven to a limited degree and can easily invoke maven builds for information on integating the maven release process see How to do maven releases with Jazz SCM

Linux GUI Development: Lazarus 0.9.30 review and screenshots

This blog is part of a series looking at programming tools on linux and covers Lazarus 0.9.30

EDIT: Since I wrote this Lazarus v.1 has been released  so I’ve updated my review here.



I’ve always liked Wirthian languages since programming in Modula-2 and university and Delphi late because they’re very readable and promote good programming practices in the structure of the language. Also, I like Wirth’s law “Software is getting slower more rapidly than hardware becomes faster.” from A Plea for Lean Software even if it wasn’t actually him that came up with it.

When I made the jump from Windows to Linux I was on the search for a nice high level language to do GUI development stuff in. In searching I came across Lazarus. Lazarus is a free cross-platform IDE which provides the Delphi experience for Linux (and Windows). Rather than Java’s “write once run anywhere” Lazarus aim’s for “write once compile anywhere” courtesy of the Fee Pascal Compiler (FPC). On top of the compiler Lazarus comes with the LCL (Lazarus Component Library) which gives a single interface for GUI programming despite underlying differences in implementation.

Lazarus is at 0.9.30 so it’s not a v1 product yet… However I’m not going to give much benefit for that since it’s been around for both windows and linux since 2008 and is available from the Ubuntu Software Centre.


Oh dear… the most important part of a software package, since if it fails your software doesn’t get used and for Lazarus it just sucks! When I first tried to install Lazarus it took me over 20 times to get it actually working. A comment from the Lazarus forum replied: “…20 times isn’t that much…” as if this is acceptable. Ok, so it’s free and open source but if it’s not accessible people won’t use it. It’s so hard to get running I’ve posted twice on the topic (and had a significant amount of hits from people with the same problems).

Worse, upgrades to Ubuntu have totally broken the installation and it’s not properly compatible with the new Ubuntu overlay scrollbars leading to focus problems with windows, text boxes and menus.

Basically, unless you really care it not going to be easy to get going. 1/10

First Impressions

Once I finally got it running my immediate reaction was summed up by the word “w00t“. Despite the always ugly multi-window layout here was an environment and language I knew like the back of my hand (so long as I rewind my memory 15 years) and could quickly put together good looking cross-platform apps in minutes 🙂

Normal multi-window interface for Lazarus

Lazarus as a single window IDE

It is possible (by recomiling the IDE) to get a single window mode which is a bit more modern. I was little disappointed to see that it didn’t have multi-project support but at least it’s solid and works if a little old-fashioned feeling. 6/10

WARNING: Due to problems with focus, the current version is close to unusable in Ubuntu 11.10.

GUI Designer

The GUI designer is solid and works well. Guidelines, alignment indicators and a pretty good set of visual components make putting together a simple form trivial. There’s no layout controls as you get in many newer GUI IDEs (flex boxes, tables, fixes vs.s flow etc.) but the use of anchors and panels means this isn’t a problem. The GUI designer feels a lot like the Delphi designer 9/10

Code Editor

The code editor features all of the old colour schemes and look and feel of Delphi with all of the modern stuff you’d expect like code folding, code completion etc.  The link between code and visual elements is easy to manage, especially with the excellent Actions feature. The Lazarus code editor is actually an improvement over the old Delphi editor 9/10

Language Features

Global variables are still there, I understand taking them out would cause problems for supporting old code bases but it’s still a shame.

The language is a good simple OO implementation but it misses out on some modern features like extension methods, anon methods, iterators, code attributes/decoration, multi-cast events…

Generics have been added but they feel a bit like a bolt on in this version, especially as when compared to their simplicity in languages like c#. Here’s the same example I used in the c# mono review in Lazarus.

generic TGList<T>; = class
  Items: array of T;
  procedure Add(Value: T);

TBlobList = specialize TGList<Pointer>;


sb := TStringList.Create();
for n :=0 to Length(blobs.Items)-1 do
Memo1.Text:= sb.Text;

I’ve created my own base generic collection here and then specialised it for a custom type. All seems to work pretty well.

Finally.. there’s no (limited) garbage collection. Although visual elements are dealt with when you close a form (it’s normally too late by then if there’s a problem) there’s no garbage collection which means in that code above I need to change the TStringList.Create to:

sb := TStringList.Create();

All in all, although it used to be a neat elegant language, and it still is Object Pascal just feels a bit old fashioned and clunky now. Sadly I’m going to have to give this 6/10

Feedback Process

The main feedback mechanism is the Lazarus site with wiki and forum. The forum’s fairly active but there seems to be an acceptance of problems such as the installation issues which is worrying.  7/10


Although the current version doesn’t really work with Ubuntu 11.10 the previous (and I hope future) configurations provide a pretty easy to use solid GUI design and code experience if a little old fashioned.

The community is reasonably active but a lot of the Lazarus usage seems non-English meaning the resources are sometimes a little hard to understand for me and since Pascal is  a bit of a niche language these days there’s not much non-Lazarus resources that can apply (except for old Delphi resources).

Although I’m predisposed to be positive about Lazarus to be honest I can’t really recommend it unless:

  • You’re an old Delphi developer looking for some nostaligia
  • Someone who hasn’t accepted Delphi is dead (even the website set up to refute this http://www.isdelphidead.com/ is dead!)
  • You need to quickly produce something very simple for multiple platforms and don’t know any other languages
Category Score
Installation 1/10
First Impressions 6/10
GUI Designer 9/10
Code Editor 9/10
Language Features 6/10
Feedback process 7/10
Overall 63% – Sadly not good enough
%d bloggers like this: