Selecting Open Source Software Libraries (2)

Dependencies: most software is dependant on other libraries for certain basic functions. This can pose a problem if these libraries are not available on the system being developed for. This might be for cost, licensing, hardware or other restrictions. Note that often the dependencies also need to be available in the correct version – possibly libraries have conflicting requirements!


Documentation is often scarce in the open source world; in particular developer documents such as API descriptions, configuration documentation, build instructions. You should also check the documents are up to date. If you need help you may also want to check whether there are any mailing lists or discussion forums associated with the software. This is often the case when the software is a product of a community effort.


Authors – it’s usually helpful to find out some background on how many authors are working on the source. Are you relying on a sole software developer or binding yourself to a single company? If the library is implementing a standard API this is not as critical as it’s easier to change the implementation w/o affecting your own software. In other cases you should always abstract from the implementation via your own API! Good places to find out about the authors are bug tracking systems and/or history of change documents, in addition to the website hosting the open source library.


Known bugs – check bug tracking systems (bugzilla[3], or whatever tracking system the open source website mentions) to find out about known bugs, get an idea of the stability of the software, frequency of updates, date of the last update (is anyone working on the software lately?), missing features, community feedback etc. The version of the software also provides an indication of stability, so beware of 0.1 versions!


Check how to build the software: the build system may require new tools and/or scripts. Possibly the build system uses a language (e.g. python) you are not familiar with. Is it configurable, do you need cross-compile support?


Take a look at the sources! Check for inline commenting, readability, structure, unit tests, all factors indicating the code quality. You may want to have a code checker (e.g. findbugs) analyse the code. Also check the warnings your compiler logs during the build process. Example applications are also useful if they are included.

Agile Bewares (1)
More and more teams and organisations are moving to agile. Interestingly I keep hearing similar statements that ring alarm bells in my mind. I thought I'd mention a couple of statements to beware about. This will probably become a growing list, so I'll call this part 1.

• we're agile inside development but still run the traditional process toward the rest of the organisation

That probably means budget, milestones and feature are fixed. In my experience, that leaves little room for agile, except for what I call "agile in the small", e.g. pair programming, test-driven development in the scope of unit testing (assuming internal milestones such as code-ready accomodate this). Probably, customer/product management won't (want to) be involved, so requirements won't be prioritized and thus the most important things might not get done first. You'd probably want to query why they want to run an agile process, what benefits they are expecting and make sure everyone has the same understanding of the process.

• scrum teams are component-teams

Compared to cross-functional teams that means you lose the advantage of direct communication between those implementing a user story (feature?) and also the better resource usage of cross-functional teams. Why is the resource usage better for the latter? Because component team members only work on their own components and thus can't help put in other areas. Cross-functional teams work on features or user stories and thus learn about all the layers and components necessary to complete their user story. On a similar line that's why you need to ensure user stories or features are customer centric and not defined like this "the database access layer needs to support CRUD operations for xyz data". Otherwise your feature team will again be working on a single component. Having cross-functional teams also enables the interfaces between the components to be defined, implemented and tested within one team, avoiding the frequent communication gap across interfaces.

• we adapted this recommendation because it won't work for us

While being agile also means adapting your development process, there is the risk that teams new to the agile process adapt recomendations because they don't understand them or because they think they don't work or maybe just because it sounds like too much work. There is a real danger to leave out all the bits people don't like to do (like regression testing, documentation) which is not necessarily being agile. Another reason why recommendations are not followed is because agile is used first time in critical projects (and that itself goes against recommendations!). And then people are afraid of anything that sounds unfamiliar and afraid of failure.

My recommendation is to try out those best practises on an uncritical project first before deciding what will work for you and what will not.

• With agile development can relax from all that planning and administrative stuff and focus on the important bits

Well, in my experience XP and also scrum require more discipline. Its just the responsibility is on the teams. For example, agile places a lot of emphasis on automation, e.g. automatic testing and also on metrics, e.g. code coverage, iteration and release plans (sprint backlogs), burn down charts, velocity tracking. Or look at planning: the product owner needs to prioritize all the user stories, stories need to be estimated based on velocity, they need to be broken down into small stories and even smaller tasks. Each needs to be tracked. Remember all those charts? Then there's all that CM stuff to sort out. CM is more complicated with everyone being able to change anyones code!

Selecting Open Source Software Libraries (Part 1)

There’s a plethora of open source out there, downloadable over the internet at the click of a button. As a professional software developer there are a number of issues you should be aware of when choosing open source software for inclusion in your own software product. The decision could make or break your project!

The first thing to be aware of is that free software (in the sense of no cost download) is not the same as open source software (OSS). Whereas OSS is usually without cost to download, “free” software does not necessarily include the source code. Without the source code, the “no cost” software needs to be in a form executable on your system. This is not a problem for java libraries assuming that the virtual machine is available (or other interpreted languages if you have the runtime system necessary), but would be a problem for C or C++ for example. Just to confuse matters the GPL found in open source software is authored by the free software foundation – they use the term “free” software as in the sense of open source.

Finding software: google™ or other search engines are always a good starting point. Sourceforge[1] is a website specialised in hosting open source projects. They have defined the licenses they accept as open source. If you’re looking for java libraries Apache is another source of usually good software quality. More popular standards or technologies often have a wiki with information on available implementations.

