All about Grid and Cloud Computing: Discover the limits

Great blog post, which I should definetly try out sometime...Or it should even be a mandatory hook script!

http://andialbrecht.wordpress.com/2009/05/09/when-merging-fails/

In the last weeks I have heard the following sentence more often: "Everybody who has done a software project knows that integration and development isn't easy". This statement of does not make sense to me. Seems like a lame excuse which implies that all software projects need to be off schedule and integration is hard when putting software together.Which is not the case I think. There are very successful projects around. And they also face the "integration problem".

So this statement does not need to be true when doing it right (my own opinion and experience though :-)). Especially with all the tools, books and information available. I think this is even right for highly distributed software projects where the partners a scattered around the world. Yes we can do it right :-)

P.S. I know a lot of links in there, but worth to follow (this is seemless self promotion :-))

An great talk from Mik Kersten from Tasktop (You might know him from Mylyn) @ W-JAX conference - it is about productivity and topics surrounding it:

The video can be found here.

So you are a software developer? The next list is a set of books which I would recommend to read :-) Might not be complete so feel free to add some more!

CodeCraft - Pete Goodliffe
Beautiful Code - Andy Oram; Greg Wilson
Code Complete - Steve McConnell
The Pragmatic Programmer - Andrew Hunt, David Thomas
The Mythical Man Month - Frederick P. Brooks
The Productive Programmer - Neil Ford
Practical Development Environments - Matthew Doar
Head First Design Patterns - Eric, Elisabeth Freeman
The Art of Agile Development - James Shore, Shane Warden
Managing Software Requirements - Dean Leffingwell, Don Widrig
Managing Iterative Software Development Projects - Kurt Bittner, Ian Spence
Refactoring - Martin Fowler
Testing and Quality Assurance for Component-Based Software - Jerry Zeyu Gao
A Practical Guide to Testing Object-Oriented Software - John D. McGregor, David A. Sykes

Beside all these nice books there are plenty of other books around which are great. For example books about programming languages, getting things done, presentations, etc...So grap a book and start to read :-) In my opinion good code quality starts with the developer. And a developer who is informed, up-to-date and knows what he is doing writes quality code!

The book "Clean code" from Robert C. Martin has the subtitle: "A Handbook of Agile Software Craftmanship". It comes up with some nice ideas. Many of them you might know, but hidden in the book are some other ideas. Overall it's well written and easy to read. And compared to the book "Code Craft" much thinner so faster to read (Although Code Craft is a very good book, and a must read for prgrammers!). Overall a nice book if you want to get into the idea of writting quality code.

Software projects grow over time. They get bigger, more stuff is added, patches added and bugs fixed. New features added, and removed and code removed. But who keeps track of the changes and ensures that your source code repository stays clean? That they are no old undeleted files, no missing unittest, that all dependecies are correct? In short: that they are no broken windows (link) and a nice clean environment a engineer can checkout, compile and run within minutes? 

I'm using the ReInCheck tool for that. Currently it is customized to support a multi module maven project which consists of OSGi bundles. But it should be easy to adopt it to your needs.

I've been working with OSGi for the past years - and I must admit I really like it. If you follow some best practices rules your applications are definitely going to perform better and look nicer. Therefor I remembered an presentation about best practices when using OSGi. I have almost nothing to add - See for yourself: OSGi Best Practices!

I like the OSGi platform, and I have been using it for quite a while. One of the most important things is to keep track of your dependencies (e.g. like preventing cycled dependencies). Auto-generated MANIFEST.MF files are most of the time not really optimized. Therefor I started writing some python code to check dependencies. 

 It reads in all the MANIFEST.MF files from the bundles and creates a dependency graph. It will look for unnecessary and unneeded imports and exports. Look for cyclus etc. It is written using the networkx library for python. Also useful is the zipfile extension in python :-) It can be used to extract the jar files of bundles.

So my personal opinion on software engineering is pretty straight forward. First of all it is important that the developers who write code are willing to improve themself by reading, blogs, articles, books (e.g. Code Craft or Beautiful Code - good reads).

The second idea is to restrict the work of the users. Provide coding guidelines and define processes. Everybody should know them by heart (and behave like they say). This will help that persons can work more and do not have to look up and ask many things (A knowledge base is always a good idea and even more important a todo/issue tracker so everybody knows what he is doing).

The next is to automate everything (another good tip from the Pragmatic Programmer book :-)). Last but not least do clear designs and document them (do not reinvent the wheel).

And if you behave work like this you can minimize the number of bugs you produce during development. You can also speed up your development! But always try to optimize (e.g. by tracking where you loose time...) your personal working behaviour and the global processses. Be Agile!

The simple question is: how can you use a source code management system to find bugs? First of start by using Mercurial (As you might know: always try to use distributed source code management systems :-))And then install the bisect extension. It is very similar to the version in GIT.

The Basic idea is the following. Take a bug free revision and a revision which has a bug in it. Then use bisect to get a revision in the middle. Test this revision and look if it is bug free or not. Then do a bisect in the higher or lower half. And so on...Until you find the revision in which the bug appeared. Pretty neat he?