3 ms·

I think some people who write about enterprise software either haven't worked on really big enterprise software or don't realize how it came to be bad. The prob

I think some people who write about enterprise software either haven't worked on really big enterprise software or don't realize how it came to be bad. The problem isn't that suddenly your product started sucking -- mostly it's that inefficiencies or poor design decisions made 3 years ago suddenly start biting you in the ass. In other words, software ages like people -- year to year there's not a huge difference, but 10 years later you look back and say "what the fk happened?!" Now, some software just clearly wasn't designed with usability in mind. Much more, however, was probably designed with a limited goal that was forced to quickly adapt to more complex situations. Startups and web companies have it relatively easy -- you can simply change your code on your server and suddenly everyone's up to date. Other companies have to deal with backwards compatibility and standards and shipping and all the pains of large projects in general. The people who come in saying "Well the people in charge are just idiots. If I were in charge we'd have SCRUM and new languages and modern development practices and everything would fix itself immediately!" really don't know what they're talking about. I think that the article has some good points (not getting involved enough with the actual users is a big one), but they're really too young to say "we have found the Holy Grail!" Removing features, especially, strikes me as something which sounds like a good idea but can really hurt you as a business. When your customer is a 300 person mid-size corporation you can easily say, "well, we had to make some changes here and that feature had to go." When your customer is a retail giant employing 300,000 people all over the country, you think very, very carefully about removing that feature.