Some of the more obvious restrictions to check: operating system, HW requirements (RAM, code size), required functionality, cost, programming language.

A very important aspect is the licensing model: GPL, LGPL, Apache, BSD, MIT, MPL – there are a lot of different licenses, and you probably need to be a legal expert to understand the terms specified in these. Certainly GPL is restrictive in that often you are required to make your own software available to the public domain, which may be a problem if you are developing commercial software. LGPL is less restrictive in that respect. Apache, BSD, MIT, and MPL have no such requirement and are good candidates for use in commercial offerings. The OSI website has information about the various open source licenses[2]Another increasing popular model is dual licensing – an open source license (usually GPL) for the community version and a commercial license for business use. Commercial licenses obviously have the advantage of guaranteed support.


[1] http://sourceforge.net/
[2] http://www.opensource.org/licenses/

Just some news on my latest software offering:
ONLINE-BACKLOG

Once again its for free! What it does?
Its a webserver based application for task tracking supporting agile planing and development processes! That means you can define projects, tasks, iterations, users; assign tasks to users, to projects and to iterations; group tasks and so on.

On the technology side we're talking about a web application with JPA (java persistency API) and a relational DB of your choice at the back end, and JSF (java servers faces) technology for the front end.

Current version is 0.4 which is working and stable but with lots of features in the pipeline there are many changes ongoing.

Due to problems with my ftp-upload via my analog line current versions are not available for download yet. The site with the details, screenshots and the download link is:
http://home.arcor.de/stephan.kennedy/html/software.html (all in german I'm afraid)

Suggestions for improvements welcome!

New project page

I finally managed to upload the project pages for my current software project Lotto-WS!

You'll find lots of information and (coming soon) the possibility to download the Lotto-WS client for free! This may be of particular interest to anybody participating in the state lottery system (6 aus 49) in Germany, but also to any interested in modern client server architectures, since there is quite some description of how the software works.

Lotto-WS is web-service based utilizing apache axis2, designed contract first from an xml/xsd/wsdl interface description, and coded in pure java - though I also proved a C# implementation of the client using .Net 2.0 framework is possible by writing a simple command line client.

The server uses a DB to store the lottery results (currently these are entered via a local admin application on the server) which the web-service retrieves and provides to the client.

The client is a swing java application that comes with documentation and simple installer, and it's for free!

Version 0.1 has a planned release date of Feb. 2007.
More details at:
http://home.arcor.de/stephan.kennedy/html/software.html

Agile Checklist Part 4

Another important aspect of agile projects are the feature or scrum teams. It's very easy to define teams that belong together from an organisational point of view. That's ok if the members are those involved in the components affected by the feature to be developed. Often though, code is structured similarly to a components organisation (seriously!), and features span several components and thus several organisational units. And often misunderstandings occur between these units, because there is less communication across units than within them.
Therefore it is important to build teams involving all the units affected by a feature.

For example, say software is required to handle a new communication protocol which enables a new sort of application, i.e. a protocol layer, some sort of an abstraction layer, and an application need to be developed. The communication experts are in one department, the application people in another, maybe there are even architecure, and test departments. Even though it might be useful to form a team in the communication department that discusses/decides how best to implement the new protocol, its far more important to form a team containing those people from each of these departments that have been committed to design/implement/test the code for the feature, even (and especially) if these people don't know each other and work in different locations!

This may sound obvious but it is difficult to manage and therefore not always practised.

Feature or scrum teams need to communicate intensively, usually on a daily basis, and getting everyone together regularly (at least for the kickoff and integration phases of a sprint) avoids the sort of misunderstandings that often occur across component interfaces.

Also ensure that the team kicks off together, avoiding the situation where people are being phased in and added to the team as development proceeds. Otherwise there are continually disruptions getting people up to speed.

Solution 2

There needs to be a pair of curly brackets {} surrounding the multi-line macro.

Puzzle 2

A really difficult one this time!
The code defines a Logger class and a macro that gets the static instance of the logger and passes the text to its Log method with the log level TRACE_LEVEL.

Unfortunately the code does not compile due to a syntax error.
You can copy the code and try it with your favorite C or C++ compiler.
I get an error that l is not defined, and interestingly there is an 'else
without an if' !

#include <stdio.h>


// define a class for logging
// provides static instance via Instance method
class Logger
{
private:
 static Logger* sInstance;


public:
 Logger() {};
 ~Logger() {};


 static Logger* Instance()
 {
  if (!sInstance)
   sInstance = new Logger();
  return sInstance;
 }




 void Log(int level, const char* text)
 {
  printf(text);
 }
};


#define TRACE_LEVEL 5


#define TRACE(text)  Logger* l = Logger::Instance();  l->Log(TRACE_LEVEL, text);




Logger* Logger::sInstance = 0; //static initialisation




int main(int argc, char* argv[])
{
 if (argc == 1)
  TRACE("to few parameters");
 

 else
  TRACE("at least one parameter");
 



 //do something sensible
 return 0;
}

A little hint: there's nothing wrong with the Logger class or the macros, the bug is within the main function!

Happy puzzling!