Slashdot Mirror
Why Your Users Hate Agile
Esther Schindler writes "What developers see as iterative and flexible, users see as disorganized and never-ending. This article discusses how some experienced developers have changed that perception. '... She's been frustrated by her Agile experiences — and so have her clients. "There is no process. Things fly all directions, and despite SVN [version control] developers overwrite each other and then have to have meetings to discuss why things were changed. Too many people are involved, and, again, I repeat, there is no process.' The premise here is not that Agile sucks — quite to the contrary — but that developers have to understand how Agile processes can make users anxious, and learn to respond to those fears. Not all those answers are foolproof. For example: 'Detailed designs and planning done prior to a project seems to provide a "safety net" to business sponsors, says Semeniuk. "By providing a Big Design Up Front you are pacifying this request by giving them a best guess based on what you know at that time — which is at best partial or incorrect in the first place." The danger, he cautions, is when Big Design becomes Big Commitment — as sometimes business sponsors see this plan as something that needs to be tracked against. "The big concern with doing a Big Design up front is when it sets a rigid expectation that must be met, regardless of the changes and knowledge discovered along the way," says Semeniuk.' How do you respond to user anxiety from Agile processes?"
http://programming-motherfucker.com/, do you speak it?
Agile taken to an extreme can be a PITA. If a customer orders a car, they want what comes out of the factory to have four wheels and a steering wheel. Agile development means that who knows what the end product will be... will it be a bicycle, will it be a lorry, will it be a motorcycle, or perhaps it might be a unicycle. The only person who knows is the one with the loudest voice.
This isn't to say that waterfall is the best dev model, but there should be a balance, so one at least has a vision of what the end product will look like.
He says it quite nicely:
http://martinfowler.com/bliki/FlaccidScrum.html
Of course that was in 2009. Nothing has changed, and I've long past the point of being fed up with the non-technical fuck-tards that think they can sprinkle Scrum-dust on a mountain of technical debt and it'll go away. This is usually done in the presence of a stable of bad developers who lack the discipline to do the actual hard work of the XP practices that deliver good products in the first place.
The parent article author can STFU already. It just reeks of, "Wah! My agile hurts me because I won't do the hard stuff".
Oh, and while your at it agile wimps: stop fucking trying to do "distributed agile" with fucking China and fucking India in order to save 30% on what's already a crap-pile due to communication problems. It's not going to help one bit.
Also, get off my lawn...
*** Sigs are a stupid waste of bandwidth.
The customer thinks they are ordering a building, metaphorically speaking. They can walk around it in their heads, see the color of the drapes, measure the windows, there are quantifiable costs. You don't build things using agile techniques however. "Well, we'll put this skyscraper about here. Start digging and we'll see how she goes."
"The big concern with doing a Big Design up front is when it sets a rigid expectation that must be met, regardless of the changes and knowledge discovered along the way," says Semeniuk.' How do you respond to user anxiety from Agile processes?"
How? Don't even talk about agile to the customer. Can you imagine a surgeon... "Well we'll just start cutting and figure it from there" no no, talk about outcome, not process. Agile talk is for the operating room, not the waiting room.
Almost everyone's doing it wrong, that's why it doesn't seem to work in practice. 99% of the "agile" efforts I've seen used agile as an excuse to avoid whatever part of the SDLC annoyed them most.
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). 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.
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. If you do that, then maybe we can solve the problem by, say, 3pm. Why wait until the next stand-up? If everybody did this with problems, your claimed reason for needing stand-ups evaporates.
Stand-ups are both annoying and pointless. Agile is nothing more than modern-day snake-oil.
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
Because, as every good manager knows, all problems can be fixed by making them more agile!
Is your well oiled development team on schedule, and the producers are twiddling their thumbs with little to do? You need to be more agile!
Have recent changes to the way your dev team works caused an on track project to go off the rails? You need to be more agile!
Have your senior developers got so fed up with the piss poor management team behind your project, that they've all just quit? You need to be more agile!
Has your company just gone bankrupt due to a lack of developers, and a lack a product? Have you considered becoming an agile consultant?
As TFA points out, that always works fine when your requirements are *all* known an are completely static. That rarely happens in most fields. Even in the ones where it does it's usually just management having the balls to say "No, you can give us the next bunch of additions and changes when this is delivered, we agreed on that". It frequently ends up delivering something less than useful.
But, it's like every other tool; it was made for a certain job. You try working in screws with the claw end of a hammer, and you can expect your results to suck. If you don't have a staff of above-average, disciplined developers and small or well-understood project goal odds are you're applying the wrong path. Agile isn't for project managers who just want to save money and speed up development.
I swear to God...I swear to God! That is NOT how you treat your human!
This is totally true. And I think the main part of the SDLC they try to avoid is planning. I've both been a developer and had developers writing automation code as projects for me as an infrastructure engineer, and the most frequent abuse is zero planning. And that's the thing that makes agile seem endless to users like me. The developers keep having to rewrite everything every dang sprint because they didn't put enough planning into the architecture to make it flexible enough to meet the requirements. And speaking of requirements gathering, that consisted of getting a bunch of user stories and then diving straight into coding, rather than taking the time to get into the true details and really flesh what the users needed. Which is another agile abuse.
I'm honestly getting pretty darn sick of agile, because even with the defects in other paradigms, I think better software was developed more quickly. It's amazing what a little up front thought (which most other paradigms call for) will get you. And again, a lot of people will argue that it's not agile that is the problem, but the abuse of agile. I agree in theory that abuse of agile is the problem, but since 99% of projects seem to do agile wrong in practice, it might be time to throw the baby out with the bath water and get a new paradigm that isn't so easily misinterpreted.
Beware of bugs in the above code; I have only proved it correct, not tried it.
If you're not doing Xtreme Agile, you're not doing Agile right.
Or at least that's what I keep hearing from all the Agilistas. They also tend to claim that any failed "Agile" project must have been doing Agile wrong, because by definition, Agile processes deliver useful working software at frequent intervals -- and they don't see the problem in defining "real" Agile processes based on an outcome rather than the processes used beforehand.
The more appropriate question is why your developers hate agile? And the most important question why is management pushing agile down the throat of developers?
Easy ...
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.
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.
Agile has a very different process than Big Design Up Front, but it definitely has processes. Frequent releases are a process. Scrum meetings are part of a process.
"First they came for the slanderers and i said nothing."
What you're failing to recognise is that there is little incentive to work beyond what you're told to do. I once worked on a product that always hit its dev targets on time, every release contained additional features that were not asked for (but were gratefully received by the clients), and every developer knew what they were doing now, and what they'd be doing in the near future. We had pride in what we were creating, and then it went agile.
Suddenly long term planning went out the window, and the dev team was forced into working in a reactive fashion, rather than a proactive one. Code became buggy, mainly due to the product owner not wanting to expend effort on things like 'testing' and 'documentation'. Any developer problems that needed to be fixed (you know, those important architectural refactors that are needed every so often), would be put into tickets, and would then be buried by the product owner so far down the backlog that they'd never be found again. In the end, if you had some spare time at the end of the sprint, you'd spend that time looking for a new job, rather than worrying about the complete and total mess the codebase had become.
Agile f**king sucks big time. You have a single point of failure, and that point of failure is the product owner. If your product owner is the best software engineer that has ever existed, then agile might work for you. If however your product owner is human, then it's likely your dev team would do better by actually making the decisions as a team. Agile does not promote teamwork, it pays lip service to it, and in the process, it removes any incentive for the team to work as a team.
Journals and conferences don't want to publish negative results, so you very seldom hear about all the people who try a process and find that it sucks for them.
Process success stories in the software field have always been driven more by special circumstances than science. Nobody has yet figured out how to (or at least bothered to) control for variations in sample-group productivity well enough to generate reproducible results for most process changes, and all the practitioners want to optimize their processes for different things. For example, CMMI and its ancestors are good if you have a load of time, good requirements control, and a few good leaders mixed with a bunch of more ordinary workers; Agile is good if your customers value whims over checking all the boxes and having really robust software; etc.
Finally, software changes can have chaotic effects, which makes it hard to apply a lot of the control, prediction and robustness methods used in other engineering fields. This makes me think that there will always be a large element of individual skill and domain expertise in building and delivering successful software, and that processes will always need to be carefully chosen based on the team and the project.
The problem with Agile is that it gives too much freedom to the customer to change their mind late in the project and make the developers do it all over again.
http://michaelsmith.id.au
that's the point. responding to change, quickly. you're saying that the goal of agile is the problem of agile.
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. Yet frequently customers expect it to be cheap because "we're agile". And by accepting that change will happen you don't push the customers to make important decisions early, ensuring that major changes will happen, instead of just being possible.
I still have more fans than freaks. WTF is wrong with you people?
False analogy. Designing and creating a car is much easier to manage as a "waterfall" since it is so much harder to change and the problem domain is often in less "flux". The sheer energy and expense to design a car; which consists of market research, basic R&D e.g. engine and tire materials, the design of the car, the design of the factory, the design and construction of the manufacturing equipment, the training of workers, etc., is so huge that upfront design makes sense.
In software the problem domain is often in flux, e.g. financial reporting regulations, and the cost of changes in software are lower. So software must be soft or lose relevance AND the fact that it is soft creates the danger of too many changes. We cannot think of software as no different than a factory, that is the original sin of software development.
putting the 'B' in LGBTQ+
Users don't hate agile. They want a system that is usable, delivered quickly and that works. When done correctly Agile does work and gives users what they want. but it does have its drawbacks especially in dealing with larger teams and larger problems. Users are also a subset typically of stakeholders. Stakeholders come in various categories but the more important the stakeholder, the more influence and stopping power they can have for their project. It's up to your Scrum Master or PM to keep them happy and if they're not, you'll be out on the streets in no time regardless of the methodology. To keep key stakeholders and keepers of the PMP flame, there are techniques and methods to reign things in but also not to make it draconian as to prohibit actual productivity. On the other hand those who hate agile are the ones who usually have invested a lot of time in "process." While agile has it's processes, they are considered anti-patterns by those who have defined things like structure and status reports and 'check the box here, did you check it? I'm still waiting for you to check the box. I haven't seen you check that box yet, were you going to check it? You have to check the box.' It reminds me of this.
What bothers me more and more is the FUD that's generated around any process change that instantly creates this knee jerk reaction against any changes to Software Development practices and techniques. Shit, if we all stuck our heads in the sand, we'd still be writing COBOL on Mainframes with POS facilities like TPF/ISPF. Anybody for punch card compilation? How about decolated listings?, that tablet thing is just a fad and you need to use pencils on 5 part form paper the all the nice carbon paper stains on it. No Fucking way do you need visual tools... Those are bad and promote bad habits we can just program everything with the switches on the front panel of the computers, yeah, bring back front panels and switches and blinky lights. That way we can troubleshoot bad instructions by looking at the registers...
Shit, when RUP came out everybody bitched that it took a special set of software to do those funny use case diagrams but guess what they didn't realize that it was the modeling that was key, not the tool but that point was missed and everybody wrote it off. Use Case driven development? It will never work I heard, shit that was what 15, 16 + years ago and people still bitch.
For those who don't like Agile, I suggest really trying to get involved with it, try it you may like it if not don't work with it and certainly don't work on an agile project if you're against the methodology; all you'll do is fuck it up. For those Agile folks who claim all the other processes are bad and don't produce anything, you also have to realize that businesses are defined by their policies and processes, for Agile to work you have to be able to live within that structure and not all software is done in an incubator setting with you and your fellow software developers being bunk-mates all living on Top Ramen. There are processes in the world, requirements and not all of them can be told as simple stories and for those who don't like architects, too bad, they help keep the orchestration together on those bigger projects and yes all systems have "qualities" that nobody likes to talk about when you start talking about scaling and all the other non functional requirements that won't show up on your story board.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
This attitude explains why software still sucks so badly - people making exactly the same mistakes they were making forty years ago. Mistakes which could have been avoided had they spent a day reading "The Mythical Man Month".
I don't know where you learned your Software Engineering, but at my university, the SE courses included lots of case studies as well as studying the various methodologies. Our professors had a very good understanding why some large project failed, yet again. So be dismissive of the Ivory Tower if you want, but don't fool yourself into thinking they know nothing.
I'll grant there's lot of things to get right, but can we at least learn from previous failures and stop repeating the same mistakes again and again?
Plan My Week for iPhone
...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.
Paying taxes to buy civilization is like paying a hooker to buy love.
I've seen actual agile, and I've seen stuff called "agile", which means, "we don't plan, but we do standups". "We're using agile" is a codeword sometimes for "we don't like or even understand SDLC, so we'll use no process and call that lack of process agile."
Not even remotely describing agile. Her "has 17 years of web development experience" jibes with my experience in a 5-man web shop where the term agile was literally a euphemism for "no process", and there was a COO asking for 6-month gantt charts despite the "agile" label; vs a stint at a top-3 software company where we had agile tools (ie, Rally), everyone got trained on it on our team, we had a very defined process (including using gitflow for branching and a review process pre-merge), and a full-time scrummaster.
I don't even think this is really giving agile a bad name, because I think anyone who has experienced both (or, say, just real agile) could tell the difference easily.
You are a problem.
You seem to fail to understand that there is no difference between designing a car and designing a software product.
All the things that go into designing a car should go into designing software. The fact that you don't do it that way shows the failure is you.
Chasing the current fad is for those without the ability to produce something of quality. They don't provide actual benefit, just waste resources.
The reason that software 'developers' get by with it and engineers don't is because most software can't result in someones death, where as an engineering failure on a car can.
You've tried to compare apples to oranges ... but only because you don't realize your oranges are really just another apple.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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. If you do that, then maybe we can solve the problem by, say, 3pm. Why wait until the next stand-up? If everybody did this with problems, your claimed reason for needing stand-ups evaporates.
No one who advocates Agile says that you should just ignore that you have issues until your next standup. Obviously if during the day you have issues you should tell someone. Nice strawman though.
Not a strawman - if you simply discuss issues as they arise, then what's the point of having dailies?
I'm a minority race. Save your vitriol for white people.
Uhh. One simple example of how they are vastly different.
Cost of recalling 5 million mufflers due to tiny flaw in production == HUGE
Cost of minor bug fix for (almost all) software == not so huge
This single difference drives all sorts of different optimizations for process.
Agile processes deliver useful working software at frequent intervals -
I love that definition... If you failed you weren't doing Agile..
Just because you've produced something working at frequent intervals, doesn't mean the user won't see it as "disorganized and never-ending"
Business unit: We want XYZ, We have a budget of $x and we want it done by July 1st.
IS Department: You see this is a math problem. XYZ costs $y not $x. You can't come and tell us exactly what you want to have done and exactly what you are going to pay. You can tell us one or the other and we'll provide the opposing data.
Business unit: That's not acceptable, and what about the date?!?
IS Department: We literally have no idea how long this or any project will take.
Business unit: We need hard facts! We need to claim our project is affordable and will be done by our arbitrary date! We need you to lie to us!
IS Department: Ok, well, we'll use a method called "Agile" and we'll completely make up some time and costs estimates. But the whole point of Agile is that we'll revise these dozens of times during the project so that, in the end, we can claim that our estimates are accurate because we basically just made them match what they actually ended up being at the end of the project. We will blame you for the overruns in our documentation, and you will blame us in yours. Then, in some meeting somewhere we'll generally complain that all projects over-run estimates by an average of 200% and gloss over the fact that this basically proves estimates are completely made up and are of no use at all.
Business unit: Perfect!
You are a fucking retard if you think there is no difference between making a software product and making a car. And I sure hope you never EVER get to work on ANYTHING more important then... fuck it, I hope it you never get to work on anything period.
Some rather obvious, to anyone with a brain, differences:
Car: Road safety regulations, any car going on the road needs to qualify in most countries to a very thick binder of rules.
Software: no regulation.
Car: Environmental regulations dictating fuel consumption and construction materials.
Software: no regulation, you can even do it in .NET if you hate the world.
Car: Has engineers work on it.
Software: Has software engineers working on it. These are NOT real engineers 99.99% of the time. Real engineers have to sign off on the stuff they design.
Car: Your car looses its brakes on the highway, you can sue.
Software: Your software crashes during crunch week, SUCKER!
The above poster then claims people can't die because of software error... is he really that dumb?
He seems to think that software design CAN be approached the same as car design... and this is were his REAL ignorance shows.
Cars get many times the budget and especially TIME that software gets. But cars also (increasingly so) re-use parts over and over again. Entire car lines are build on the same chassis, with the same stock engines. And what car maker makes it own tires?
Cars also work on universal roads, nobody would put a Jeep on Mars and then call tech support because "it doesn't work".
Software developers often are expected to create a complex piece of work, with many custom parts at a breakneck pace. It is because if you ask a real engineer to build a car in a week, he would snort at you. That is because the entire world accepts that this cannot be done. Software? They expect you to code a facebook, youtube, gmail competitor over the weekend for a hundred bucks.
and THAT is the big difference. Not in quality or capability of the people but in the treatment they get from management. And that is because car management people have learned that anyone who promises them a new car design in a week is stoned while software managers think "wow, I finally found the only honest developer".
Oh and finally, if car designers pulled of what software developers have been doing, our cars would not just run on water, they would do it on the rings of Saturn. See the current Jeep fiasco and the refusal for a callback despite a very high incident rate.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
You seem to fail to understand that there is no difference between designing a car and designing a software product.
I beg to differ. Cars have a fixed design: body, chassis, steering wheel, gears, seats, engine, tranny, suspension, fuel tank, exhaust, etc. Car manufacturers only change the spec of each of these components. Once you've manufactured cars for a few years, you know how much time and effort is required to make small changes for the next version.
The same does not apply for designing new software. Software design's scope is several orders of magnitude bigger than car design's because the former can do much more than the latter. Sure you may know how to write the GUI and program the database. But there are still many other pieces of the software you have not built before. These new components are brand new. So they can't be planned like you can plan a car component or a construction building. That's because you are building it for the first time whereas these car components and building structures have been built and perfected for decades or hundreds of years.
If you're not doing Xtreme Agile, you're not doing Agile right.
Or at least that's what I keep hearing from all the Agilistas. They also tend to claim that any failed "Agile" project must have been doing Agile wrong, because by definition, Agile processes deliver useful working software at frequent intervals -- and they don't see the problem in defining "real" Agile processes based on an outcome rather than the processes used beforehand.
well.. there's a difference between doing agile where you're supposed to and in making the user a part of the testing team..
why would the user care how the sw is developed? they don't. but if the fucking sw they have in active deployment changes where buttons are weekly as the developer is doing reactive development, that is going to suck balls.
world was created 5 seconds before this post as it is.
I really beg to differ there - you see the design that goes into a car and you'd understand that software is pathetically simplistic in comparison. There's a reason a new car takes years from inception to delivery, and why my car doesn't have a USB media, or Android or iPhone interaction - when it was designed, these components were too new for inclusion in car specs. Your argument that software is always new, while it has some merit in that our industry does too much re-engineering of stuff that should be stable, doesn't compare to car designs that have to utilize new stuff too.
Still, it doesn't take away from the fact that cars are designed well, and software is hacked together on a sloppy basis. No matter what unit tests or "best practices" or methodology you use, the comparison is still that software is cobbled together.
Now software used to be well designed, (and I don't mean where that means a huge requirements specification that can never be fulfilled), but designed as software. When I started out we were taught to write software by first laying out on paper how it would work and how it would interact with all of its components. Nobody does that today, and its probably why the software of yesteryear are still running your banks systems compared to how Microsoft cannot produce software that requires service pack after service pack, or a framework that they won't scrap and replace with something else after 2 years!
If we want our industry to be mature and well-respected, and for our software to keep running for decades, then we have to move away from the continual reinvention of the same old shit. We have to put up with moving goalposts all the time - thanks to the suppliers like Microsoft that keep on changing the OS or OS components so they can sell us new versions. We don;t help ourselves by chasing new languages and frameworks all the time too though. If we could fix this, we could start writing software that did whatever it was designed to, and didn't need replacing.
The way it was taught in my college class anyway, Agile is simply a different process for implementing code. The problem is not how the code is written but how the customer requirements are written. Both Agile and Waterfall will suffer greatly if customer requirements are incomplete or worse, contradictory. The results are always having to go back and rewrite code
Agile can work nicely to develop the customer requirements into a modular system where components can be quickly added and removed as opposed to the blob of spaghetti that Waterfall can produce. However both Agile and Waterfall can end up with that same blob of spaghetti when the developers are not disciplined enough to design carefully instead of quickly.
It's not that agile encourages laziness from the client... it's more that agile realizes that many (most?) clients don't really know what they want up front.
I find mention of the car design up above particularly useful, as you may have a client go through a lot of trouble to explain that they want a car and work with you to design a beautiful station wagon. You produce that station wagon perfectly to spec, and the user grudgingly accepts the station wagon but is never fully satisfied with it because what he/she *really* wanted was a sports car, but the user was unable to fully realize it until you handed over the station wagon.
Now that the process is over, though, the user is stuck with the station wagon unless he/she is willing to start the process again and throw more money at it (and at least in my contrived example, they got a working car).
The underlying goal of agile is to get the user to realize he/she wanted the sports car at a point early enough in the process to either change course and make the sports car with minimal extra overhead or realize the end product is simply going to be a station wagon and live with it or cancel the project early.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Academics with degrees in software engineering describing how to write code is like a horny virgin describing how to have sex:
The same goes for academics with degrees in medicine describing how to treat a patient, academics with degrees in civil engineering describing how to build a bridge and academics with degrees in accounting describing how to balance the books at year-end, I take it?
This is one thing that really p!sses me off about the programming world: the notion that "the real world" is all about graft and experience, and that actually thinking about what you're doing and why is a bad thing. I've just started programming again, and I'm following the advice I was given during my CS degree because it's good practice, and a good idea. When I cut corners, I acknowledge I'm being lazy, but I don't swear about ivory tower academics — I choose to break the rules for short-term convenience having assessed the impact of doing so, which is still good practice. That's what the "real world" coders forget: anything can be good practice if done for the right reason. The academics don't demand that we do everything one way every time, just that when we diverge from the "best" path, we do it conscious of the consequences.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Errm, that's exactly what waterfall is. You have a big upfront specification phase (essentially your user manual from your example) followed by a design phase followed by development etc.
The problem is that users truly don't know exactly what they need, and even if they did, those requirements will change over time in response to the market changing. So by the time that you've spent months writing a spec, 50% of what you specified will not be what is actually required. Worse you've now spent months writing out of date documentation and have NO software to show for it and opportunity to start getting back any of your investment - paper specifications are not a business asset. Then you spend still more months writing code against that spec, meanwhile another 50% of the remaining correct spec is now out of date meaning that by the end of development you've actually only delivered 25% of what the customer really wants and 75% of what you've developed is wrong. And you've still not got any software into production to be returning on the investment you've made.
That's why people looked at other ways of developing software and why agile gained traction.
It's not a perfect approach, but IMHO it's the least bad approach that we've tried so far.