Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Siebel Systems (SEBL) - strong buy? -- Ignore unavailable to you. Want to Upgrade?

To: Lizzie Tudor who wrote (6724)	5/21/2003 2:23:30 PM
From: Stock Farmer	Read Replies (1) \| Respond to of 6974

Lizzie, let me guess, you've never found examples of architectural defects in SV based software, huh? And you mean to tell me that your idea of good communication with respect to software engineering consists of "how's it going" and "fine" via a transatlantic telephone call??? Doesn't smack of 'state of the art' design methodology to me. Or management discipline. Sounds more like ad-hocracy to me. For example, how come you didn't spot the architectural flaw earlier? Do you normally wait 'till the code comes back to review the architecture? That's the kind of hacker methodology we used back in the 80's. Me, I'm used to more modern methodologies which include up-front review and sign-off of level I, II and III architecture, at least! Don't you? If you want to indulge in ex-ante data-mining and select a development program that was obviously using a flawed methodology to prove a point, feel free. It's not very intellectually honest to do so, however. And if that's the only kind of example you know of, well, then it would surprise me if you have any luck whatsoever with multi-site development. I've seen good multi-site developments, and I've seen bad too. In my experience, the result depends more on the communication skills and design methodology imposed by the folks in charge at the interface than on the implementation skills at either end. It's also hard to get right the first time. I mean, just getting people from San Antonio to understand people from Birmingham when they speak to each other is a problem, even if both of 'em think they know "English". Even if both are experts in their respective fields. The solutions aren't difficult or even time consuming. And in fact, the discipline even improves the end-to-end development time for projects that are run entirely in one site. But it sure as heck doesn't rest on "How's everything going... Fine... OK.. click". Based on some of our dialogue so far, it wouldn't surprise me at all that your experience with offshore development would be quite negative. And that you would also fail to admit your contribution to the result. But if you fail where others succeed, then it's a good idea to look towards yourself as an opportunity for improvement rather than blame those with whom you are unable to work effectively. John

To: Lizzie Tudor who wrote (6724)	5/21/2003 3:09:36 PM
From: Scott Meyer	Read Replies (1) \| Respond to of 6974

Herein lies the problem with offshore development. Actually it is a problem with the way people want to think about software development... It isn't a top down activity. Some things are just assumed when you work with strong people locally. Otoh when you are working with some offshore facility, it is like trying to explain changing a tire on a car to a blind man, this is a huge strain on your tech leads who have to watch these offshore devt teams constantly so they don't make huge mistakes like this. If it takes your tech leads 100% of their time to police these people offshore, then it is actually MORE expensive working this way vs. what can be done here. At a certain point, specification becomes unworkable. You might as well write the code yourself... The problem has nothing to do with offshore or onshore. Projects fail this way in SV too. The best development teams are dynamic, reactive and flexible in pursuit of a large-scale goal. Ideas get tried and discarded. Sometimes you find a bit of software to buy. Sometimes a partner comes up with a new interface. Good developers adapt and bad ones deliver a product that is already obsolete. The problem is that detailed specification and the business relationship that goes along with outsourcing criple your ability to respond to changes in the world. The benefits of responsiveness far outweigh saving 50% on your labor costs. Now to relate this back to SEBL. I interviewed with them when they were still back in Menlo Park and they had the most amazingly detailed product specification I'd ever seen. On the one hand, I was pretty sure they were going to do really well for the first few years, but I wondered a bit how things would work out after their product had been in the market for a few years and everyone had the chance to copy the important features. At that point, roughly where we are now, the first mover advantages are all gone and all the players are playing the software development game on the same field. And... ?