The new version of both sites is slow, sluggish and provides me with no benefit.
It's about par for the course when a new dev group and/or manager comes in and wants to make their mark. I generally find this sort of thing facepalm-inspiring-not-so-smart. For one thing, there are so many examples out there of how this can go wrong. (see sorenjan's cousin comment) For a mature long-running production system, the right thing to do is to bias for continuity and incremental change. This isn't to say that redesign and progress are forbidden. There are usually benefits to be had. I've been a part of teams that have implemented radical changes to underlying frameworks. (Re-hosting from an object database to Oracle, for example.) My experience is that there is almost always a way to do this incrementally, but that ego and limited imaginations get in the way of doing the right thing.
When you're out to re-architect or re-host a long standing production system, there are two things you should absolutely do, absolutely:
1) Avoid disrupting the current users
2) Preserve the hard won domain, operational, and optimization knowledge of the previous development team
The goodwill of the users and the good reputation of your company/app were won with great effort and expense. They are extremely valuable. Degrade those at your peril! Likewise, the hard won domain, operational, and optimization knowledge of the previous development team were won with great effort and expense and are extremely valuable. Degrade/disregard those at your peril!
I think I would like to ask new managers who are going to "make their mark" by re-implementing something if they can absolutely guarantee 1) and if they can quantify 2) and back themselves up empirically. Then, when the project is done, ask how good they were at answering those questions.
Just the 2 cents of a hoary old veteran.
(A couple of hints, for those wondering how: Automated test suites and syntactic code rewriting are your friend!)
Sometimes you need to evolve to survive. We got stuck with the old codebase and adding features was a nightmare - features a lot of users were demanding! With the new design and codebase we can start adding more features.. optional features! we wont force you to use them. And FYI unlike other companies we don't even force you to use the redesign! We've left the old one up at old.reddit.com
Are you suggesting that I think evolution is wrong? Would that really be a fair reading of my comment?
We got stuck with the old codebase and adding features was a nightmare - features a lot of users were demanding!
A positive suggestion for a future project: Implement a new UI with a newer fancy framework -- but have it emulate the old UI. (It should be flexible enough to implement the old UI and the new.) This lets you be maximally flexible in introducing new features incrementally, and lets you easily make comparisons with the old system, especially with regards to performance. In some cases, this can also let you re-use QA assets. Also, this can facilitate allowing users to transition themselves to the new site/new features incrementally, which makes the transaction of switching to the new UI more consensual for the users. (More pull, less push, from their perspective.)
And FYI unlike other companies we don't even force you to use the redesign! We've left the old one up at old.reddit.com
I noticed. Good on you. As a user, the transaction still seemed a bit foisty to me, but it was better than usual. But as a hoary old dev: you can still do better than the naive complete rewrite.
Sorry for the late reply - was out. And for putting words in your mouth. I understand now your more about incremental steps rather than drastic changes.
Thanks for the feedback. As I'm not on the web or redesign team I don't know how feasible that would have been.. I know there was a ton of stuff being done in strange ways with the legacy system.. but I can promise that with the new framework we will be able to make the usual A/B adjustments a lot easier and hopefully evolve more incrementally now into something better than both the current old and new designs.
I gotta say your comments are not inspiring much confidence.
Generally speaking, I love 'new' stuff, and even welcome non-backwards-compatible breaks with the old to get rid of cruft/legacy issues. But with the Reddit redesign I definitely feel that it goes way beyond that and instead does a whole lot of things that seem more 'state of the art front-end bandwagon-ey' than is prudent.
Basically, I get the impression that while the redesign might include a whole bunch of stuff that redditors have been asking for, it's primarily not made with that target audience in mind. Who the actual target audience is I'm not sure, but I imagine their interests don't align with most users. I'd be happy to be proven wrong though.
(and honestly, I wouldn't be surprised if the actual target audience is 'front-end reddit devs who like to use the coolest newest stuff')
it's primarily not made with that target audience in mind. Who the actual target audience is I'm not sure, but I imagine their interests don't align with most users.
That's the fundamental problem in such a situation with completely asymmetrical power. The 'bosses' think they are being super conscientious -- and often they are genuinely trying -- but their point of view lets them get away with thinking, "Oh well, they won't mind. Oh well, it's worth it, they can take it."
I wouldn't be surprised if the actual target audience is 'front-end reddit devs who like to use the coolest newest stuff'
That's something to think about. You want to be able to hire the best devs. This is why policies like "Absolute Continuity" are useful for keeping the devs self-honest. Otherwise, because there is no direct accountability, the dev's priorities are going to creep into superseding the user's.
> The 'bosses' think they are being super conscientious -- and often they are genuinely trying -- but their point of view lets them get away with thinking, "Oh well, they won't mind. Oh well, it's worth it, they can take it."
It's possible, but I doubt it. It seems more likely to me that the 'bosses' don't really care all that much beyond whatever they consider the 'bottom line'.
It's about par for the course when a new dev group and/or manager comes in and wants to make their mark. I generally find this sort of thing facepalm-inspiring-not-so-smart. For one thing, there are so many examples out there of how this can go wrong. (see sorenjan's cousin comment) For a mature long-running production system, the right thing to do is to bias for continuity and incremental change. This isn't to say that redesign and progress are forbidden. There are usually benefits to be had. I've been a part of teams that have implemented radical changes to underlying frameworks. (Re-hosting from an object database to Oracle, for example.) My experience is that there is almost always a way to do this incrementally, but that ego and limited imaginations get in the way of doing the right thing.
When you're out to re-architect or re-host a long standing production system, there are two things you should absolutely do, absolutely:
1) Avoid disrupting the current users
2) Preserve the hard won domain, operational, and optimization knowledge of the previous development team
The goodwill of the users and the good reputation of your company/app were won with great effort and expense. They are extremely valuable. Degrade those at your peril! Likewise, the hard won domain, operational, and optimization knowledge of the previous development team were won with great effort and expense and are extremely valuable. Degrade/disregard those at your peril!
I think I would like to ask new managers who are going to "make their mark" by re-implementing something if they can absolutely guarantee 1) and if they can quantify 2) and back themselves up empirically. Then, when the project is done, ask how good they were at answering those questions.
Just the 2 cents of a hoary old veteran.
(A couple of hints, for those wondering how: Automated test suites and syntactic code rewriting are your friend!)