« 7 Attainable Goals | Main | Radical Retention: Nerds Need Love Too »

February 21, 2011


Feed You can follow this conversation by subscribing to the comment feed for this post.


I do believe that we should use the best tools money can buy, but I had some painful experiences with this approach:

a) Many times even "the best" and enormously expensive tool was a complete usability and integration disaster.

b) Companies tend to drop bad open-source tools easier than bad tool that cost mountains of money. So I'm less worried to be stuck when choosing open-source.

c) Only free tools can be integrated as a "partisan" effort by motivated workers.

d) I suffered so much from version control, defect and project management tools, be they free or not, that it will require *a lot* of convincing to make me believe there is a solution that integrates easily and doesn't require constant maintenance.

e) Considering the previous point, I will be reluctant to switch from free tool that works with certain amount of pain to a costly tool that promises miraculous solutions.

f) Many times the solution is not the tool but the process, and those are not bought with money. If I have little hope that the process will change, I won't waste money for nothing.

Bottom line, I'm skeptical, I don't believe easily anymore and I'm sick and tired of silver bullet solutions that flood the market nowadays.

Eugene Jorov

a) So true.
b) Worry not about companies, that's too big a scope. Make sure you take care of your team - the rest will work out.
c) Hardly so, I haven't seen a single tool that doesn't provide at least 30 days of free trial. If you are serious, you can always ask the vendor to extend that to 60.
d) This only proves that the need is big. I won't recommend FogBugz seen I haven't tried it out.
e) Aha! That's my point. If something works well, look elsewhere. Just check what the most painful dev. experience is - and handle that.
f++) Sounds like you are not ready for an integrated solution. Try to identify problems with individual tools. Once you get in the habit of process awareness and improvement, it'll be easier to imagine taking on a bigger system.
Thank you for your from-the-heart comments, I definitely identify with your life experience. This only proves giving up is not an option :)

Costya Zhorov

I think that the issue of having "the best" version control programm (for your specific needs of course) has even greater importance... The frustration that might be accompanied to the Branching and Merging process, might lead to bad descision making.
The development team might try to ignore the correct development process and avoid Branching and Merging at necessary times. And the potential danger in that, is far greater than waisted development hours.


Basically I agree with what you wrote.
The problem is that you usually need to convince those who have the money and they see this as an expendable thing most of the time.
The time of the engineer was already paid for, new tools are new expenses...
The difficulty is that you probably can never prove ROI for those things and need to convince using common logic and slogans alone.
You can never know what the engineer is doing with his now free 20% of his time (coffee brakes and family – good for him, no extra profit for business).
I say, if you manage to convince it is worth the cost - buy before they change their minds!

Eugene Jorov

@Tom: I tend to believe convincing the management to invest in good engineering is one of the major responsibilities of the team leader. About proving ROI - it's probably easier than you think. If you collect data - then you have proof, while the management only have their intuition and beliefs to present in the argument.

Eugene Jorov

@Kot: Absolutely agree, branching and merging is one of the prime suspects whenever you start analyzing dev. problems.


@Kot,@EJ: What are the existing alternatives to branching and merging?

Eugene Jorov

@FireAphis: For starters, forget branching and switch to distributed source control. Mercurial and Git are probably the most popular tools today. Merging is completely different then: instead of trying to combine to foreign revisions like Subversion does, the distributed guys keep track of the changesets that led to the two different code versions. That info turns re-combining the code into a smoother and more reasonable affair. Take a look at Joel's excellent Mercurial tutorial for more:


@EJ: You make it sound so easy…
I dare you collect data and show me ROI for using Microsoft word, excel or office.
Please show me what percentage of your company profit you can relate directly for using those applications.
If you can do that, I am convinced you can do it for engineering support applications as well.
I think it is the other way around my friend – you only have your intuition and beliefs in this argument…

Eugene Jorov

@Tom: Usually I'm eager to respond to any challenges, but this time I'll pass. I doubt my success with improving the MSOffice-related situation in my team will help you reach a decision to do the same. A change starts from inside, no one can make you get going. However, I can recall a very similar situation that I acted upon recently. An average build in a project I was working on took about 5 minutes, which was devastating to me. The rest of the group just seemed to ignore that number and busied themselves with Facebook and such while building - a real concentration killer. I spent two days to refactor some Makefiles and got it under 40 seconds. I published the results throughout the company and went back to work. Two conclusions: 1) If you feel something's wrong - investigate and fix it. 2) No on cared to look into similar problems in other projects after my report, hence while I encourage you to handle that MSOffice issue, I'd rather not take that challenge on myself.

The comments to this entry are closed.