Less Productive With Maven2.

My first trials of Maven were failures. As I am stubborn, I tried again, on a new project, a quite simple one. It works, but it makes some easy things overkill. And the default way of using it makes a developer lose lots of time.

If I have a project with common classes, a standalone app, and a web app, then logically you do 3 projects, 2 of them depending on the common one. That's how the default maven setup works, and that's what their documentation presents. Now when using maven eclipse, this will create 3 project, none depending on each other. If you modify something in the common code, it won't be seen by any of the other code, you have to publish it with maven first, this takes way too much time. Furthermore I did not see any way to force rebuild the common automatically from one of the other project. If you modify code in common and web app project, you need to call maven twice. I find all this very counterproductive, because you do those steps extremely often. Now there are probably some ways to do that with Maven2, but it is not the default behavior. I could add project dependencies in eclipse manually, and forget about maven while working in eclipse, but then the maven eclipse plugin is really useless. And you'll face the same issues when you want to use maven tomcat deploy.

Even more worrying, after moving back to Ant, I saw a strange bug with Spring context loading disappear. Maven is hiding so much, that it becomes not obvious how your app is deployed.

Developers lose power with Maven. It's a pain to do something a bit differently that the default Maven way. With Ant, people gain power. I see both as being the distinction between a framework approach (Maven) and a library API approach (Ant). By default, Maven tries to do a lot, while Ant tries to do nothing. It's very easy to build exactly what you need with Ant, while it is of course difficult with Maven.

Some parts of Spring have a similar disadvantage to Maven. If you do everything in XML with the most Spring magic, you'll spend hours trying to figure out how to do things and why it does not seem to work like you think it should. If you use Spring as an API, like the wonderful Spring JDBC, development will be fast (faster than with straight JDBC for example), and your program flow is easy to follow.

Less Productive With Maven2.

My first trials of Maven were failures. As I am stubborn, I tried again, on a new project, a quite simple one. It works, but it makes some easy things overkill. And the default way of using it makes a developer lose lots of time.

If I have a project with common classes, a standalone app, and a web app, then logically you do 3 projects, 2 of them depending on the common one. That's how the default maven setup works, and that's what their documentation presents. Now when using maven eclipse, this will create 3 project, none depending on each other. If you modify something in the common code, it won't be seen by any of the other code, you have to publish it with maven first, this takes way too much time. Furthermore I did not see any way to force rebuild the common automatically from one of the other project. If you modify code in common and web app project, you need to call maven twice. I find all this very counterproductive, because you do those steps extremely often. Now there are probably some ways to do that with Maven2, but it is not the default behavior. I could add project dependencies in eclipse manually, and forget about maven while working in eclipse, but then the maven eclipse plugin is really useless. And you'll face the same issues when you want to use maven tomcat deploy.

Even more worrying, after moving back to Ant, I saw a strange bug with Spring context loading disappear. Maven is hiding so much, that it becomes not obvious how your app is deployed.

Developers lose power with Maven. It's a pain to do something a bit differently that the default Maven way. With Ant, people gain power. I see both as being the distinction between a framework approach (Maven) and a library API approach (Ant). By default, Maven tries to do a lot, while Ant tries to do nothing. It's very easy to build exactly what you need with Ant, while it is of course difficult with Maven.

Some parts of Spring have a similar disadvantage to Maven. If you do everything in XML with the most Spring magic, you'll spend hours trying to figure out how to do things and why it does not seem to work like you think it should. If you use Spring as an API, like the wonderful Spring JDBC, development will be fast (faster than with straight JDBC for example), and your program flow is easy to follow.

How to Build Good Software? Good network connection

Not having good internet connection can be problematic to download new libraries, read or search for documentation on development subjects. But not having a good internal network connection is killer of productivity. It means sometimes not being able to access integration, preprod or even production environment, or ssh session not responding in the middle of an action. As software makes an increasing use of the network, it means not being able to test or to use correctly all kind of software.

How to Build Good Software? Good network connection

Not having good internet connection can be problematic to download new libraries, read or search for documentation on development subjects. But not having a good internal network connection is killer of productivity. It means sometimes not being able to access integration, preprod or even production environment, or ssh session not responding in the middle of an action. As software makes an increasing use of the network, it means not being able to test or to use correctly all kind of software.

How to Build Good Software? Private office, again

Apparently it's more a habit of French companies to have big open spaces with no separation at all between people. There is nothing more annoying than having people in conference call in front of you while you are trying to work on something completely different. French people forgot the cubicle part in the American open space idea. So sometimes the room is just a big mess, everybody being able to disturb you anytime. Even if I have no private office, please give me at least a cubicle.

How to Build Good Software? Private office, again

Apparently it's more a habit of French companies to have big open spaces with no separation at all between people. There is nothing more annoying than having people in conference call in front of you while you are trying to work on something completely different. French people forgot the cubicle part in the American open space idea. So sometimes the room is just a big mess, everybody being able to disturb you anytime. Even if I have no private office, please give me at least a cubicle.

How to Build Good Software? Welcome newcomers

Some companies do it naturally, some really don't. In small companies, it is almost natural, people will make a newcomer productive very quickly. In a big company it's not the same game.

Some important points are:

• Computer ready the first day, well sized (right ram, right power, developers are not MS office users), right OS. I had experience with having not the right amount of ram, not the right version of OS, not the right user rights to install and use critical software for my work, and all those were known from the team. I also hate when companies give the cheapest computer available for developers/architects. On top of that badly configured computers take often a month to be ready in big companies. It just does not makes sense.
  
• Network access. I have seen people coming for a short contract and not having network account or email account before 1 week.
  
• Give documents to read, show applications the person will work with. Involve newcomer in new decisions on his project.
  

Some big companies have it right. I remember my internship at IBM Germany, where on the first day I had a box waiting for me with computer inside, that I had to unpack and install (with OS/2) for my use. I think this is the best way for developers/tech people. And then they recommended excellent reading on the subject I would be working on. It's not that difficult.

How to Build Good Software? Welcome newcomers

Some companies do it naturally, some really don't. In small companies, it is almost natural, people will make a newcomer productive very quickly. In a big company it's not the same game.

Some important points are:

• Computer ready the first day, well sized (right ram, right power, developers are not MS office users), right OS. I had experience with having not the right amount of ram, not the right version of OS, not the right user rights to install and use critical software for my work, and all those were known from the team. I also hate when companies give the cheapest computer available for developers/architects. On top of that badly configured computers take often a month to be ready in big companies. It just does not makes sense.
  
• Network access. I have seen people coming for a short contract and not having network account or email account before 1 week.
  
• Give documents to read, show applications the person will work with. Involve newcomer in new decisions on his project.
  

Some big companies have it right. I remember my internship at IBM Germany, where on the first day I had a box waiting for me with computer inside, that I had to unpack and install (with OS/2) for my use. I think this is the best way for developers/tech people. And then they recommended excellent reading on the subject I would be working on. It's not that difficult.

Project Estimations And Fibonacci Sequence.

I was recently in a meeting where use case complexity was estimated using numbers in the Fibonacci sequence. I was surprised by the choice of the Fibonacci sequence. Why not any sequence? Why a particular one? I googled and found the culprit, Mr Mike Cohn in his book Agile Estimating and Planning. It's actually not a bad sequence to choose, since the scale is increasing constantly, so by picking up numbers in this sequence, you can quite accurately describe estimation. If you have defined complexities of 1,2,3,16,17 corresponding to 5 different use cases then obviously 16 or 17 denotes the same complexity, and it would be surprising that you can really distinguish both. You need an ever increasing scale. But a power of 2 scale might not be precise enough (steps are growing too fast).

Still I think the main reason for him to chose Fibonacci sequence is due to Da Vinci Code, that was just popular at that time in 2004 when he wrote his book. And then this particular series seduces people easily, be it because of the da vinci code book, or because of a mathematical tool that gives the impression our estimations are better, even if there is no real mathematical reason to use it.

Project Estimations And Fibonacci Sequence.

I was recently in a meeting where use case complexity was estimated using numbers in the Fibonacci sequence. I was surprised by the choice of the Fibonacci sequence. Why not any sequence? Why a particular one? I googled and found the culprit, Mr Mike Cohn in his book Agile Estimating and Planning. It's actually not a bad sequence to choose, since the scale is increasing constantly, so by picking up numbers in this sequence, you can quite accurately describe estimation. If you have defined complexities of 1,2,3,16,17 corresponding to 5 different use cases then obviously 16 or 17 denotes the same complexity, and it would be surprising that you can really distinguish both. You need an ever increasing scale. But a power of 2 scale might not be precise enough (steps are growing too fast).

Still I think the main reason for him to chose Fibonacci sequence is due to Da Vinci Code, that was just popular at that time in 2004 when he wrote his book. And then this particular series seduces people easily, be it because of the da vinci code book, or because of a mathematical tool that gives the impression our estimations are better, even if there is no real mathematical reason to use it.

How to Build Good Software? Use a bug management software, really.

This will seem obvious, unfortunately, when people are involved, nothing is that obvious. It's not because you setup a bug/feature management software that people will use it. You have to force people to go through the bug management software each time they want something fixed. If you don't do that some people will keep sending incomplete mails, or worse call you to get something fixed, that will be forgotten in a week. It is also very useful to avoid receiving 10x the same request from the same person.

How to Build Good Software? Use a bug management software, really.

This will seem obvious, unfortunately, when people are involved, nothing is that obvious. It's not because you setup a bug/feature management software that people will use it. You have to force people to go through the bug management software each time they want something fixed. If you don't do that some people will keep sending incomplete mails, or worse call you to get something fixed, that will be forgotten in a week. It is also very useful to avoid receiving 10x the same request from the same person.

How to Build Good Software? Have a good build process

Important points are: standard code hierarchy, automatic download of dependencies, a distribution command with versioning support and source control interaction, a simple command to build each part of the project. In Java best candidates are a sophiticated ant build, or maven2. Maven2 is quite good since it forces you to do some of those steps, even though I think ant can't really be avoided for many more specific tasks.

Once, I got wrong code before I left for a customer site, because code given to the customer was not checked into a source repository everytime before it was given to the customer. Furthermore the code I had could not be built because of missing jars, and the project structure forced some source directories containing source code common with other projects to be in a very specific directories at a particular level, because project isolation was poor. It took me 7 days to understand their very awkward build process.

A good build process is dependent on good CVS (or other source control system) management, which is itself dependent on good code split. CVS head should always compile. If CVS head does not compile, then people will start trying to work around it. Unfortunatly working around it means use it as rarely as possible (either by just not updating your code frequently, or by working in a branch that can not merge well because head is in a bad state). I have seen that on projects, the result is integration headaches, and extremely poor overall quality.

An good check for a build process is to see how long and how many steps you have to do to build the latest deliverable on a new machine, and how difficult it is to put that in production.

How to Build Good Software? Have a good build process

Important points are: standard code hierarchy, automatic download of dependencies, a distribution command with versioning support and source control interaction, a simple command to build each part of the project. In Java best candidates are a sophiticated ant build, or maven2. Maven2 is quite good since it forces you to do some of those steps, even though I think ant can't really be avoided for many more specific tasks.

Once, I got wrong code before I left for a customer site, because code given to the customer was not checked into a source repository everytime before it was given to the customer. Furthermore the code I had could not be built because of missing jars, and the project structure forced some source directories containing source code common with other projects to be in a very specific directories at a particular level, because project isolation was poor. It took me 7 days to understand their very awkward build process.

A good build process is dependent on good CVS (or other source control system) management, which is itself dependent on good code split. CVS head should always compile. If CVS head does not compile, then people will start trying to work around it. Unfortunatly working around it means use it as rarely as possible (either by just not updating your code frequently, or by working in a branch that can not merge well because head is in a bad state). I have seen that on projects, the result is integration headaches, and extremely poor overall quality.

An good check for a build process is to see how long and how many steps you have to do to build the latest deliverable on a new machine, and how difficult it is to put that in production.

How to Build Good Software? Private Office

In an open space, people keep on coming to discuss various issues with various people, issues that have nothing to do with your work. You end up either being distracted, or annoyed by the increased noise level.

Apparently at Microsoft, they have private offices for each programmer. It might be extreme, paradoxally not in the XP (extreme programming) sense, but it is much better than open space for productivity. In XP, it's almost the opposite with 2 developers working often together.

How to Build Good Software? Private Office

In an open space, people keep on coming to discuss various issues with various people, issues that have nothing to do with your work. You end up either being distracted, or annoyed by the increased noise level.

Apparently at Microsoft, they have private offices for each programmer. It might be extreme, paradoxally not in the XP (extreme programming) sense, but it is much better than open space for productivity. In XP, it's almost the opposite with 2 developers working often together.

How to Build Good Software? Lay Off Quickly.

If you have to lay off in your job, do it quickly. I don't understand companies that want to keep someone as long as legally possible when this someone wants to leave. First the employee won't be as motivated, but more importantly, you will continue to train that person to your company's software and ways of work. This would be much better used on another person, that will stay in the company. Time for layoffs should exclusively be used for knowledge transfer.

How to Build Good Software? Lay Off Quickly.

If you have to lay off in your job, do it quickly. I don't understand companies that want to keep someone as long as legally possible when this someone wants to leave. First the employee won't be as motivated, but more importantly, you will continue to train that person to your company's software and ways of work. This would be much better used on another person, that will stay in the company. Time for layoffs should exclusively be used for knowledge transfer.

How to Build Good Software? Talk to people, especially the ones you don't know well.

Someone modified a simple launch script on a integration machine. This pissed off the author of the script. Why?

Just because the guy who modified the script never worked before with the author of the script. If only the author had been notified verbally or by mail of the modification, he would have been happy. Furthermore this would increase the quality of the change since the new guy might have made a change that has other impacts, that the author will best evaluate quickly.

How to Build Good Software? Talk to people, especially the ones you don't know well.

Someone modified a simple launch script on a integration machine. This pissed off the author of the script. Why?

Just because the guy who modified the script never worked before with the author of the script. If only the author had been notified verbally or by mail of the modification, he would have been happy. Furthermore this would increase the quality of the change since the new guy might have made a change that has other impacts, that the author will best evaluate quickly.

Find Grep And Vi Keys Small Memo

I tend to forget this now and then to grep on a specific list of files:

find . -name "*.xml" | xargs grep "iwantthis"

And I also tend to forget the vi keys. Small extract:

h - move left one character
j - move down one line
k - move up
l - move right
$ - go to the end of the current line
0 - go to the beginning of the current line
G - go to the last line in the file
15G - go to line 15
control-F - forward one page

control-B - backwards one page

n (N) - next (previous) in search mode (/ or ? forward or backward)

s/OLD/NEW/g - replace on current line

%s/OLD/NEW/g - replace every occurence in file (or use 0,$ instead of %)

x - delete one character

Update I have to add the standard replace in multiple files via sed command. Here is an example of how to move your eclipse workspace to another directory:

• find . -name "*.xml" | xargs sed -i "s,c:[/\\]java[/\\]eclipse,d:/eclipse302,gi"

Find Grep And Vi Keys Small Memo

I tend to forget this now and then to grep on a specific list of files:

find . -name "*.xml" | xargs grep "iwantthis"

And I also tend to forget the vi keys. Small extract:

h - move left one character
j - move down one line
k - move up
l - move right
$ - go to the end of the current line
0 - go to the beginning of the current line
G - go to the last line in the file
15G - go to line 15
control-F - forward one page

control-B - backwards one page

n (N) - next (previous) in search mode (/ or ? forward or backward)

s/OLD/NEW/g - replace on current line

%s/OLD/NEW/g - replace every occurence in file (or use 0,$ instead of %)

x - delete one character

Update I have to add the standard replace in multiple files via sed command. Here is an example of how to move your eclipse workspace to another directory:

• find . -name "*.xml" | xargs sed -i "s,c:[/\\]java[/\\]eclipse,d:/eclipse302,gi"

How to Build Good Software? MS Press Code Complete says Measure twice, cut once

I am starting a series of posts about software construction, based on good and bad experiences while working for my many employers.

"Software construction (a.k.a. architecture), is the only activity that's guaranteed to happen on every project". It is not rare that projects or new features are abandoned either because they are too costly, or because they are not needed anymore, or because they are other more important priorities.

In the same vein: "Measure twice, cut once". “Measure twice, cut once” is highly relevant to the construction part of software development, which can account for as much as 65 percent of the total project costs. The worst software projects end up doing construction two or three times or more. Doing the most expensive part of the project twice is as bad an idea in software as it is in any other line of work.

When you see Software that change versions (major versions) while not really having been used much, this is a sign there is something wrong in the construction part.

How to Build Good Software? MS Press Code Complete says Measure twice, cut once

I am starting a series of posts about software construction, based on good and bad experiences while working for my many employers.

"Software construction (a.k.a. architecture), is the only activity that's guaranteed to happen on every project". It is not rare that projects or new features are abandoned either because they are too costly, or because they are not needed anymore, or because they are other more important priorities.

In the same vein: "Measure twice, cut once". “Measure twice, cut once” is highly relevant to the construction part of software development, which can account for as much as 65 percent of the total project costs. The worst software projects end up doing construction two or three times or more. Doing the most expensive part of the project twice is as bad an idea in software as it is in any other line of work.

When you see Software that change versions (major versions) while not really having been used much, this is a sign there is something wrong in the construction part.