Prev: Tanix - you generated a REAL BUG!
Next: Set processor core affinity to a thread
From: Le Chaud Lapin on 22 Jan 2010 13:02
Hi All,

It is becoming increasingly apparent, at least to me, that Microsoft
is relying more on a "lock-in-the-customer" strategy with their
products. This strategy has always been present to some extent, but
now it seems to be on over-drive.

I see it everywhere, in C++.NET, crypto, Silverlight, web services.
Perhaps they feel this is the only way to stave off loss of market
share due to increasing inability to control What-Comes-Next.

Take Team Foundation Server.

It reeks of "'I'm-a-genius-because-I-found-yet-another-clever-way-to-
milk-the-customer" marketing-head mentality.

Sharepoint? IIS? SQL Sever 2008?

Are you serious?

I think Microsoft had at least two objectives in creating TFS:

1. Force developers to marry the baker while buying bread. They
deliberately create somewhat artificial interdependencies amongst a
cadre of their products, hoping to seed companies with products that
are difficult and expensive to deploy, and, necessarily, difficult and
expensive to extract in favor of an alternative.

2. Raise the complexity of deployability so that seasoned engineers
become utterly frustrated with TFS deployment mess and complain. Then
managers will take these complaints as cries of technical
insurmountability and think,

"Wow...since it is so technical, it must be very deep...even my top
engineers struggle with it..what power it must contain!!!!...maybe we
need a 'dedicated resource' to manage all this and keep my engineers
happy."

This is how it starts.

Now you have the Dedicated Resource, Ralph, the guy that is the anti-
thesis of efficiency and economy in software engineering. He is long
past his prime, rather slothy compared to rest of team,
disproportionately compensated for what he actually does, very much
fond of weekly meetings that accomplish virtually nothing, quiet in is
element, but fiercely protective of his turf, known by all as the High
Priest of the Big Red Build Button, a "critical asset" according to
management, one who will scream murder if anyone even *thinks* about
trying to untangle the nauseatingly complex hairball of interdependent
"tools" that he has, perhaps subconciously, created over a period of
years as a way toward self-preservation. He has an answer for every
detractor:

New-Hire: "Hey Ralph, I was just looking at your diagram of our build
cycle, and...well...not to be too critical, but I found it massively
over-complicated..."

Ralph: "It grew organically."

Someone in Microsoft must have been dreaming of the windfall of
revenue that would come creating these interdependencies of multiple
Microsoft products based on the TFS-complex, the long-term benefits to
Microsoft due to its inextricability, and of course, Ralph,
effectively an internal evangelist, who, once "installed", will
probably be uninstallable.

-Le Chaud Lapin-
From: Le Chaud Lapin on 22 Jan 2010 14:06
On Jan 22, 12:02 pm, Le Chaud Lapin <jaibudu...(a)gmail.com> wrote:
> Someone in Microsoft must have been dreaming of the windfall of
> revenue that would come creating these interdependencies of multiple
> Microsoft products based on the TFS-complex, the long-term benefits to
> Microsoft due to its inextricability, and of course, Ralph,
> effectively an internal evangelist, who, once "installed", will
> probably be uninstallable.

After I wrote this post on Google Groups hit the ENTER key, I noticed
a Google advert off-to-the-right that said, "TFS is a complex
product." There was link to a consulting company dedicated to helping
manage TFS.

I thought about that about that for a moment. A consultant, whose
entire company exists on the predication of a product being complex.
Mind you, we are not talking about guidance systems for missiles or
anything. It's just source control!

So I googled for "Team Foundation Server Complex", and found that MSDN
takes the top two links, but there are many other links, and many of
my brothers of software engineering agree that Microsoft really goofed
up with this Team Foundation Server mess.

This morning, I felt uneasy about ~not~ using a Microsoft solution.
After all, the Visual Studio IDE proper *is* an excellent product, as
is the C++ compiler that comes with it, IMO, so I kept second-
guessing, thinking perhaps I was not giving proper objective
assessment.

But after reading the comments of others on the Web, all my uneasiness
is completely gone.

There is on way in h*ll that Visual Studio Team System is coming
anywhere near my engineering team.

We will continue to use SVN.

But we do need a good bug tracking system...

-Le Chaud Lapin-
From: consul on 22 Jan 2010 14:40
Le Chaud Lapin wrote:
> On Jan 22, 12:02 pm, Le Chaud Lapin <jaibudu...(a)gmail.com> wrote:
>> Someone in Microsoft must have been dreaming of the windfall of
>> revenue that would come creating these interdependencies of multiple
>> Microsoft products based on the TFS-complex, the long-term benefits to
>> Microsoft due to its inextricability, and of course, Ralph,
>> effectively an internal evangelist, who, once "installed", will
>> probably be uninstallable.
>
> After I wrote this post on Google Groups hit the ENTER key, I noticed
> a Google advert off-to-the-right that said, "TFS is a complex
> product." There was link to a consulting company dedicated to helping
> manage TFS.
>
> I thought about that about that for a moment. A consultant, whose
> entire company exists on the predication of a product being complex.
> Mind you, we are not talking about guidance systems for missiles or
> anything. It's just source control!
>
> So I googled for "Team Foundation Server Complex", and found that MSDN
> takes the top two links, but there are many other links, and many of
> my brothers of software engineering agree that Microsoft really goofed
> up with this Team Foundation Server mess.
>
> This morning, I felt uneasy about ~not~ using a Microsoft solution.
> After all, the Visual Studio IDE proper *is* an excellent product, as
> is the C++ compiler that comes with it, IMO, so I kept second-
> guessing, thinking perhaps I was not giving proper objective
> assessment.
>
> But after reading the comments of others on the Web, all my uneasiness
> is completely gone.
>
> There is on way in h*ll that Visual Studio Team System is coming
> anywhere near my engineering team.
>
> We will continue to use SVN.
>
> But we do need a good bug tracking system...
>
> -Le Chaud Lapin-

Try this:
http://sourceforge.net/projects/gitextensions/
Much better than SVN
From: Stefan Kuhr on 22 Jan 2010 17:20
Hi Le Chaud Lapin,

On 1/22/2010 8:06 PM, Le Chaud Lapin wrote:
> On Jan 22, 12:02 pm, Le Chaud Lapin<jaibudu...(a)gmail.com> wrote:
> <snip>
> We will continue to use SVN.
>
> But we do need a good bug tracking system...
>

What bug tracking system do you currently use and what is it that makes
you consider it not being a good bug tracking system?

Just curious,

--
S
From: Le Chaud Lapin on 22 Jan 2010 22:02
On Jan 22, 4:20 pm, Stefan Kuhr <kustt...(a)gmx.li> wrote:
> Hi Le Chaud Lapin,
>
> On 1/22/2010 8:06 PM, Le Chaud Lapin wrote:
>
> > On Jan 22, 12:02 pm, Le Chaud Lapin<jaibudu...(a)gmail.com>  wrote:
> > <snip>
> > We will continue to use SVN.
>
> > But we do need a good bug tracking system...
>
> What bug tracking system do you currently use and what is it that makes
> you consider it not being a good bug tracking system?

We're using the...

"hmm...wonder why that crashed...Hey JF! Your software crashed!"

system. :)

We'd been using FlySpray, but noticed that since our team is really
small, < 10 people, it was better to just let each person hack at what
belongs to him.

That is changing as we get close to a real alpha release.

-Le Chaud Lapin-
 |  Next  |  Last
Pages: 1 2
Prev: Tanix - you generated a REAL BUG!
Next: Set processor core affinity to a thread