

Nobody cares what tools you use - glenngillen
http://rubypond.com/blog/nobody-cares-what-tools-you-use

======
devmonk
Pretty good post, but I think it is generalizing possibly a bit too much and
could be misinterpreted:

1\. 'ask yourself “is this going to make me deliver the product faster?”. If
the answer is no, don’t do it'

While on a whole it's true, but some aspects of process (change control, QA,
etc.) can:

a. make the delivery of the product go more smoothly, b. increase the quality
of the product, c. decrease time needed to fix bugs, fix data, or eat crow
after product launch, and d. decrease chaos, confusion, and late hours spent
trying to figure out what part of several issues caused some other issue.

2\. 'nobody cares what tools you use'

Not true. Some shops hate (insert anything here) with a vengeance or have
something in place that prohibits what you could use or how you could do
something.

At the same time, I agree for the most part that _users_ , on the whole, don't
care how it is implemented.

That said, I certainly agree with the notes on Cucumber, etc. being something
that seems good to the developer but that the business becomes less interested
in as time goes on.

I really enjoyed doing full-on XP before with index cards, etc. Luckily we did
that with our manager representing the customer. Whenever there has actually
been a customer truly involved in the process directly, no matter what you do
with wireframes, showing them results at end of iteration, etc., the customer
(whether it be one or many) always has a personality and thought and work
processes that affect the development process. You can slap Jira and workflow,
etc. on it, but it doesn't matter. You have to work with the customer- there
is no choice.

~~~
tomjen3
The shops may hate it, but if the software can be better written in a
different language and the software is important for their business it doesn't
matter - either they use the best or some other company does which then
replaces them.

Most of the places this happens are properly already ineffective companies -
which doesn't notice they aren't effective anymore and therefore gets eaten by
bigger companies.

~~~
_delirium
There are sometimes integration costs, though--- if the company runs almost
everything on a Microsoft stack, and you deliver them something that runs on a
typical Unix stack, or vice versa, it's not going to necessarily be very
smooth for them, even if the actual functionality is great.

~~~
glenngillen
I think that is where the "best for the business" disclaimer comes in. You
need to make the decision based not only on your own development efficiency
but those you are impacting too.

A recent example is at my current client, quite a large company with a lot of
"legacy" investment. I can't work without using git as part of my workflow any
more, but I need not mandate it for this new project. Instead we stick with
svn, use git-svn to give us the features we need, and bananajour for sharing
code easily amongst ourselves. We've in a sense sandboxed ourselves so our
preferences don't impact the infrastructure team.

As tends to happen, they eventually start to wonder what all the fuss is and
want a demo of why it's cool. Now others are using git-svn too, the barrier to
overcome throughout the rest of the business is rapidly decreasing.

I realise it's an easy example, but with a little creativity there is often a
similar solution to most problems regarding platform/framework/etc. Not
always, but often.

------
varikin
For the most part, I agree with this, except where people do care what tools
you use for the wrong reasons. For example, a VP of Something dictates that
you use DB2 just because he wants to be on the good side of IBM. Or VP of
Something Else says you can't use Apache because she distrusts open source and
says you have to use IIS with your Java application.

