Last entry inspired me to think about books I really liked, they taught me a lot and I wish everybody around me have read too :-) Here it is, it is not complete and their order is not meant as ranking.

• Martin Fowler: Refactoring Improving the Design of Existing Code
• Michael Feathers: Working Effectively with Legacy Code
• Kent Beck: Test Driven Development: By Example
• Dave Astels: Test-Driven Development: A Practical Guide
• Eric Evans: Domain-Driven Design
• Martin Fowler: Patterns of Enterprise Application Architecture
• Gerard Meszaros: xUnit Test Patterns: Refactoring Test Code
• Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software
• Alan Shalloway: Design Patterns Explained: A New Perspective on Object-Oriented Design
• Andrew Hunt, David Thomas: The Pragmatic Programmer: From Journeyman to Master
• Tom DeMarco, Timothy Lister Peopleware: Productive Projects and Teams
• Johanna Rothman, Esther Derby: Behind Closed Doors: Secrets of Great Management

I am sure I have missed some important or that I do not remember that some influenced me as much as these did. Only thing I am sure is that this list should be longer.

Following list contains books still in queue (either ready on shelf or still at Amazon :-) ). I have strong feeling they are worth of reading:

• James Shore, Shane Warden: The Art of Agile Developement
• Robert C. Martin: Clean Code: A Handbook of Agile Software Craftsmanship
• (many): The ThoughtWorks Anthology

About 2 years ago I was handing my project over to my successor. He was younger, less experienced so apart of showing him details of project I was also giving him good advice.

I was talking about unit testing, TDD, something about design and that led me to refactoring. At the end of the session I gave him Refactoring book thinking how much I helped him.

To my big surprise he came to me next day handing book back with words "I can click in Eclipse". I was shocked, not able to react. My first thought was probably something that I misjudged him. I realized whole point only later, but then I felt it is too late to return to that for him already closed matter.

The real meaning of those words was "I don't know and I don't know I don't know.". Really - he thought that book talks only about things Eclipse can do easily. But that was huge mistake - it talks about more important things like what are code smells, how to detect them, how to achieve better design with small steps, what to do if simple refactorings fail or they don't lead to nicer result and so on.

I believe this book taught me how to work a bit differently - be less concerned about immediate appeal of code I am currently writing, because I can change it easily when bigger picture is available. That I can Extract Method later when I know what it does and how to name it correctly. I do not worry about every aspect, because I know I can change it easily. And I know what my possibilities are, so I am able to spot opportunity when it occurs. I would say that spotting opportunity when it occurs is the most important part. If all code looks satisfying/passable to me, there is no possibility for improvement. I believe it was the first book that taught me something about aesthetics in code.

Looking back to this "incident" I think I missed good opportunity to help him, but it is quite possible his ego did not allowed me to, so maybe my reaction was OK. Since then I try to be more persuative in similar situations. So if you stumble on me, trying to help you, be tolerant and patient, please :-)

Project I am currently working on has rather sophisticated build system. I believe that huge project as this one is deserves it. It has many advantages and a few disadvantages. Problem is that it is optimized for Eclipse as all developers are using it.

Unfortunatelly, some features like:

• dependencies between modules done through jar files
• regeneration of Eclipse's project files by Ant (needed every time you update jar files)
• dependenent jars copied to target/
• fact that Eclipse does not distinguish between production and test sources

made my life with Idea miserable in the beginning. It used lot of memory, was slow and needed refresh of internal data often (very slow in Idea) and remote debugger was not able to switch to different module. I gave a chance to Eclipse (3 weeks) before returning to Idea with goal to overcome all these problems (plus those happening in Eclipse too like impossibility to refactor between projects) by custom scripts.

I started slowly, then I added more features. Because my goal was to fix problems in Eclipse/Idea integration, fix disadvantages in dependencies as well as to fix management of project I rejected an idea to create plugin as it would need learning huge Plugin SDK and it could not help me to solve all problems. I decided to go through command line scripts (not to mention I never liked to do project management related tasks through IDE). My scripts are done in Ruby.

