Bugginess
Too much attention is paid to the off the shelf software and technology selections that are made in enterprises. Being a developer, I have always tended to advise customers to buy the boring stuff and build the fun stuff. But how do they decide what to buy?
It's seldom the users or anyone closely involved that makes the big budget decisions. This quote from James McGovern (formerly respected- now entirely too vehemently anti-Ruby to be taken seriously) shows one form of the insanity: "For example, If I were to champion use of an open source Enterprise Service Bus such as ServiceMix and figured out a way to keep support internally while another colleague say championed purchase of a $5 million closed source Service Bus, which one do you think will get promoted quicker?" It's soo true. It applies to project staff size too. In Tom Demarco's "Slack" he talks about the manager that is bullied into accepting a larger staff and shorter timeline for a project. I like the Ruby on Rails thing David HH said this week (roughly): "[Rails is for] small teams doing big things." I am not really fond of his attitude though...yikes. I guess he's a magnet for criticism.
Back on topic though. Too often the comparison comes down to a feature list type thing, check or no check usually. Here are things that people don't consider enough when doing product evaluations- how hard is it to install/upgrade/maintain, how buggy is it, how is the usability, how well documented is the API/integration mechanism, how does it perform in the real world, and it is pretty enough to stare at day-in/day-out for a few years. I was in a meeting today where the consensus was that ESRI software is pretty buggy, but "so what"? Lots of people think Microsoft software is pretty buggy. I don't see the ESRI alternatives as being significantly less buggy, but maybe if that started to become a decision factor in enterprise software acquisition, it could become a point of competition. Not so much about how many map projections you support, but how well you do whatever it is that you do.
Those are some rather rambling thoughts- but I am really concerned by the poor choices I see made in enterprise software, and the bureaucracies that enshrine those choices as the only options for years to come.
2 comments:
Some really good points there. I think part of the problem is that people are looking for *THE* GIS solution when the optimal solution usually involves integrating multiple programs into a workflow that suits your needs. In my work, we use ESRI software but about half the time it just isn't cut out for the task, either due to bugs or lack of certain functionality. So we turn to GRASS, GDAL, OGR, PostGIS or Mapserver, etc. And often these aren't cut out for the task either so we have to search for another solution or roll our own.
It takes alot of time and experimentation to find out which software is optimal for certain tasks but it's a crazy to think that any one software package will cover all your needs. That's not what the budget manager needs to hear but its the truth.
Glad you at least agreed with my perspective on spending money within the enterprise. Does this still make me too enterprisey for speaking about it?
Can I at least get a little respect for acknowledging when we are too enterprisey and when we are not?
Do you think you can get the Ruby community to acknowledge that at times they are too anti-enterprisey?
FYI. I am not anti-Ruby. I just want folks in the community to acknowledge alternative perspectives. Ruby has its place.
Hype is the plaque in the house of software...
Post a Comment