grease 16y ago
I agree. Server based software makes it easier to fix things in a continuous manner - ensuring that software doesn't suck over a period of time. Also agree with the "getting involved with real users" point. One of the ways to achieve this is to build and market for smaller firms - these tend to operate less bureaucratically, and also have a good chance that the buyer and user is same. This also allows for the software to be built in a more organic manner - the most crucial aspects first and then features that are incrementally useful.
jaygoldman 16y ago
Thanks for the comment Locke1689. You make some excellent points. (In the interest of full disclosure, I'm the Head of Marketing for Rypple.) Rypple itself may be young, but the guys who co-founded it are very experienced in the world of traditional, capital-E, Enterprise software. They were the head of sales and marketing at Workbrain, which they grew to $100m in revenue providing serious Enterprise solutions to the biggest companies in the world. They intimately understand how this world works and so they are well qualified to say that our approach is a much better one. You're absolutely right about it being easier when you're SaaS. We're confident that this is not a fad, for the very reasons you mention. Salesforce.com is hardly a startup anymore and is a significant player in the Enterprise space with an entirely SaaS-based solution. The next version of Office is rumored to be a Cloud solution. Even consumer-focused products like the AppleTV have gone from client-side storage to the Cloud. The strongest reaction to this post is around the idea of removing features, with lots of people saying "You can't do that!" and "Your customers will revolt!". We get that. It's the natural reaction after years of building software in the traditional way. Here's the thing though: our customers celebrate when we take features out. We get emails from them thanking us for keeping the app simple and jettisoning the cruft. We sometimes pull something out that we do get a strong reaction to, and then we work closely with the users who felt strongly to make the feature awesome and put it back in. Keep the comments coming! Thanks, Jay
- Locke1689 16y ago
  Thanks Jay, I love to have open dialog. Rypple itself may be young, but the guys who co-founded it are very experienced in the world of traditional, capital-E, Enterprise software. They were the head of sales and marketing at Workbrain, which they grew to $100m in revenue providing serious Enterprise solutions to the biggest companies in the world. They intimately understand how this world works and so they are well qualified to say that our approach is a much better one. I didn't mean to insinuate that the companies are somehow unqualified to make those judgements. It's usually the armchair experts that make these kind of comments. When I referred to the young age of the company I was really referring to the company model itself instead of the people inside. I wish you the best of luck but my point was mainly that knowledge and acumen are great, but when it gets down to it the proof is in the pudding. I hope you guys will still be here in 10-15 years and it will be great if you are and the model does scale into the long term, but I think it's premature to say it's definitely succeeded before the eggs have hatched. The strongest reaction to this post is around the idea of removing features, with lots of people saying "You can't do that!" and "Your customers will revolt!". We get that. It's the natural reaction after years of building software in the traditional way. Here's the thing though: our customers celebrate when we take features out. We get emails from them thanking us for keeping the app simple and jettisoning the cruft. We sometimes pull something out that we do get a strong reaction to, and then we work closely with the users who felt strongly to make the feature awesome and put it back in. I think this really depends. Mainly it depends on what kinds of features you're removing. One thing I'd really caution against is changing your API every couple months. That is the kind of thing that can drive your company into a hole they can't crawl out of.

grease 16y ago

I agree. Server based software makes it easier to fix things in a continuous manner - ensuring that software doesn't suck over a period of time. Also agree with the "getting involved with real users" point. One of the ways to achieve this is to build and market for smaller firms - these tend to operate less bureaucratically, and also have a good chance that the buyer and user is same. This also allows for the software to be built in a more organic manner - the most crucial aspects first and then features that are incrementally useful.

jaygoldman 16y ago

Thanks for the comment Locke1689. You make some excellent points. (In the interest of full disclosure, I'm the Head of Marketing for Rypple.) Rypple itself may be young, but the guys who co-founded it are very experienced in the world of traditional, capital-E, Enterprise software. They were the head of sales and marketing at Workbrain, which they grew to $100m in revenue providing serious Enterprise solutions to the biggest companies in the world. They intimately understand how this world works and so they are well qualified to say that our approach is a much better one. You're absolutely right about it being easier when you're SaaS. We're confident that this is not a fad, for the very reasons you mention. Salesforce.com is hardly a startup anymore and is a significant player in the Enterprise space with an entirely SaaS-based solution. The next version of Office is rumored to be a Cloud solution. Even consumer-focused products like the AppleTV have gone from client-side storage to the Cloud. The strongest reaction to this post is around the idea of removing features, with lots of people saying "You can't do that!" and "Your customers will revolt!". We get that. It's the natural reaction after years of building software in the traditional way. Here's the thing though: our customers celebrate when we take features out. We get emails from them thanking us for keeping the app simple and jettisoning the cruft. We sometimes pull something out that we do get a strong reaction to, and then we work closely with the users who felt strongly to make the feature awesome and put it back in. Keep the comments coming! Thanks, Jay

Locke1689 16y ago
Thanks Jay, I love to have open dialog. Rypple itself may be young, but the guys who co-founded it are very experienced in the world of traditional, capital-E, Enterprise software. They were the head of sales and marketing at Workbrain, which they grew to $100m in revenue providing serious Enterprise solutions to the biggest companies in the world. They intimately understand how this world works and so they are well qualified to say that our approach is a much better one. I didn't mean to insinuate that the companies are somehow unqualified to make those judgements. It's usually the armchair experts that make these kind of comments. When I referred to the young age of the company I was really referring to the company model itself instead of the people inside. I wish you the best of luck but my point was mainly that knowledge and acumen are great, but when it gets down to it the proof is in the pudding. I hope you guys will still be here in 10-15 years and it will be great if you are and the model does scale into the long term, but I think it's premature to say it's definitely succeeded before the eggs have hatched. The strongest reaction to this post is around the idea of removing features, with lots of people saying "You can't do that!" and "Your customers will revolt!". We get that. It's the natural reaction after years of building software in the traditional way. Here's the thing though: our customers celebrate when we take features out. We get emails from them thanking us for keeping the app simple and jettisoning the cruft. We sometimes pull something out that we do get a strong reaction to, and then we work closely with the users who felt strongly to make the feature awesome and put it back in. I think this really depends. Mainly it depends on what kinds of features you're removing. One thing I'd really caution against is changing your API every couple months. That is the kind of thing that can drive your company into a hole they can't crawl out of.