FOAK: Bugzilla anyone?

Free software: the development gang tells the management what it wants,
and downloads it. End of story.

Paying software: enter the salesperson. Doesn't even talk to the
developers. Needs to get management on his side. Demonstrates
management-oriented features of the software (that usually involve more
work from the developers). Darwinian evolution ticks in: all such
software ends up being more management-friendly than developer-friendly.

 

Funnily enough, I can relate to that on hardware products.

BTW, will be in touch tomorrow.

 

If only.

And frankly I'd be pissed if any of my developers did that. It's my
responsibility to determine the toolset for a project, and I'll have
thought of a lot more considerations than the developers will have
with regard to the overall project.

Not that in most of our environments they'd be allowed to install
anything anyway.

 

We do exactly that. Trac and SVN authentication is actually handled by
Apache, it's quite straightforward to set up.

 

I'm not talking about one developer deciding to use his own pet tools.
I'm talking about the developer gang deciding (either collectively, or
through some lead person) what they need.

In my galaxy developers often have to install their own standard
development environment from a blank system, an install server, and a
Powerpoint written by someone in the developer support team (when the
project is big enough to warrant such a job).

 

Haha. Hahahahaha. Bwaahaahaha.

Large corporations tend to launch large projects to determine future
architecture and development environments. The development teams'
input is always sought out, of course, and is highly valuable. But is
also often the first thing to be ignored in the long and painful
search to find the worst possible combination of functionality (or
lack of) imaginable.

 

I was recently asked by my boss to look into Web Services, as Big Boss
in US has decreed that's the Current Big Thing that we probably ought
to be using.

When I enquired as to why we were approaching it as "How can we use Web
Services" instead of "What technology can best serve us"[1] I was told
to JFDI.


[1] Which may or may not be Web Services.

 

That leads to things like speccing an Oracle database just to do
something trivial like store settings, on the principle that it allows
the "we use oracle" tickbox to be checked. Customers like things to be
enterprisey, you see.

 

We used to have a Big Boss like that, & ended up with a load of shite
in Java as a result. Thankfully both the Big Boss & the IT Director who
said yes are ancient history now, & it's up to me to decide which
technologies we use.

 

Ta, will Googlify that later.

 

Did anyone say "Service Oriented Architecture"?

 

No. Move along.

 

I dunno. I'm still struggling with calling them a "Scrum".

Pretty much my world as well. Although our tools tend to be a little
expensive and we have to get the client to sign off buying licences.

 

SOA != WS

For example, the current SOA I'm working with is all done through JMS
(http://java.sun.com/products/jms/), and it works bloody well.

 

Agreed, but WS seems to be the trend in SOA.

And I know JMS, and before the good ol' MQ Series

 

Whew I *really* don't miss software/application development

 

I wouldn't be. Although it's "flavour of the month" at the moment,
it's actually pretty shit.

It's a nasty mashup of "design by committee" and plain old "making it
up as you go along". With silly rules.

 

This saved me reading several books and meeting some evangelists.

 

fair enough. I'm used to working in a proper SDLC/ITIL environment,
with proper checks and boundaries.

well, "making it up as you go along" can have its place, for instance
in prototyping/storyboarding/wireframing etc.

 

no, it's shit.

And that's not even mentioning the whole world of pain that is Sarbox
compliance.