Software Development and Licensing Issues: The License Maven Plugin

There a some common pitfalls in software development. Most can be overcome by the developers them self, but when it comes to software licensing, they are completely lost (all developers I met at least). For me, it is the same and I tried to find a lawyer who would know about that, but I did not find any, yet. I still have some questions, but I cannot get them answered professionally, but some website and books give at least some information and hints…

One good source is the book “Understanding Open Source and Free Software Licensing” ( Here some information is presented on what licenses can be used to produce Open Source Software and proprietary software and which are to be avoided. Terms like Copyright and copy-left are explained. But, do you always know what licenses are used libraries you use and link against?Are you sure, that the licenses of these libraries are correct? May it be possible that an Apache License licensed library uses a GPL licensed library? In that case, the used library is also copy-left… šŸ˜¦

At least for Java in combination with Maven there is a possibility to check that automatically, and it is advised to do this regularly with the build system. Maven and maven artifacts should contain a license hint in their poms about the used licenses and the dependencies of them should contain the same hint. So it is possible to check the licenses transitively for all dependencies in your project.

For an easy implementation have a look to and

Quality Assurance in Software Development from its Root

I checked the V-Model of software development again a couple of days ago during my holidays. (For example have a look to Wikipedia: The model in general is very helpful to explain different levels of testing and their meaning. It is a difference whether I use unit testing to check different functions of the software or integration testing to check the system as whole to check the different parts working together. From functional point of view this V-Model is a good model, but it lacks the most basic building block of software: The source code itself.

Let us take car manufacturing as an example. The V-Model tells us to specify the basic requirements like the car needs to be able to go from A to B with four passengers and a big trunk. We specify then the system design like it is a person car which has a certain size and shape and go down via engine design to details like the different parts of the engine. We take the requirements and design everything from top to bottom by separating more and more smaller building blocks which are separated again until we end up with the most basic building blocks like screws, nuts and bolts. The test goes in production the other way around. First the screws, nuts and bolts are checked for their correct size before they are put into an engine for example. The engine is tested before it is put into the car and so on.

But, when we look to the car manufacturing, there is something which is still missing. It is the part where engineers think about the maintainability of the car. They already think during design phase of new car models about their maintainability. It would be a catastrophe if a mechanic has to dis-assemble the whole car just to change the front light bulb. (In my car I need to walk my way up to the front light starting from the front wheel! So they did not do a good job here…)

In software development it is the same. We think about the correct behavior of the code, but we forget, that we need to maintain the code in future and we also need to develop it further. So maintainability is a big deal, too. Here we need to pay more attention on software architecture, design and source quality to not block our development for further functionality. It is even more obvious, that we need to do this, when we think about the fact, that the source code of the current product is the base for all following products.

The Killer Difference between Mechanical Engineering and Software Engineering

I always run into the same discussions when it comes to project management and quality assurance in software development. Some people (mostly people without technical background in software development) do not really understand why classic project management and quality assurance methods fail in software development. Here is the killer argument why this does not work:

In hardware engineering for each piece of hardware product the same procedure is applied repeatedly. In softwareĀ  the procedure is applied once and then the product is copied.

This is now my killer argument in most discussions related to that topic to stop discussions why these methods do fail. The difference should be easy to understand. For a deeper understanding, I explain a little more:

  1. Hardware engineering has a lot of physical constraints which limit the choices and there for timelines are more predictable.
  2. In hardware engineering it is not so easy to define new requirements and the requirements do not change on regular basis like in software development. A car needs to go fast and safe, but it is not to be intended to dive from one day to another. Nobody would think about requesting something like this and expects the car to be able to dive in the next release within a short period of time. For software it is a common pattern, because it is just easily put in, there is only some code to be written…
  3. In hardware production, due to its repeating nature, one can track cp and cpk values and drive the process to engineering. After some prototypes (which are fixed manually later or disposed), the production process is optimized and controlled. The products become better in quality over time due to continuous improvements. That’s classic quality assurance. For software: A product is produced once (and hopefully well tested), but shipped not just once, but up to thousands of time until a bug is reported. Hardware products are all a kind of special. Software is copied.

In this way, I could go on. I just take the classic methodologies and apply them to software development with the difference in mind.

Scrum and Extreme Programming (XP) for Software Quality Assurance

I talked to someone who owned a software company for outsourcing in Asia. The idea was, as always, to provide software developers with lower hourly rates for customer’s software projects. The specialty was a management of Europeans who drove a tight, Scrum based project and company management.

The question about quality assurance arose from my site. All I got as answer was, that the Software is developed with Scrum, with 2 week sprints, the source code and the results are shared on daily basis with the customer and that daily stand up meetings are held, sprint demos are organized together with the customer and some tools were in place for project monitoring. But, there was nothing told about source code quality, testing or code reviews. Assuming I was a customer who outsources its development projects to a company like, I wonder what source code and quality I get. The source code produced with outsourcing, is the property of the customer who pays for that. The customer wants high quality, but what is the interest of the development team in Asia about the quality of the source and the test coverage? I have no concise answer for that.

Scrum, as I understand it, is mainly a kind of project management. Scrum is not for quality management per se, but for satisfying stakeholders. Quality is not build into software, but into the process in form of retrospectives, demos and daily stand ups. Scrum assures deliveries in time and a transparent software development.

If you look into Extreme Programming (XP), that is quite different. Except of the terms, the Scrum methodology is also built into XP, but there is much more. XP also has Quality Assurance potential build in, in form of Pair-Programming, Test-Driven-Development (TDD), dedicated testers and other elements. Would it not be more suitable for companies providing outsourcing services?

%d bloggers like this: