Which work process in my company should I Improve first?

Question

I've just started to work in a new place, and I see several things they do that I find really terrible, and I want to know if they are indeed so wrong, or I am just too strict. Please let me know if my criticism is in place, and your opinion on which problem is the worst and should be fixed first. The developement is all in Java.

1. Not using svnignore. This means svn stat can't be used, and developers forget to add files and break the build.

2. Generated files go to same folders as committed files. Can't use simple maven clean, have to find them one by one. Maven clean doesn't remove all of them.

3. Not fixing IDE analyze warnings. Analyze code returns about 5,000 warning, of many different kinds.

4. Not following conventions: spring beans names sometimes start with uppercase and sometimes not, ant properties sometimes with underline and sometimes with dots delimiter, etc.

5. Incremental build takes 6 minutes, even when nothing is changed.

6. Developers only use remote debug, and don't know how to run the Tomcat server internally from the IDE.

7. Developers always restart the server after every compilation, instead of dynamically reloading the class and saving the server's state. It takes them at least 10 minutes to start checking any change in the code.

8. Developers only compile from command line. When there are compilation errors, they manually open the file and go the the problematic line.

9. A complete mess in project dependencies. Over 200 open sources are depended on, and no one knows what is indeed needed and why. They do know that not all dependencies are necessary.

10. Mixing Maven and Ant in a way that disables the benefits of both. In one case, even dependency checks are not done by Maven.

11. Not using generics properly.

12. Developers don't use Subversion integration with IDE (Eclipse, Intellij Idea).

What do you think? Where should I start? Is any of the things I mentioned not really a problem?

Answer 1

You don't mention continuous integration, but one good thing to start with is to give developers a rapid feedback if the build is broken. Once you have it you can add code quality metrics to encourage them to correct warnings or bad use of generics.

Only with all that in place you should start working on their productivity by showing them how to hot deploy, debug, use an IDE and so on...

And good luck :)

Answer 2

In general, I think that stuff that wastes time for developers should be taken care of first. The less idle the developer is, the greater the benefit.

1) This together with 12) should be prioritized higher, as broken builds take time.

3) IDE warnings aren't that important, as they are just warnings and could be as simple as unused imports.

4) Lack of naming conventions doesn't break anything and can be enforced gradually. That will take a lot of time however you do it. This shouldn't be highly prioritized.

5) I assume you have a separated build server that takes care of the builds, six minutes doesn't sound like a very long time. If you don't have a build server, that would be a good investment.

7) Sounds like a lot of time is being wasted for all developers, this should be highly prioritized.

11) These could cause a lot of the warnings in 3), should be fixed, but not highest priority.

12) Subversion integration with IDE should help out a lot, I think the developers would see this as very useful.

Answer 3

I'd look at it like this:

• Anything that affects productivity should be solved first
• Things that affect profitability solved second (most productivity fixes are profitability fixes too)
• Nitpicky stuff last

Therefore, you should have the following (in order of my opinion):

1. 7 - Restarting the Server after Compilation
2. 5 - Incremental Build Speed
3. 6 - Remote Debugging only
4. 8 - Compiling from command line
5. 12 - Subversion Integration (kind of in the same league as 5. above)
6. 2 - Generated Files
7. 11 - Not using Generics Correctly

Then

1. 1 - svnignore
2. 9 - Project Dependencies (this will take a great deal of time i'm sure)
3. 10 - Mixing Maven + Ant
4. 3 - IDE Warnings
5. 4 - Conventions

The reason I have the ordering in this sense is time vs. benefit. If it takes a user 16 minutes to compile and check their code, it's bloody well insane to be honest. Say a developer compiles 5x per day, we're taking about 80 minutes, doing nothing.

After that it's productivity. If you speed up the rate at which your developers can do their work, the turnover of work completed will rise substantially. (Profitability++)

After this is the "nitpicky" things. I say this not as to infer that they're not important, but the fact is from the looks of things you have much bigger fish to fry, so get those done first before correcting casing in code.

Answer 4

Not being a maven user, I can't comment on some of the above but most things in your list look like good areas for improvement. I think the best advice I can give is:

• Take it slow. They've probably been doing it this way for ages and may resist change.
• Get the team (and possibly the manager(s)) involved in the changes. Hold a meeting to discuss what improvements you see (keep it simple, just a few), what they think of them, and if they think its sensible to implement. Then, if agreed, pair with someone to get the improvement in place.
• Offer presentations on working practices which are easily changed. E.g. show them in a live setting the difference of dynamic class loading during a debugging session.
• Prioritize the list above and focus on a few at a time.
• Be gentle. Change is hard! To much at once will potentially alienate or disengage folk.
• Start with quick wins that will make an immediate and positive difference to the developers in the team. This will build their confidence in accepting more difficult changes.

Best of luck...

Answer 5

Comments to the issues

1) Not using svnignore. This means svn stat can't be used, and developers forget to add files and break the build.

