Methodology schmetodology



  • Exhibit A: An Agile aficionado, mildly disappointed that his current snake oil doesn't sell well, tries to sell even more snake oil.

    Exhibit B: the story makes it to Slashdot where hilarity in comments ensues quite rapidly.

    The shit-hurling here seems to center around the following ever so lovable straw men:

    "I was in this Agile shop, and they skimped on testing, so Agile must be at fault! Bleeech, scrum sucks!"

    Or how about this exchange:

    "I was in this Agile shop, and they did 2-hour stand-ups, how can Agile help productivity?" — "You were clearly doing it wrong, stand-ups are not status reports to managed and they are time-boxed to 15 minutes overall" — "Oh, you are invoking no true scotsman, you!!!111"

    Agile processes, I observed, failed when they were not, in fact, agile (look it up in the Oxford dictionary). Management wants to create an impression of adopting new methods, while not letting go of all their favorite toys like micro-management and long-winded status reports (so they can score better in their bosses' or customers' eyes). Or developers believe the new process will magically relieve them from the burden of responsibility, accountability, or thinking as such.

    Which all makes me think that there must be something really irresistible about cargo cults.

    Or that people who claim decades of programming experience are off by an order of magnitude evaluating their own intelligence. Because common sense is a thing, motherfucker. For example, take a look at this comment:

    As a Program Manager, while Waterfall techniques could frequently end up with late or over budget, or both, projects, at the end of every project (I oversaw 5 multimillion dollar projects using Waterfall methods) we at least had a working application that met the original specifications.

    What good is being so proud of a working application meeting the original specifications if the said specifications are no longer relevant? Is this some kind of a masturbatory relief after six months of stroking one's mind to the point it's completely numb? I thought we already absorbed the idea that software projects are there only to satisfy a specification. They are there to make the motherfucking revenue, or to enable people to make the motherfucking revenue.

    The guy at the Exhibit A tries to make a point that Agile fails because developers are too stupid to reason about why a particular rule works, thus we need a new shiny methodology (called GROWS, without a clear explanation what it even is) to accommodate stupid developers. Why not educate or get rid of them instead?

    TL;DR version: programmers are by no means a kind of an intellectual elite. The humanity is a total failure. Makes me sad.


  • BINNED

    http://blog.toolshed.com
    

    But what colour is it???


  • ♿ (Parody)

    @wft said:

    What good is being so proud of a working application meeting the original specifications if the said specifications are no longer relevant?

    Yeah...how many things did the users recoil in terror over when they saw what they'd really asked for? That stuff is hard, and I don't see a way around iteration. I came across this post this morning, which seems apropos:

    http://what.thedailywtf.com/t/vote-of-no-confidence/270/395?u=boomzilla



  • @wft said:

    if the said specifications are no longer relevant?

    Where did that come from?

    @wft said:

    The guy at the Exhibit A tries to make a point that Agile fails because developers are too stupid to reason about why a particular rule works, thus we need a new shiny methodology (called GROWS, without a clear explanation what it even is) to accommodate stupid developers.

    Go back to your quotes from Slashdot above. Do you think that:

    1. Developers chose to have no QA department?

    2. Developers chose to have 2-hour-long standup meetings?

    How do you propose educating developers would help either of those scenarios?

    @wft said:

    TL;DR version: programmers are by no means a kind of an intellectual elite.

    Duh?

    Look at the shitty software produced by them. Especially in the open source world, where there's practically no management at all. If they are some "kind" of intellectual elite, they're the "kind" who doesn't give a flying shit whether they produce good software or not.


    I personally agree that Agile really sucks at greenfield development. It only works if you're modifying an existing, working, product-- and even then it only works if your modifications are small enough to be completed in a 2-week period of time.

    The only way Agile works for greenfield is if you extend the length of a sprint to ludicrous amounts, or completely trash the demo requirement. And then programmers on your team bitch about it being no longer Agile.


  • ♿ (Parody)

    @blakeyrat said:

    @wft said:
    if the said specifications are no longer relevant?

    Where did that come from?

    It's a natural consequence of the waterfall methodology. You collect the requirements and build the spec in the beginning and then go away for a while and come back with a finished product. That's not to say that everything is no longer relevant.


  • kills Dumbledore

    @blakeyrat said:

    The only way Agile works for greenfield is if you extend the length of a sprint to ludicrous amounts, or completely trash the demo requirement

    Depends on the project. I've done greenfield projects before that, after a couple of weeks setting up the basics, lent themselves very well to weekly or biweekly "here's what the application does that it couldn't do last time" demos



  • @boomzilla said:

    That's not to say that everything is no longer relevant.

    It's also not to say that anything is no longer relevant. That idea was just kind of introduced out of nowhere with zero explanation, which is exactly why I'm confused.


  • ♿ (Parody)

    @blakeyrat said:

    That idea was just kind of introduced out of nowhere with zero explanation, which is exactly why I'm confused.

    It was assumed you'd be familiar with waterfall, I'm sure.



  • @Jaloopa said:

    Depends on the project.

    Possibly? But I've never worked on a project that took less than 2 weeks of foundational work before you could demo anything at all.

    @Jaloopa said:

    after a couple of weeks setting up the basics,

    If you go a single sprint without anything demonstrable, you're "breaking the rules" of Agile. That's my exact complaint.

    Currently, I'm working on back-end C# code to figure out health insurance spending account rules and rates, there's no development team on Earth that could start from scratch and have a demonstrable product for that after 2 weeks. 2 months? ... maybe.

    (Of course I couldn't demo it even if my part were done, since the front-end guys generally run at least a month behind the back-end development, and there's nothing to demo until you have a UI.)

    Our solution is just to trash the entire "demo day" concept completely. Which means we're no longer doing "Agile", we're just "inconveniently splitting a several-month-long task into tons of individually-useless 2-week long tasks". A.k.a.: adding tons of management overhead for no discernible benefit.



  • @boomzilla said:

    It was assumed you'd be familiar with waterfall, I'm sure.

    I am.

    What I want to know is why it's impossible to do a waterfall project where the specifications didn't change during the course of it. What exactly makes that impossible?

    It's a fucking obvious question based on the thing I'm quoting. But it was assumed Boomzilla was familiar with 2nd grade reading comprehension, I'm sure.


  • I survived the hour long Uno hand

    I've noticed a lot of theory, tooling, and methodologies assume standalone compiled applications, which is about the easiest use case. Web applications, integrations between COTS, API-only applications, SSIS packages or batch jobs, all kind of have to shoehorn themselves into tools meant for traditional applications.


  • kills Dumbledore

    Yeah, I was thinking of relatively small desktop apps where it's the same person doing the UI and the business logic. In that case, it's not hard to make a load of non functional buttons and wire them in as you get to the logic, or add screens as you go.

    If you're doing backend stuff it is more tricky to demo without writing your own shitty UI to plug in to the logic, and then people complain about the shitty UI instead of the shitty logic


  • ♿ (Parody)

    @blakeyrat said:

    What exactly makes that impossible?

    Reality, IME. I'm sure there have been stable projects where people could express requirements and specifications and then let the team go off and do it, but that's very rare.

    @blakeyrat said:

    It's a fucking obvious question based on the thing I'm quoting.

    To anyone with familiarity with the history of software development, the answer to your question was obvious. You've displayed some savvy in this area before, so I'm still confused why you'd ask such a braindead question.



  • @boomzilla said:

    Reality, IME. I'm sure there have been stable projects where people could express requirements and specifications and then let the team go off and do it, but that's very rare.

    So it's true or not true? The assertion that it's true comes from... what data? Guesswork?

    Look, of all the millions of waterfall projects that have been done, how many have had the specifications change during development? 10%? 50%? 90%? 100%? How do you know? How does wft?

    @boomzilla said:

    To anyone with familiarity with the history of software development, the answer to your question was obvious.

    The assertion seems to be based on absolutely nothing. It's this truism that came from absolutely nowhere, and that's what threw me.

    I'd be like if I typed a post that just casually replied on the assumption that all cats are orange without once explaining why I think all cats are orange.

    @boomzilla said:

    You've displayed some savvy in this area before, so I'm still confused why you'd ask such a braindead question.

    I think "backing-up assertions with data" is the opposite of braindead. You know me well enough that none of this should have come as a surprise.

    And you even admit here that the assertion comes out of nowhere because it's "obvious". Well you also know I don't do "obvious", and you know I'm likely to say "a lot of 'obvious' things are utterly wrong", and I don't know why you posted that unless you're suddenly suffering from amnesia.

    It's "obvious" that the stomach ulcers my aunt suffered from all her life are caused by stress or some other emotional state. It's so obvious that no medical researchers even bothered to attempt coming up with a cure for decades. Then, shortly after she died, Barry Marshall and Robin Warren said "fuck 'obvious!'", actually studied the problem, and determined it was a simple bacterial infection all along.

    Fuck "obvious".


  • ♿ (Parody)

    @blakeyrat said:

    Look, of all the millions of waterfall projects that have been done, how many have had the specifications change during development? 10%? 50%? 90%? 100%? How do you know? How does wft?

    Yeah, I have no clue what the numbers are, but I'd be surprised if it was very far from 100%. It is the whole reason we went from it to things like spiral design and now to agile. Because people don't know and can't predict this stuff without doing it and trying it and seeing what works.

    @blakeyrat said:

    The assertion seems to be based on absolutely nothing. It's this truism that came from absolutely nowhere, and that's what threw me.

    I know, you're coming to this topic like a newborn babe and only peer reviewed meta studies will satisfy your appetite for citation. I don't have it and I'm not going to search for it.

    @blakeyrat said:

    I'd be like if I typed a post that just casually replied on the assumption that all cats are orange without once explaining why I think all cats are orange.

    I don't want to shock you, but the sky is blue (it's the stuff above the rain clouds).

    @blakeyrat said:

    It's "obvious" that the stomach ulcers my aunt suffered from all her life are caused by stress or some other emotional state. It's so obvious that no medical researchers even bothered to attempt coming up with a cure for decades. Then, shortly after she died, Barry Marshall and Robin Warren said "fuck 'obvious!'", actually studied the problem, and determined it was a simple bacterial infection all along.

    And I'm sure that you guys even get all of your specifications correct for just a short sprint and never need to revisit anything. Now scale that up to the whole damn thing. There is nothing subtle about people thinking they need one thing and only realizing later that it's not what they need. There is no mysterious waving of hands about a cause, like the stuff you brought up there.

    @blakeyrat said:

    Fuck "obvious".

    2 +2 != 5

    No, I'm not going to prove it or cite it for you.



    1. I have not seen a Waterfall process in decades. As soon as there is any type of "change order" it is not waterfall.

    2. I have seen hundreds (200-400) of projects that claim to be "Agile", yet have no correlation to the 12/4 of the Manifesto

    3. I regularly work on complex project like blakeyrat posted (even some in the insurance industry). I have never had a problem with a functional demonstration each sprint (I do advocate 3 week sprints, but that is not so much of a change).

    4. Having "front end guys" and "back end guys" is usually an indication of an organization that will have problems in being agile. Having thin vertical slices where UI<->DB can be worked on by one team for a small segment of the application domain is usually much better.

    5. For Greenfield, Agile also works great. I just finished bidding on a project for a piece of avionics test instrumentation. Before project kickoff the product backlog already has over 200 user stories (which have not yet been ranked).



  • @boomzilla said:

    Yeah, I have no clue what the numbers are,

    Thus proving Blakeyrat's concern justified once more.

    @boomzilla said:

    but I'd be surprised if it was very far from 100%. It is the whole reason we went from it to things like spiral design and now to agile.

    It could easily be trendwhoring. I mean, what's the "reason" we moved to Node.JS instead of C#.NET? Or what's the "reason" we moved to Git?

    This industry frequently moves to inferior products/processes. I don't know why you'd assume the move to Agile was holy and sacred.

    @boomzilla said:

    And I'm sure that you guys even get all of your specifications correct for just a short sprint and never need to revisit anything.

    Like I said, we're working basically in "mega-sprints", so it's kind of moot.

    @boomzilla said:

    Now scale that up to the whole damn thing.

    Is that valid? The stuff shifting during our sprints is what part of the requirements to do first, not what part of the requirements are valid at all. In fact, since the requirements are based on Federal Law, they've been remarkably stable on this particular project.

    @TheCPUWizard said:

    I have never had a problem with a functional demonstration each sprint

    Right; but you're a magical super-being from heaven. We're talking about mere mortals here.

    @TheCPUWizard said:

    Having "front end guys" and "back end guys" is usually an indication of an organization that will have problems in being agile.

    The front-end is using radically different technologies. (Single-page apps, or whatever the latest buzzword is compared to WebAPI 2.0.) I'm sure a holy angelic perfect being like yourself has no trouble hiring employees who know both, but us mere mortals have to compromise.

    And no, I had no part in picking either technology so don't come in here and bitch at me for "my" stupid decisions.

    @TheCPUWizard said:

    For Greenfield, Agile also works great. I just finished bidding on a project for a piece of avionics test instrumentation. Before project kickoff the product backlog already has over 200 user stories (which have not yet been ranked).

    And that demonstrates... what?

    "Man this pie recipe is really great! We've already gathered 400 ingredients!"


    The funny thing is I'm not even saying Agile doesn't work. For all I know, it's the best method. My entire career I've been at companies that either have team sizes too small to bother with any development methodology at all, or that blindly use Agile (or some variant of it). I just don't know, and haven't experienced any alternatives.


  • ♿ (Parody)

    @blakeyrat said:

    Thus proving Blakeyrat's concern justified once more.

    https://youtu.be/BHqgHFcmAOc

    @blakeyrat said:

    It could easily be trendwhoring.

    Yes, a 20-30 year trend.

    @blakeyrat said:

    I don't know why you'd assume the move to Agile was holy and sacred.

    I'm not saying it is. But the move out of waterfall certainly was.

    @blakeyrat said:

    In fact, since the requirements are based on Federal Law, they've been remarkably stable on this particular project.

    This is a particular sort of stability where some projects have an advantage. But in a waterfall project, you'd have planned out what each screen / page looks like before you started writing. Not just the requirement that you need to frobnicate the listicle.

    @blakeyrat said:

    The funny thing is I'm not even saying Agile doesn't work.

    I never interpreted anything you said to be saying that it doesn't work.

    @TheCPUWizard said:

    I have not seen a Waterfall process in decades.

    The project I'm currently on was originally envisioned that way. Well, with a little bit of spiral thrown in. It was retarded, and eventually we escaped that cesspit of a methodology.



  • @boomzilla said:

    Yes, a 20-30 year trend.

    The move away from spatial interfaces has been a 20-30 year trend, and produced shitty results. However, it's so established now that you can't even assume the average programmer knows what the term "spatial interface" means anymore.

    @boomzilla said:

    But the move out of waterfall certainly was.

    Based on...?

    @boomzilla said:

    I never interpreted anything you said to be saying that it doesn't work.

    Yeah well sometimes I try to pre-empt the people without your super-impressive 2nd grade reading comprehension skillz.


  • kills Dumbledore

    @blakeyrat said:

    you can't even assume the average programmer knows what the term "spatial interface" means anymore

    👋



  • @Onyx said:

    But what colour is it???


  • ♿ (Parody)

    @blakeyrat said:

    Yeah well sometimes I try to pre-empt the people without your super-impressive 2nd grade reading comprehension skillz.

    Apologies. I'll drop down to kindergarten mode.

    @blakeyrat said:

    Based on...?

    Everyone who's ever touched it. You clearly aren't familiar with it. You could start with wikipedia or any of the zillion hits that google will give.



  • @boomzilla said:

    Everyone who's ever touched it.

    You speak for everybody who's ever touched Waterfall development methodology!? You're a powerful man.

    Are you going to use that vast army of bearded Unix users to invade Cuba?


  • ♿ (Parody)

    @blakeyrat said:

    You speak for everybody who's ever touched Waterfall development methodology!

    Absolutely!

    @blakeyrat said:

    Are you going to use that vast army of bearded Unix users to invade Cuba?

    Doubtful, but ever optimistic!



  • Blakey,

    Nothing "super human" about it... No need to hire any different people, simply a matter of organization of the existing people into a different team structure.

    Since you are honest about never having really experienced it, I would recommend finding a way to work with a really good agile team.

    There are so many indications (not in your posts specifically, but in the overall discussion ad even ecosystem) that companies claiming Agile really do not have a clue, as an example...

    @blakeyrat said:

    Developers chose to have 2-hour-long standup meetings?

    Well, yes, that is their choice, since ONLY developers should be in these meetings. If the developers choose to allow the product owner to attend, then that person is an observer only, and should remain SILENT,

    @blakeyrat said:

    Developers chose to have no QA department

    Again, it is a matter of organization. There is definitely a need for many "quality" related issues, but personal responsibility is the most effective means of achieving actual quality. Having a distinct department is really counter productive.



  • @TheCPUWizard said:

    Well, yes, that is their choice, since ONLY developers should be in these meetings.

    Do you know what the word "should" means?

    @TheCPUWizard said:

    There is definitely a need for many "quality" related issues, but personal responsibility is the most effective means of achieving actual quality.

    HahahahahahAHAHAHHAAHHAHAHAHAHAHAHAHAHAHAHAHAHAH



  • @blakeyrat said:

    Do you know what the word "should" means?

    Of course, it is the 'simple past tense" of shall... and Shall has the definition (among others) of "will have to, is determined to, or definitely will: will have to, is determined to, or definitely will:

    So it is a matter of the developers simply (simple and easy are different, and there may be side-effects) say "You want Agile, this is how agile is done, now GTF out". 😉


  • I survived the hour long Uno hand

    @TheCPUWizard said:

    Having a distinct department is really counter productive.

    Capers Jones found that projects that had only developers as testers tended to succeed less than 25% of the time, while projects that had a distinct testing department succeeded 90+% of the time. The separate QA department that doesn't have a personal bias toward the code like a developer would and doesn't answer to development leads is key to getting good results. The most successful companies have > 3% of their IT staff as dedicated SQA professionals. http://sqgne.org/presentations/2012-13/Jones-Sep-2012.pdf



  • @TheCPUWizard said:

    Again, it is a matter of organization. There is definitely a need for many "quality" related issues, but personal responsibility is the most effective means of achieving actual quality. Having a distinct department is really counter productive.

    Yeah, QA is not a silo! At least, not if you want it to be effective...

    You need testers, though, as Capers Jones' study points out. I personally would rather have them detached and paired with functional-unit teams, though...there's no sense in trying to lock QA away from devs.


  • I survived the hour long Uno hand

    Agreed, communication is important, but at the same time, so is autonomy. Detached but paired is a nice compromise.


  • kills Dumbledore

    At my last company, after the QA manager was fired for being a cunt the QA department was restructured so each programming team had a couple of testers attached to it, with a handful of floating testers for the teams who weren't big enough for a dedicated resource or extra help in the main teams if they were busy.

    I left not long after that (and was on one of the teams deemed too small for our own tester), but it seemed like a pretty decent setup from what I saw



  • @blakeyrat said:

    If you go a single sprint without anything demonstrable, you're "breaking the rules" of Agile.

    For a given definition of "demonstrable" that's applicable to your project. For some it can be tests passing, or even an ad-hoc tool using your framework (CLI or otherwise). "Demonstrable" does not always mean clicky-touchy GUI in the real application.

    Also, if you cannot come up with anything demonstrable in any way in a month's time, an alarm bell should go off that you're drowning in architecture.



  • @TheCPUWizard said:

    1) I have not seen a Waterfall process in decades. As soon as there is any type of "change order" it is not waterfall.

    It can be "waterfall". Waterfall just means that changes are expensive, sometimes prohibitively, in terms of both implementation and red tape (and can come out just as useless) so users are taught to work around bugs. You can see this in major state/government institutions where you are basically fucked once you enter that field (they actually demand waterfall in most cases from you, I've seen that).

    Also, Agile stands against Big Design Up-Front, but does not prohibit design up-front at all. When you have enough experience, you learn to know the differences between what you can tell right away, what you can tell with some thinking, what others can tell you, what no one can tell. You don't apply rules of thumb blindly.


  • I survived the hour long Uno hand

    @wft said:

    a month's time

    I've been told several times a month is too long for a sprint.



  • How long a sprint is is not an universal metric. Whoever tries to impose that on you is a bloody fool.

    At my soon-to-be-former company we have sprints that are three week long and are very happy with that. Your mileage may vary greatly.

    Also, in my freelancing team of one, I employed two-day sprints: implement today, look back on it tomorrow, regroup and pick the next work item. Split if it's too large. It worked just right for some things, otherwise I would just get stuck in shuffling code with no real progress.



  • This post is deleted!


  • @wft said:

    For a given definition of "demonstrable" that's applicable to your project. For some it can be tests passing, or even an ad-hoc tool using your framework (CLI or otherwise). "Demonstrable" does not always mean clicky-touchy GUI in the real application.

    Right; but this project has a UI, so that doesn't help me at all.

    @wft said:

    Also, if you cannot come up with anything demonstrable in any way in a month's time, an alarm bell should go off that you're drowning in architecture.

    Or it could just mean that the Federal laws referring to health insurance saving account products are really fucking complicated.


  • kills Dumbledore

    @blakeyrat said:

    Right; but this project has a UI, so that doesn't help me at all.

    For the backend stuff I'm working on at the moment, I have my own basic CLI interface for testing it. It's completely separate from the actual GUI but it means I can test the functionality before the UI is written to call its properly



  • Well ok?

    But showing that off wouldn't be demonstrating the actual product, is my point. It'd be demonstrating some utility almost entirely divorced from the actual product being shipped to customers.

    If that's all it takes to be a "demo", then what's the point of the demo requirement in the first place?


  • kills Dumbledore

    I don't even know why I'm arguing on this one TBH. My current workplace is AINO and I've never done a demo here. I'm just saying if you're demoing your own functionality you don't necessarily need it to be in the same UI as the customers will use



  • @Jaloopa said:

    I'm just saying if you're demoing your own functionality you don't necessarily need it to be in the same UI as the customers will use

    I know what you're saying. Look above for my reply to that.

    Are you repeating yourself for some reason?



  • @wft said:

    Waterfall just means that changes are expensive...

    Not when the term was introduced. The concept of an "Engineering Change Order" was prohibited by the true waterfall contracts of the 1960's and early 1970's. Each stage was to be signed off, and once signed could not be altered. The only option was a cancelation of the project. The next stage could not be started (or in many cases even talked about) until signoff of the previous was complete.

    Another classic case (a good friend of my father was involved in this one) was where there were typographical (Spelling, mainly) errors in the definitions of what the reports should contain (at the time, everything was hard copy). The code was faithfully developed to contain reports with misspelled headings and other errors that were in the spec. The software was delivered to the customer and accepted. Then a brand spanking new contract was sent out (RFQ) to create a new software package that eliminated these "limitations".


  • Java Dev

    We use 2-week sprints, but carry over items more often than not. We do have a more stringent guideline that a backlog item that's in current sprint for more than 4 weeks needs a closer look in the weekly backlog item review (combined product owner demo + sprint status + upcoming items review)



  • @blakeyrat said:

    Right; but this project has a UI, so that doesn't help me at all.

    Your part has other implications. How do you know it works? Oh, it's got unit tests or the like! Great. That can be a demo, too. It's all about your progress being measurable.



  • @PleegWat said:

    but carry over items more often than not.

    I guess either your estimates don't improve over time, which raises question of what quality your retrospectives are, or you need to chunk more finely, or you need to lengthen your sprints. Sometimes you can't decompose further and the stories are still too big for two weeks. It's not like one size fits all.


  • Java Dev

    It's more picking up an extra item 3 days before end of sprint because it's that or twiddling your thumbs for 3 days.

    It's grown to where a single transfer on an item isn't seen as a problem - a second or third is, and not delivering anything in a sprint is as well.



  • @wft said:

    Your part has other implications. How do you know it works?

    That's the point, isn't it? I don't know it works until it's shipped to the client and put in front of actual users.

    The idea of unit tests telling you a project works is absurd.



  • @PleegWat said:

    It's more picking up an extra item 3 days before end of sprint because it's that or twiddling your thumbs for 3 days.

    This is not a problem, then. At all. A sprint has a goal you must deliver and one or more candidates which are nice to have. It's when you carry over your sprint goals that a flag must be raised.



  • @blakeyrat said:

    The idea of unit tests telling you a project works is absurd.

    Wait what, you always develop projects as a whole? You never break them down? No modular structure whatsoever? How do you tell a fucking module or a goddamn library works? You rush to other parts before you can even verify your APIs work?

    Either there is a way you can tell, or the hell freezes before I'd even consider to pay you by the hour.


  • Java Dev

    @blakeyrat said:

    That's the point, isn't it? I don't know it works until it's shipped to the client and put in front of actual users.

    The idea of unit tests telling you a project works is absurd.

    No, you don't know it worked until it's been obsoleted, every installation purged, and will never be installed again.

    Testing (Including UAT and production use) cannot prove the presence of bugs, only their absence.


Log in to reply