So, you're a contractor, and you're working, you appear to have productivity, and you are driving. Hmmm, that seriously smells on a number of levels.
From the sound of your description, what could happen is that what comes out the other end gets completely trashed because while the pieces looked good when they were presented, the whole sucked eggs and required a redesign with new wireframes that cannot be matched with what you produced.
That's why it doesn't just come out at the end. We show what we've got at the end of every sprint. If it sucks eggs, we can change it. Without Agile, we'd discover this much later. And the earlier you discover this stuff, the cheaper it is to change it.
Additionally, this approach, especially given your description, will result in something like my current project, where there are 4 separate shopping carts, each for a different phase of the purchasing cycle, because no one with half a brain sat down and actually designed what the process would be. Nope, couldn't do that because it would take more than an iteration's time to properly get all requirements, design it, and then develop all required pieces.
You don't have to show something new every sprint. Especially early in a project, when you're still designing the basic architecture and data structures, it's entirely logical that you don't have a good-looking screen ready. Instead of your stories being "make screen X with a shopping cart" and "make screen Y with a shopping cart", your stories might be "make a shopping cart for screen X and Y", "make screen X", and "make screen Y". If the shopping cart is a separate feature, your stories should reflect that. Personally I prefer small issues, and therefore small stories.
I have other examples where projects failed under Agile. In fact, across the many years and projects, I have yet to see a successful project using Agile that was more than 2-3 developers. My successful projects, of which there are quite a few, were all project driven, not really waterfall, and had various processes in them that Agile now claims as their own, but have nothing to do with Agile. They all started with a known goal and requirements, which then generated planning sessions and components, which were then put into the development workflow. The results were always a cohesive design working across multiple nodes, including in some cases distributed services and workflows. This never lends itself to Agile, unless Agile looks an awful lot like waterfall, which the Agile elitists tell you never happens.
From everything I'm hearing, Agile appears to encourage laziness on the part of the client.
From what I'm experiencing, Agile encourages involvement on the part of the client. They don't get to sit by the sideline, they get to be involved every step of the way.
It's not that I don't want to satisfy the client, of course I do, it's just that the client has to do his part in specifying clearly what s/he wants. You know, specs.
And yes, sometimes the developer DOES know what the client wants better than the client does. A seasoned developer with knowledge/experience in the target domain will typically understand lots of things more in-depth and realistically than a client who simply has a pie-in-the-sky vision of things.
The thing with software development is that developers generally lack knowledge in the target domain. That's why the client needs to be involved, because he does have that knowledge. The advantage of Agile is that he gets to provide feedback every step of the way, rather than only at the start and end. I may think I know better than the client what he needs, but blindly assuming that I'm right is a recipe for disaster. I need to get his feedback. Preferably early on.
How can you possibly not care about what the rest of your team is doing to the code that you're working on?!
That's what code reviews are for.
Code reviews are only part of it. If that's truly all your involvement with your co-workers, that's sad.
But sometimes somebody is trying to figure something out on his own because he's sure he can do it and doesn't want to disturb others with it, when actually someone else can solve his problem much faster. Standups are for detecting that issue.
One justification for stand-ups I've heard is to prevent slacking off; now this one to mitigate stubborn and/or prideful people. It sounds like Agile is a way to baby-sit people with work-ethic or personality defects. You can get the same result with a daily e-mail -- that I can glance at much more quickly than having to hear someone speak it and either delete it (because I know nothing about their problem or how to help) or answer it.
You can get the same result with a daily email, but you usually won't. Daily emails usually don't get the same results and involvement.
The pigs and chickens metaphor has been deemed bad and unconstructive in Scrum. It sounds funny at first, but calling some people pigs while suggesting others aren't really as important to the effort sets a wrong atmosphere.
What is the difference to actual development between "we have a launchable product after each sprint" versus "we launch our product after each sprint"? There are obvious differences to the users, but what makes the former superior to the latter when it comes to meeting the overall project goals?
You've got something that you can show to the customer. If he wants changes, you can make those early, instead of after the entire product is finished.
While no process will reliably produce good software with a dysfunctional team, Agile seems to be much more sensitive to dysfunction than many other processes. If you have a team full of disciplined, skillful individuals led with integrity by focused managers, many well-documented software processes will let you deliver good software on schedule. In the real world, teams often fall short of that ideal, so it is important for a development method to be somewhat robust to imperfect use, but Agile seems to encourage frequent distractions and excessive back-and-forth.
Quite the opposite. Agile, or at least Scrum, encourages discipline and focus, and adjusts the process to the needs of the team. It can actually fix a dysfunctional team. Although you do need a competent Scrum Master for that. Without someone to keep an eye on the process, your process will suffer, no matter what process you use.
She's been frustrated by her Agile experiences — and so have her clients. "There is no process.
If there is no process, it's not Agile. It's laziness with a name as its excuse.
Exactly. Agile is big on process. It's just that process doesn't trump people ("People over process", after all). And the process itself is flexible. After every sprint you have a retrospective which can lead to refinements in your process, until you've got a process that fits the needs of the team best. But "no process" doesn't work. That's just chaos.
I understand you're working in that magical place where everybody always delivers everything on time? I can understand Agile doesn't add anything of value there. In the real world, however, it does.
So you're saying if a fellow team member is doing something in a way you think could be done better, you just stay silent?
The best way anyone can do something is in a way that makes sense to them and they can achieve efficiently. Give them a clear spec to adhere to and then let them do the job they were tasked with.
This works fine when you work alone. Most projects are team efforts, however. Work like a team, not like a loner.
As I understand it, in a stand-up, one is supposed to say what one did yesterday (I don't care), what one is going to do today (again, I don't care), and what road-blocks, if any, you have (and, unless your problems affect me doing my work, I still don't care).
Sounds to me like you're just a crappy team player. How can you possibly not care about what the rest of your team is doing to the code that you're working on?!
A good programmer cares about the code, the project and the team, and helps his co-workers out when they need it.
And it never takes 5 minutes. You also have to factor in the time of just getting everybody in the same place at the same time.
It does usually take more than 5 minutes, but not because of the time it takes to get people together, because you usually do this in the same room where the team is working. Only product owners and other people outside the immediate development team work in other parts of the building. No, the reason it takes too long is that people always have more to discuss. And that's a sign that the meeting serves a purpose.
If you discover a road-block at, say, 2pm, what do you do? Just sit there twiddling your thumbs for the rest of the day because the next stand-up at which you can bring this to anybody's attention isn't until tomorrow? You should just either walk over to me or e-mail me now.
And that's exactly what you do in Agile.
But sometimes somebody is trying to figure something out on his own because he's sure he can do it and doesn't want to disturb others with it, when actually someone else can solve his problem much faster. Standups are for detecting that issue.
This is the same BS that all Agile apologists say, "you're doing it wrong, its not agile its you!".
It quite often is. Companies call lots of crap Agile, but that doesn't make it so. Sure, there's a risk of some element of the No True Scotsman fallacy here, but it's naive to assume that everything that people call Agile really is agile.
Some of the comments in this discussion sound like: "I hate peace. We've had way too many civilians dying in majors assaults than before we had peace." That's not a No True Scotsman, that's simply not what peace is. It's someone not understanding what peace is. Someone using the word "peace" to refer to war. The same thing happens a lot with Agile in this discussion.
Much more effective than a daily stand up: manager spending at least 5 minutes with each team member to review, inspect, and evaluate their progress (you know, actually checking people's work)
Why do you need a manager for that? Aren't developers much better at reviewing each other's work?
more meets as a deadline approaches (beginng of project doesn't need daily meetings, near end might need 2-3 meetings per day).
The end only needs that many meetings because you didn't have them at the start. You can save a lot of time by clearing that stuff up at a much earlier stage.
I don't know what you call Agile over there, but trusting developers is one of the core principles of Agile. It should put more power in the hands on developers, not less. If it's used as an excuse for micromanagement, it's definitely not Agile.
Developers hate Agile because it, when combined with incomplete/inadequate specifications, is quicksand for developers.
Management loves it because it allows them to commit to anything. The mindset management has is the developers can throw together an "Agile" solution without management having to do their part of the job.
If you do it right, it's the developers who should love Agile, because it puts them in control. The developers are the ones who decide on the process, they decide what they need from management and business, they decide when requirements are acceptable to them. At least, that's how it works where I work, and from my perspective, management and business do their best to fulfill the support roles that we give them. Not all of them, so we let them know they should do better. And when they do, we tell them they're doing good, and they're happy.
Agile purists tend to frown on this, focusing more on your rolling releases where it doesn't matter what you ship as long as you ship. Could be a couple bug fixes, could be an entirely new database schema that mandates a re-write of connectors that allow for other departments to interface with a vendors app... you never know until you check the release notes.
In Scrum, the team commits to certain sprint goals, and the sprint takes a set amount of time. Not meeting the sprint goals is a big deal. It's not the end of the world, but often missing your sprint goals will be noticed. You can use this to estimate when it will be done.
Scrum also used to work with burn-down charts that gave pretty decent estimates of when it would be done, even taking scope-creep into account. But I've recently been told burn-down charts are out. I admit I don't quite understand why.
...but they can be trusted to say what is most important to them at the time.
No they can't. If you are delivering to customer requests you will always be a follower and never succeed. You need to anticipate what the customers need. As with the I guess made up quote attributed to Henry Ford, "If I listened to my customers I'd have been trying to make faster horses." Whether he said it or not, the statement is true. Customers know what they have and just want it to be faster/better/etc you need to find out what they really need.
That's not the difference between Agile and Waterfall, it's the difference between tailor-made contract work and selling a product. No customer is going to bear the risk for your crazy idea. They want what they know will work.
But if you want to make them something innovative anyway, showing them working results early makes it a lot easier to get their buy-in.
It frequently is. It doesn't matter what methodology you use- if you change major features/priorities at the last minute it will cost multiple times as much.
And that's exactly why Agile is so important. You get to show your results early in the process, so if the customer wants something different, it's cheaper to change it. If you show the finished product after a long process based on wrong assumptions, it's going to be a lot more expensive. Weeding that stuff out early is one of the core tenets of Agile.
I've worked in lots of places that claimed to do Agile, but few really did. Often it meant doing daily standups (or even sit-downs in one case!) and not having any good specs. Right now I'm working at my first contract that really is Agile, and it's fantastic. It is chaotic, but not because of us; it's the reality we're facing. We're doing several projects at once, the designs had to be sent back several times because they were wrong, business isn't really sure what they want, and we're being productive in spite of that.
We tell business what we need from them in order to do our work, instead of the other way around. We don't accept issues that don't meet our standards, and as a result, more and more issues do meet our standard. When we uncover a misunderstanding, we can change direction on a moment's notice, and because business, admin and others show up at our standups and our sprint demo, we discover these misunderstandings pretty quickly.
Not all is perfect. Not everybody around us really gets Agile, and particularly our tester would be much more at home in a Waterfall setting, but for me personally, it's working very, very well.
People don't advertise their mental illnesses in bars either. You usually find out that stuff by meeting them in person and getting to know them. And you're going to do that anyway, no matter how you met them, as that's the entire point, isn't it?
Maybe not for you, me, or your average Slashdot reader. But there certainly are people out there who are socially adept enough to rapdily pick out the problematic types in a crowd.
Only in a crowd? Not when they meet one-on-one? Because only then would this be a problem with online dating.
I have seen one commercial site where non-paying members could respond to messages. They couldn't initiate contact, but contacting them wasn't futile. That's really the only way to do paid membership right.
Physical attraction isn't going anywhere, but it's rarely been the sole basis of a relationship. During many of those thousands of years, economic security was a far more important pillar. Sometimes marriages were arranged. Sometimes it was simply a matter of whoever was available in the village. It's only recently that people have gotten really picky with unrealistic romantic expectations. Online dating makes it easier for picky people to find someone suitable.
It's entirely unclear to me what you're trying to say here. Of course you shouldn't quit after your first try, but that doesn't change the fact that some dating sites are scams. It's vital for the effectiveness of a dating site that non-payers can at least respond to your messages.
I have little faith in commercial dating sites. On the worst ones, people who don't pay can't send messages, but you still see them anyway. So that means the vast majority of profiles you read, are utterly irrelevant. It's okay when people who don't pay can still respond to messages of paid members, though. Still, I frequented a few paid dating sites with little success, and found my wife on one that was either free or cost about $10 a year.
$30/month by itself is no problem, but some dating sites are effectively scams. There are better ones out there.
I don't want to be embarassed when others see me with her, nor do I want her to be embarassed when others see her with me.
If you're dating for other people instead of each other, don't bother. Fuck what other people think. If you've found the right person, your real friends will accept him/her. If it's all about image, you're not ready for a serious relationship.
Slashdot Mirror
So, you're a contractor, and you're working, you appear to have productivity, and you are driving. Hmmm, that seriously smells on a number of levels.
From the sound of your description, what could happen is that what comes out the other end gets completely trashed because while the pieces looked good when they were presented, the whole sucked eggs and required a redesign with new wireframes that cannot be matched with what you produced.
That's why it doesn't just come out at the end. We show what we've got at the end of every sprint. If it sucks eggs, we can change it. Without Agile, we'd discover this much later. And the earlier you discover this stuff, the cheaper it is to change it.
Additionally, this approach, especially given your description, will result in something like my current project, where there are 4 separate shopping carts, each for a different phase of the purchasing cycle, because no one with half a brain sat down and actually designed what the process would be. Nope, couldn't do that because it would take more than an iteration's time to properly get all requirements, design it, and then develop all required pieces.
You don't have to show something new every sprint. Especially early in a project, when you're still designing the basic architecture and data structures, it's entirely logical that you don't have a good-looking screen ready. Instead of your stories being "make screen X with a shopping cart" and "make screen Y with a shopping cart", your stories might be "make a shopping cart for screen X and Y", "make screen X", and "make screen Y". If the shopping cart is a separate feature, your stories should reflect that. Personally I prefer small issues, and therefore small stories.
I have other examples where projects failed under Agile. In fact, across the many years and projects, I have yet to see a successful project using Agile that was more than 2-3 developers. My successful projects, of which there are quite a few, were all project driven, not really waterfall, and had various processes in them that Agile now claims as their own, but have nothing to do with Agile. They all started with a known goal and requirements, which then generated planning sessions and components, which were then put into the development workflow. The results were always a cohesive design working across multiple nodes, including in some cases distributed services and workflows. This never lends itself to Agile, unless Agile looks an awful lot like waterfall, which the Agile elitists tell you never happens.
From everything I'm hearing, Agile appears to encourage laziness on the part of the client.
From what I'm experiencing, Agile encourages involvement on the part of the client. They don't get to sit by the sideline, they get to be involved every step of the way.
It's not that I don't want to satisfy the client, of course I do, it's just that the client has to do his part in specifying clearly what s/he wants. You know, specs.
And yes, sometimes the developer DOES know what the client wants better than the client does. A seasoned developer with knowledge/experience in the target domain will typically understand lots of things more in-depth and realistically than a client who simply has a pie-in-the-sky vision of things.
The thing with software development is that developers generally lack knowledge in the target domain. That's why the client needs to be involved, because he does have that knowledge. The advantage of Agile is that he gets to provide feedback every step of the way, rather than only at the start and end. I may think I know better than the client what he needs, but blindly assuming that I'm right is a recipe for disaster. I need to get his feedback. Preferably early on.
That's what code reviews are for.
Code reviews are only part of it. If that's truly all your involvement with your co-workers, that's sad.
One justification for stand-ups I've heard is to prevent slacking off; now this one to mitigate stubborn and/or prideful people. It sounds like Agile is a way to baby-sit people with work-ethic or personality defects. You can get the same result with a daily e-mail -- that I can glance at much more quickly than having to hear someone speak it and either delete it (because I know nothing about their problem or how to help) or answer it.
You can get the same result with a daily email, but you usually won't. Daily emails usually don't get the same results and involvement.
Agile is designed to operate in chaos, and bring structure to it.
The problem is when you start with chaos. At best Agile is a band-aid.
The problem is that we have chaos. Agile is a way to solve that problem.
The pigs and chickens metaphor has been deemed bad and unconstructive in Scrum. It sounds funny at first, but calling some people pigs while suggesting others aren't really as important to the effort sets a wrong atmosphere.
What is the difference to actual development between "we have a launchable product after each sprint" versus "we launch our product after each sprint"? There are obvious differences to the users, but what makes the former superior to the latter when it comes to meeting the overall project goals?
You've got something that you can show to the customer. If he wants changes, you can make those early, instead of after the entire product is finished.
While no process will reliably produce good software with a dysfunctional team, Agile seems to be much more sensitive to dysfunction than many other processes. If you have a team full of disciplined, skillful individuals led with integrity by focused managers, many well-documented software processes will let you deliver good software on schedule. In the real world, teams often fall short of that ideal, so it is important for a development method to be somewhat robust to imperfect use, but Agile seems to encourage frequent distractions and excessive back-and-forth.
Quite the opposite. Agile, or at least Scrum, encourages discipline and focus, and adjusts the process to the needs of the team. It can actually fix a dysfunctional team. Although you do need a competent Scrum Master for that. Without someone to keep an eye on the process, your process will suffer, no matter what process you use.
She's been frustrated by her Agile experiences — and so have her clients. "There is no process.
If there is no process, it's not Agile. It's laziness with a name as its excuse.
Exactly. Agile is big on process. It's just that process doesn't trump people ("People over process", after all). And the process itself is flexible. After every sprint you have a retrospective which can lead to refinements in your process, until you've got a process that fits the needs of the team best. But "no process" doesn't work. That's just chaos.
Agile is designed to be pure chaos.
More accurately, Agile is designed to operate in chaos, and bring structure to it.
Your problem here is using SVN while your work style requires something like git. SVN is not suitable for feature branches.
I understand you're working in that magical place where everybody always delivers everything on time? I can understand Agile doesn't add anything of value there. In the real world, however, it does.
So you're saying if a fellow team member is doing something in a way you think could be done better, you just stay silent?
The best way anyone can do something is in a way that makes sense to them and they can achieve efficiently. Give them a clear spec to adhere to and then let them do the job they were tasked with.
This works fine when you work alone. Most projects are team efforts, however. Work like a team, not like a loner.
As I understand it, in a stand-up, one is supposed to say what one did yesterday (I don't care), what one is going to do today (again, I don't care), and what road-blocks, if any, you have (and, unless your problems affect me doing my work, I still don't care).
Sounds to me like you're just a crappy team player. How can you possibly not care about what the rest of your team is doing to the code that you're working on?!
A good programmer cares about the code, the project and the team, and helps his co-workers out when they need it.
And it never takes 5 minutes. You also have to factor in the time of just getting everybody in the same place at the same time.
It does usually take more than 5 minutes, but not because of the time it takes to get people together, because you usually do this in the same room where the team is working. Only product owners and other people outside the immediate development team work in other parts of the building. No, the reason it takes too long is that people always have more to discuss. And that's a sign that the meeting serves a purpose.
If you discover a road-block at, say, 2pm, what do you do? Just sit there twiddling your thumbs for the rest of the day because the next stand-up at which you can bring this to anybody's attention isn't until tomorrow? You should just either walk over to me or e-mail me now.
And that's exactly what you do in Agile.
But sometimes somebody is trying to figure something out on his own because he's sure he can do it and doesn't want to disturb others with it, when actually someone else can solve his problem much faster. Standups are for detecting that issue.
This is the same BS that all Agile apologists say, "you're doing it wrong, its not agile its you!".
It quite often is. Companies call lots of crap Agile, but that doesn't make it so. Sure, there's a risk of some element of the No True Scotsman fallacy here, but it's naive to assume that everything that people call Agile really is agile.
Some of the comments in this discussion sound like: "I hate peace. We've had way too many civilians dying in majors assaults than before we had peace." That's not a No True Scotsman, that's simply not what peace is. It's someone not understanding what peace is. Someone using the word "peace" to refer to war. The same thing happens a lot with Agile in this discussion.
Much more effective than a daily stand up: manager spending at least 5 minutes with each team member to review, inspect, and evaluate their progress (you know, actually checking people's work)
Why do you need a manager for that? Aren't developers much better at reviewing each other's work?
more meets as a deadline approaches (beginng of project doesn't need daily meetings, near end might need 2-3 meetings per day).
The end only needs that many meetings because you didn't have them at the start. You can save a lot of time by clearing that stuff up at a much earlier stage.
I don't know what you call Agile over there, but trusting developers is one of the core principles of Agile. It should put more power in the hands on developers, not less. If it's used as an excuse for micromanagement, it's definitely not Agile.
Developers hate Agile because it, when combined with incomplete/inadequate specifications, is quicksand for developers.
Management loves it because it allows them to commit to anything. The mindset management has is the developers can throw together an "Agile" solution without management having to do their part of the job.
If you do it right, it's the developers who should love Agile, because it puts them in control. The developers are the ones who decide on the process, they decide what they need from management and business, they decide when requirements are acceptable to them. At least, that's how it works where I work, and from my perspective, management and business do their best to fulfill the support roles that we give them. Not all of them, so we let them know they should do better. And when they do, we tell them they're doing good, and they're happy.
Agile purists tend to frown on this, focusing more on your rolling releases where it doesn't matter what you ship as long as you ship. Could be a couple bug fixes, could be an entirely new database schema that mandates a re-write of connectors that allow for other departments to interface with a vendors app... you never know until you check the release notes.
In Scrum, the team commits to certain sprint goals, and the sprint takes a set amount of time. Not meeting the sprint goals is a big deal. It's not the end of the world, but often missing your sprint goals will be noticed. You can use this to estimate when it will be done.
Scrum also used to work with burn-down charts that gave pretty decent estimates of when it would be done, even taking scope-creep into account. But I've recently been told burn-down charts are out. I admit I don't quite understand why.
...but they can be trusted to say what is most important to them at the time.
No they can't. If you are delivering to customer requests you will always be a follower and never succeed. You need to anticipate what the customers need. As with the I guess made up quote attributed to Henry Ford, "If I listened to my customers I'd have been trying to make faster horses." Whether he said it or not, the statement is true. Customers know what they have and just want it to be faster/better/etc you need to find out what they really need.
That's not the difference between Agile and Waterfall, it's the difference between tailor-made contract work and selling a product. No customer is going to bear the risk for your crazy idea. They want what they know will work.
But if you want to make them something innovative anyway, showing them working results early makes it a lot easier to get their buy-in.
It frequently is. It doesn't matter what methodology you use- if you change major features/priorities at the last minute it will cost multiple times as much.
And that's exactly why Agile is so important. You get to show your results early in the process, so if the customer wants something different, it's cheaper to change it. If you show the finished product after a long process based on wrong assumptions, it's going to be a lot more expensive. Weeding that stuff out early is one of the core tenets of Agile.
I've worked in lots of places that claimed to do Agile, but few really did. Often it meant doing daily standups (or even sit-downs in one case!) and not having any good specs. Right now I'm working at my first contract that really is Agile, and it's fantastic. It is chaotic, but not because of us; it's the reality we're facing. We're doing several projects at once, the designs had to be sent back several times because they were wrong, business isn't really sure what they want, and we're being productive in spite of that.
We tell business what we need from them in order to do our work, instead of the other way around. We don't accept issues that don't meet our standards, and as a result, more and more issues do meet our standard. When we uncover a misunderstanding, we can change direction on a moment's notice, and because business, admin and others show up at our standups and our sprint demo, we discover these misunderstandings pretty quickly.
Not all is perfect. Not everybody around us really gets Agile, and particularly our tester would be much more at home in a Waterfall setting, but for me personally, it's working very, very well.
Maybe not for you, me, or your average Slashdot reader. But there certainly are people out there who are socially adept enough to rapdily pick out the problematic types in a crowd.
Only in a crowd? Not when they meet one-on-one? Because only then would this be a problem with online dating.
I have seen one commercial site where non-paying members could respond to messages. They couldn't initiate contact, but contacting them wasn't futile. That's really the only way to do paid membership right.
Physical attraction isn't going anywhere, but it's rarely been the sole basis of a relationship. During many of those thousands of years, economic security was a far more important pillar. Sometimes marriages were arranged. Sometimes it was simply a matter of whoever was available in the village. It's only recently that people have gotten really picky with unrealistic romantic expectations. Online dating makes it easier for picky people to find someone suitable.
It's entirely unclear to me what you're trying to say here. Of course you shouldn't quit after your first try, but that doesn't change the fact that some dating sites are scams. It's vital for the effectiveness of a dating site that non-payers can at least respond to your messages.
I have little faith in commercial dating sites. On the worst ones, people who don't pay can't send messages, but you still see them anyway. So that means the vast majority of profiles you read, are utterly irrelevant. It's okay when people who don't pay can still respond to messages of paid members, though. Still, I frequented a few paid dating sites with little success, and found my wife on one that was either free or cost about $10 a year.
$30/month by itself is no problem, but some dating sites are effectively scams. There are better ones out there.
I don't want to be embarassed when others see me with her, nor do I want her to be embarassed when others see her with me.
If you're dating for other people instead of each other, don't bother. Fuck what other people think. If you've found the right person, your real friends will accept him/her. If it's all about image, you're not ready for a serious relationship.