Just a meta comment about these lessons learned posts. The motivation behind these is to promote the product in question and one must therefore take them with a grain of salt. Peer reviewed research is more reliable.
[deleted]
We Just Undid Three Months of Dev work. Here's What We Learned.
11–20 of 33 posts
Re: We Just Undid Three Months of Dev work. Here's What We Learned.
#12This reminds me of one of my biggest internal conflicts: when to optimize.
"Premature optimization" has earned a negative reputation because it has a tendency to inflate dev schedules unnecessarily.
So I tend to just crank something, anything out just to have something. Once you can see what you have, it's often a lot easier to modify than come up with in the first place.
OTOH, I like to think that everything I build is a foundation for the next thing to be built upon it. I am constantly getting bitten in the ass by some grossly underperforming building block. If a prototype runs poorly a dozen times, it's a concern. If the same code runs poorly a million times, it's a disaster.
It's a constant trade-off. Get something running vs. build solid building blocks. Make a mistake one way and never release. Make a mistake the other way and have a time bomb to clean up. Sounds like OP has a lot of the same issues.
Re: We Just Undid Three Months of Dev work. Here's What We Learned.
#13Earlier quoted context omitted.
If you want to dismiss a post on that theory, you should remove the links to your products in your profile.
There is no need to dismiss all such posts. Some may be interesting/educational regardless. But you do need to keep in mind the primary motivation behind them -- marketing.
Almost everything submitted here has marketing as an ulterior motive. They're either marketing a product or themselves. But thanks for the reminder.
Re: We Just Undid Three Months of Dev work. Here's What We Learned.
#14I wish I could send this to my boss. The functionality I'm working on right now was requested by a single client and is really only applicable to their unique billing situation. Why am I spending so much time on something that is going to have so little payoff, and yet which adds so much additional complexity to the system? But I've only been here a month and I don't feel like I can cast a dissenting voice. Maybe I'm…
Being vocal about imperfections in the development cycle and suggesting improvements that matter to the bottom line is not dissent. It's important to have open communication about this very topic - it improves the pipeline and keeps margins where they need to be. Be confident and prepared with data, and make yourself an asset to your company, not just a keypusher! :)
When discussing the merit's of this feature be open minded that you may not have all the information they had in deciding to implement it. Perhaps this is heavily requested by the sales department or by other customers further up the pipeline. Maybe the company threatened to take their business elsewhere.
It's always less obnoxious to approach potentially illogical situations by giving someone the benefit of doubt. So, while you collect your 'data', also do some brainstorming on area's where the feature your adding makes a ton of sense, and might even open up new sales channels or markets.
Instead of assuming there's been some catastrophic mistake you must remedy, and instead of assuming that management puts no value on your time, try assuming that they have good reasons for it that you, especially being their for a month, might not have been fully explained. Quite often the problem is communication, not intent to waste money.
At the end, if all your effort is for seemingly insignificant return, smile and do an amazing job. Repeat until you grow weary and embattled, then leave for another job with a different set of problems.
Re: We Just Undid Three Months of Dev work. Here's What We Learned.
#15Earlier quoted context omitted.
There is no need to dismiss all such posts. Some may be interesting/educational regardless. But you do need to keep in mind the primary motivation behind them -- marketing.
Almost everything submitted here has marketing as an ulterior motive. They're either marketing a product or themselves. But thanks for the reminder.
[deleted]
Re: We Just Undid Three Months of Dev work. Here's What We Learned.
#16I think the real lesson to learn here is to never assume anything. They assumed performance wouldn't be a problem, so they didn't test for it when prototyping, and they didn't make those tests part of their development cycle. It's tough, these things, especially if you're talking about a feature you personally appreciate a lot. The article talks about the performance problems leading focus away from actively marketin…
They assumed performance wouldn't be a problem
We did pretty extensive performance tests, but not for long enough. We load tested tested for hours at a time, and the problems started to show up after days of production load and really compounded after that. It's probably a topic for another post, but the performance of database tables with a lot of churn (rows being frequently inserted and deleted) really degrades over time.
Re: We Just Undid Three Months of Dev work. Here's What We Learned.
#17Earlier quoted context omitted.
On the other hand, punting on any hard problems just makes it that much easier for your competitors.
You mean hard problems that matter . There are a lot of hard problems startups try to solve which no one cares about. That's the trap to avoid. Fixing something hard does not inherently make your company valuable in the marketplace.
The problem with this ideas is that you don't get to decide which hard problems matter, but your users will not really know if the feature matters until you have made a real effort at providing the feature. There is a particularly insidious meme going around (usually from the so-called "lean startup" crowd) that building a lame/simple version first to see if people like the feature is how you learn what your users want. The problem with this is that you never know if people don't like the feature because the problem you are solving is not important to them or because your half-assed "iteration" has led them to decide that you don't have the chops to solve the problem so they should look elsewhere. I can't even count the number of times I have seen one company introduce a poorly implemented version of a feature, pull the feature or let it languish (presumably "because our metrics show no one wants it"), and then watch as customers flock to another company that actually solved the hard problem.
Fixing a hard problem does not automatically make your company more valuable, but failing to fix a hard problem will never increase the value of your company.
Re: We Just Undid Three Months of Dev work. Here's What We Learned.
#18I think the real lesson to learn here is to never assume anything. They assumed performance wouldn't be a problem, so they didn't test for it when prototyping, and they didn't make those tests part of their development cycle. It's tough, these things, especially if you're talking about a feature you personally appreciate a lot. The article talks about the performance problems leading focus away from actively marketin…
They assumed performance wouldn't be a problem We did pretty extensive performance tests, but not for long enough. We load tested tested for hours at a time, and the problems started to show up after days of production load and really compounded after that. It's probably a topic for another post, but the performance of database tables with a lot of churn (rows being frequently inserted and deleted) really degrades ov…
Guess that's my bad for assuming you thought performance wouldn't be a problem. :-)
Re: We Just Undid Three Months of Dev work. Here's What We Learned.
#19I wish I could send this to my boss. The functionality I'm working on right now was requested by a single client and is really only applicable to their unique billing situation. Why am I spending so much time on something that is going to have so little payoff, and yet which adds so much additional complexity to the system? But I've only been here a month and I don't feel like I can cast a dissenting voice. Maybe I'm…
I don't know the details of your particular situation. That said, I've been in situations where that "single client" accounts for 75% of the user base and more of the revenue. Sometimes you give the client anything they ask for :)
Re: We Just Undid Three Months of Dev work. Here's What We Learned.
#20Earlier quoted context omitted.
You mean hard problems that matter . There are a lot of hard problems startups try to solve which no one cares about. That's the trap to avoid. Fixing something hard does not inherently make your company valuable in the marketplace.
The problem with this ideas is that you don't get to decide which hard problems matter, but your users will not really know if the feature matters until you have made a real effort at providing the feature. There is a particularly insidious meme going around (usually from the so-called "lean startup" crowd) that building a lame/simple version first to see if people like the feature is how you learn what your users wa…
your half-assed "iteration" has led them to decide that you don't have the chops to solve the problem
While this theory sounds good, it is disproven time and again by initial half-baked versions of sites that then go on to take off. Just check the original launch of YouTube, Digg, facebook.
Also, a HUGE idea coming from lean startup way is to invest very little in marketing until you have a product users like. You don't need to get one million users to tell you a product sucks. Often, 50 would do. Now if you are saying that 50 users writing off your product will doom it for its lifetime, the problem isn't the lean way it's that your market is too small. YouTube guys had very poor reaction to their initial site.
"because our metrics show no one wants it"
They have little idea on how to use metrics. Don't blame lean startup ideas for that.
ie. What lean startup would do is put up a button that looks as good as your best competitor can put up. Then see how many people click on it. What you measure is action until the click, not the engagement after the click to draw conclusions about the demand for that feature. Now if 1000 people are clicking on the link but only few are using it, chances are your product sucks. Take that insight and work on your product. Just one small example.
failing to fix a hard problem will never increase the value of your company.
If you are saying that you have to solve really hard technical problems to increase value of your company, I full disagree. Just look at the web2 companies that took off.
Craigslist did not take off because it solved a huge technical problem. Craigslist also has a lot of value as a company.