Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Comment: Re:Inventions vs. Engineering (Score 1) 59

They reject quite a few, try submitting one sometime. It takes time and effort to push it through. The real issue is that a patent should come with a working prototype described by the patent. No prototype, no patent, no patent filing date, no submarine extensions. Solves a whole host of issues right out of the gate not to mention removing entire classes of "ideas" or "business process" patents, reducing the latter back down to trade secrets which is where they should have stayed.

Comment: Re:Require patents to advance the state of the art (Score 1) 59

Beats me, but I wrote a notification service in 2007 using Kannel and that goes back to Oct 2004 date as the reference implementation for WAP 2.0.... Something tells me it's older than that. In fact, IIRC, I wrote an email/SMS sending app back around 2003 that leveraged some commercial service for another job, and they weren't new either, but I can't recall who that was.

Comment: Re:isn't IBM already mainly a services business?! (Score 1) 208

by Gr8Apes (#49580815) Attached to: IBM CIO Thinks Agile Development Might Save Company
Here's a only partly contrived example based on something I witnessed once in an order management system: Consider a search service, a datawarehouse server, an LDAP system, and a messaging system that all depend on aspects of a user definition. However, LDAP doesn't give a hoot about any of the others, and the SSO team does their thing in a relative vacuum. They work on LDAP, and have what they think is their own personal attribute in LDAP, let's call it a companyUserId. They've used this ID as a username for a while, and the datawarehouse folks, seeing it, used it in reports 6 months ago. The messaging system, after it was created, in a 100% Agile way, decided to use these usernames as an abstraction for the user. The SSO folks decided that the ID was badly designed, doesn't meet their need for rapid indexing, and convert them all to numbers. Or, the messaging folks decide to allow users to set those usernames to whatever they want, and don't do a uniqueness test. There's so many ways that things can be tested as components and work perfectly well but go to shit in a complex system if there's not a cohesive design in place and it's managed by someone. And before you go "SCRUM will solve all this" no it won't. There were 100s involved in this development effort.

Comment: Re:isn't IBM already mainly a services business?! (Score 2) 208

by Gr8Apes (#49579965) Attached to: IBM CIO Thinks Agile Development Might Save Company

It is a dirty little secret that complex enterprise solution projects fail more than half the time, often to the tune of 8 figures.

Agile won't save you from failure in these cases. Complex enterprise solutions by their nature require significant effort to get even the basic scaffolding up, and by the time they get to a scale where certain classes of problems become evident, you've already sunk quite a bit into the project. This isn't moving GUI widget from the left corner to the middle and something Agile is good at, but changing a data structure that is layered throughout 6 sets of services, for instance, one or two that the modeler may not even be aware of. This is where enterprise and data architects live and earn their pay, or fail and go to management to repeat their failures.

Do molecular biologists wear designer genes?