I am able to clean all projects in directory by subsequent calling of 'ant clean' in all subdirectories:

def clean
    in_dirs_with 'build.xml' do
        system 'ant clean'
    end
end

I was really nicely surprised seeing how nice and readable those simple tasks could be. I added a few more:

def update
    in_dirs_with '.svn' do
        system 'svn up'
    end
end

def eclipse
    in_dirs_with '.classpath' do
        system 'ant eclipse'
    end
end

All magic is hidden in following method:

	def in_dirs_with(guard)
		Dir['*'].each do |dir|
			if File.exist?("#{dir}/#{guard}")
				puts "Processing #{dir}..."		
				Dir.chdir(dir) do
					raise Exception.new($?) unless yield
				end
			end
		end
	end

OK, less annoying things are handled, now I can get to fixing problems with Idea. I am not going to show any code for that, it is bigger, but I will describe what I have done:

• script finds all generated .classpath and replaces jar dependencies with known sources (fixed refactoring and debugging problems)
• script finds all .eml files (Idea keeps here information what .classpath belongs to module and what is missing in .classpath but Idea needs it). Script modifies it by stating which directories are tests and which directories to exclude from project.

With these two scripts my life is wonderful again (as it was before I joined this huge project with build system optimized for Eclipse). Idea responds immediately and I can refactor as no of my colleagues can :-) (well, they could use the one wiring modules together, because it modifies only .classpath, but they would need to install Ruby first).

Apart from that I have created small DSL that helps me to perform merges (merging multiple modules in Idea is rather annoying), but I needed it only twice. Example how merging file might look like follows:

Merger.new.
	from_revision(12305).
	from_branch('http://server/svn/branches/mybranch').
	to_branch('http://server/svn/branches/head').

	add_new('new_module').
	add_new('other_new_module').

	merge('changed_module1').
	merge('changed_module2')
end

If I tried to do it in Idea (similarly in Eclipse) I would need to state revisions and branches for every module that needs to be merged. Small script helped enormously with 10 modules I was merging last time. (Note: add_new is for adding module that was created in mybranch so it cannot be merged directly to head, at least I am not aware of directly working solution).

Doing these things is called yak shaving and considered problematic, but I have to say, my yak is shaved very well now and I guess time invested has been paid off for some time already.

I have changed my job 6 months ago to adapt to changes in my private life. I am still big fan of previous employer. Recently I started to use their product/service that was in early stage when I was leaving. Well, I used their other product while being there, so being their customer should not be new for me, but that one was stable and I've been in while this one is still in beta and I see from outside. I did not participate in development of either of them.

As can be expected this new product has issues. Bugs, usability problems, unfinished features. I expected that and it is not the part of problem why I decided to write about that. I always send my bug reports and suggestions. They are usually answered soon. Problem is when the answer contains "I asked and it should work". So it was not tried after my report, it was just believed it (still) works - maybe because it takes less time to assume than check and they have a lot of other things to do. But how long does it take to check that RSS feed does not contain any content? 20 seconds or less I guess.

My point is that experience have brought me completely new perspective. Till now I was always at provider's side and now I got to other side. Seeing different steps taken than I hoped for as a customer/user opened my eyes. Issues are not bad, only that having no clue when and if they will be resolved feels annoying. The service is free, so I do not feel ripped off and I understand their priorities have to be on paid tasks, but still it feels annoying. My current employer has better approach to handle these situations: acknowledge and thank for bringing to attention, assess, apologize and say when it is is expected to be fixed (followed by fixing it, of course). Taking this path is not only helping to keep good relationships between vendor and customers, but in fact can be felt as rewarding to customers, because they can be proud they helped with product/service.

For me, it means that I am now aware of these problems and I hope I will remember them next time I'll be assigned a bug.

I am big fan of two programs. Big means that I bought also upgrade. It also means I used to advocate both of them. This is not the case with one anymore. These products and their companies have many common things and many differences. Let's look at them both.

Similarities:

• Both products are excelent in what they offer, they have many unique features
• Both are commercial products surrounded by commercial and free competitors
• Both companies need to release new version every year to keep income
• Both companies need about half a year for finalizing public version to finished state (see later!)
• Both companies have a lot of bugs reported by customers which is normal (see later!)
• Both companies need to balance enhancing existing features vs. adding new
• I resist upgrading to new version of both products until some killer feature is added I must have
• Both products satisfy my needs in their respective area
• I have bought at least one upgrade of both of them in past
• Both companies distribute their products mainly through web (see later)
• Both companies have associated discussion forum for their products (see later)
• Features of both products are copied by competitors
• Both products need a lot of computing resources and are a bit slow (that means if they were twice as fast, I would be glad)

Before I get to their differences I am going to disclose them. I am comparing JetBrains with their IntelliJ Idea and DXO with their DXO Optics Pro. One is for SW development, other for processing photos from DSLRs (how surprising from me :-) ).

Differences:

• JetBrains starts with Early Access Program that can be used by owners of previous version for free, getting valuable feedback about problems and features driving final great product. DXO releases final (paid) version that is completely useless till version x.2
• JetBrains' developers are active in discussion forums trying to help, DXO ignores bug reports and tries to blame customers (indirectly for buying their terrible product!)
• When JetBrains releases new version it contains change list (detailed for EAP, somehow more generalized for update). DXO is able to release several updates without saying what was changed.
• If you buy new computer, update version of Java or switch to another language/library, there is fair chance you still can use your version of Idea. If you buy new camera you will probably need to buy new version of Optics Pro. Or if your new camera is supported by existing version of Optics Pro it is possible your existing lenses are not. And upgrading might not help you.
• I have seen JetBrains' server down, but DXO is master in this area. Many people are not able to download product/update, downloaded file is corrupted or even users are not able to activate their license after they paid for it. It can take days to be running again.
• Some people (former users of Optics Pro) are coming to forum for fun - to see how other more tolerant people struggle to use Optics Pro and are abused by DXO
• JetBrains care about their customers, DXO does not
• JetBrains care about their image, DXO does not (I am sure their management is not stupid, thus this conclusion is only one that I could make)

Am I going to buy upgrade of these products when they are finished?

• JetBrains: I am already using their 8.0 Milestone 1, hence the answer is probably yes.
• DXO: I am afraid to install their latest update 5.2.1 because nobody knows what was changed and there are long discussions about broken reading on RAW files. Nobody knows what will be offered by 6.0 and I hope I will not buy a new camera supported only by 6.0 if I still want to use my version of Optics Pro.

Why I preffer attitude of JetBrains?

• By releasing EAP soon and often people can try it to see if it works for them. As software developers they are usually striving for new features and they get them. Basically they get addicted to new version long before it is done!
• Released EAP has usually lot of bugs, but people do not feel robbed compared to what happens after paying for Optics Pro that is full of bugs (and refuses to start). Nobody will bash JetBrains, because the newest build (Release Candidate or even less) has 1234 bugs, but there are not many phlegmatics that would be satisfied with wonderful marketing materials promising something it cannot deliver 10 months after paying for product, because it is unstable and full of bugs. (To be fair, I waited patiently 8 months since 5.0 was shipped and bought 5.1 and I have never experienced the worst things described in forums. I consider myself lucky).

Why I wrote this

Now I am getting to reason why I am writing this. My intention is not to mock or ruin business for DXO. They are self sufficient it this area. Contrary, I try to help them in only way I can. Please, DXO, start to behave as a comercial company that plans to stay in business and start to do what your customers deserve from you. I have given you one example worth of following.

Oh, there is one positive twist about all this - I am really happy I did not encourage anybody to buy Optics Pro 5.x. I would not be able to apologise enough for that!