Doesn't sound very critical to me - I assume from the above that you have a CI or nightly build (if not, that would be a major issue indeed). The purpose of the CI build is to catch such problems, so IMHO it is not a catastrophe if it is broken every now and then. Of course if it happens daily, that's a different story :-(

2) Generated files go to same folders as committed files. Can't use simple maven clean, have to find them one by one. Maven clean doesn't remove all of them.

This is bad, and is fairly simple to fix (under normal circumstances :-)

3) Not fixing IDE analyze warnings. Analyze code returns about 5,000 warning, of many different kinds.

This is bad, and it takes a lot of time to fix. However, skimming through the analysis results to spot really critical issues could be a high priority task.

4) Not following conventions: spring beans names sometimes start with uppercase and sometimes not, ant properties sometimes with underline and sometimes with dots delimiter, etc.

Not a catastrophe, OTOH easy to fix.

5) Incremental build takes 6 minutes, even when nothing is changed.

This is bad, and (considering cases 9 and 10 below) may be a rather daunting task to fix.

6) Developers only use remote debug, and don't know how to run the Tomcat server internally from the IDE.

A short demo and mentoring should not take a lot of effort. However, there may be cultural issues, and old members of the team might not be willing to learn new tricks. So a sensitive approach is required.

7) Developers always restart the server after every compilation, instead of dynamically reloading the class and saving the server's state. It takes them at least 10 minutes to start checking any change in the code.

Same as above.

8) Developers only compile from command line. When there are compilation errors, they manually open the file and go the the problematic line.

Same as above.

9) A complete mess in project dependencies. Over 200 open sources are depended on, and no one knows what is indeed needed and why. They do know that not all dependencies are necessary.

This is bad, and is a huge task to fix.

10) Mixing Maven and Ant in a way that disables the benefits of both. In one case, even dependency checks are not done by Maven.

Same as above.

11) Not using generics properly.

Do you mean they are still programming the Java 1.4 way using non generic collections et al? If the code is otherwise stable, this can be fixed (and developers educated) gradually.

12) Developers don't use Subversion integration with IDE (Eclipse, Intellij Idea).

See case 6.

Priorities

I would try ordering tasks based on cost vs benefit ratio. My order would be:

First, tasks to simplify and speed up day to day work, and build up your credibility and authority within the team: 7, 6, 8, 12, 2

Then the fundamental, but difficult and time-consuming tasks, for which you need more support from the team: (continuous integration in case there is none yet), 5, 10, 9

The rest can be introduced gradually: 1, 3, 4, 11

Answer 6

First of all, I totally agree with you list of problems since I have been on projects that have basically the same issues.

If you start with the places where you think you can gain the most productivity. I would think that you can save considerable amount of time with:

• Get tomcat running in the IDE.
• Fix any build script, maybe also test, issues to make the builds run fast.
• Compilation within the IDE and hotdeploy (hotswap/jrebel) will also save you a lot of time.

As already posted, get a continuous build server up and running for the project. And if you have an issue tracker, add these issues to it so that everyone is aware of what needs to be done. When the high priority stuff has been completed try to push for time to get the other stuff fixed as well, its really annoying with all the small problems and even though they seem small now they can cause considerable headache after a while.

Answer 7

First of all, since you are new, you need to be careful not to be considered very annoying.

I would suggest you start by talking to your own boss, and say that you may have some experiences that might be useful to your new company. Management backup is essential if you want something done rather quickly.

You will need to demonstrate to your boss and coworkers that your suggestions are immediately beneficial to them, in their daily work. Hence select just one pain-point and fix it good (but reversible as going back is a nice option to have when trying things out). Be prepared to do a lot of work yourself and a lot of mentoring.

Based on your description, I would suggest a quick demonstration of a proof-of-concept web application being run inside the IDE with hotspot editing and instant redeployment of changed files would be very eyeopening. Do NOT go to fast - be certain that everybody understand what you do. Then as a final demonstration, do it again but in normal speed.