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?"
Agile is to proper software engineering what Red Bull Flugtag is to proper aeronautic engineering....
http://programming-motherfucker.com/, do you speak it?
The major problem with Agile is that it is the new software development buzzword, and thus is perceived as a golden bullet for software development. Agile has a specific application: development of experimental software, where the project sponsors know they need something in a particular area but do not know exactly what. Agile (and iterative development in general) lets the target change over time as knowledge is gained. Unfortunately, iterative development is expensive, probably twice as expensive as waterfall for the same result: "refactoring" is another word for "rework," and there is a great deal of this in iterative development. Agile in practice is typically waterfall without a project plan: the project sponsor knows what is desired, and when, and is trying to get it for cheap. Iterative development fixes the time taken ("timeboxing") and the cost (level of effort); what is unknown is how long it will take (or alternately how much you can put into a sprint). Starving Agile has the same result as starving typical development: you only get the 1/3 of the software that is apparent, not the 2/3 that makes that 1/3 truly functional, reliable, and maintainable.
I'm a developer and I also hate Agile -- specifically the daily stand-ups. I really don't care what everyone else is doing. Just have what you said you've have done by the time you said you'd have it done and we're good. The only time I care is if you need to change something or the due date. But then you could just come and tell me the instant you figure that out and not have to wait until the next stand-up.
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer 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.
"Proper software engineering" does work, its called "Systems Engineering", is well established and successfully used for large-scale mission-critical projects in almost every industry outside of IT - which seems to be blind to anything invented outside of IT.
Systems engineering has its own professional accreditation organization: http://www.incose.org/practice/whatissystemseng.aspx
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!
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.
"Proper software engineering" doesn't work.
You're right, but you're going to the other extreme. The problem with all methodologies, or processes, or whatever today's buzzword is, is that too many people want to practice them in their purest form. Excessive zeal in using any one approach is the enemy of getting things done.
On a sufficiently large project, some kind of upfront design is necessary. Spending too much time on it or going into too much detail is a waste though. Once you start to implement things, you'll see what was overlooked or why some things won't work as planned. If you insist on spinning back every little change to a monstrously detailed Master Design Document, you'll move at a snail's pace. As much as I hate the buzzword "design patterns", some pattern is highly desirable. Don't get bent out of shape though when someone has a good reason for occasionally breaking that pattern or, as you say, you'll wind up with 500 SLOC's to add 2+2 in the approved manner.
Lastly, I agree that there is no substitute for good engineers who actually talk to and work with each other. Also don't require that every 2 bit decision they make amongst themselves has to be cleared, or even communicated, to the highest levels. If you don't trust those people to make intelligent decisions (including about when things do have to be passed up) then you've either got the wrong people or a micromanagement fetish. Without good people you'll never get anything decent done, but with good people you still need some kind of organization.
The problem the article refers to about an upfront design being ironclad promises is tough. Some customers will work with you, and others will get their lawyers and "systems" people to waste your time complaining about every discrepancy, without regard to how important it is. Admittedly bad vendors will try and screw their customers with "that doesn't matter" to excuse every screw-up and bit of laziness. For that reason I much prefer working on in-house projects, where "sure we could do exactly what we planned" gets balanced with the cost and other tradeoffs.
The worst example of those problems is defense projects. As someone I used to work with said: In defense everything has to meet spec, but it doesn't have to work. In the commercial world specs are flexible, but it has to work.
If you've ever worked in that atmosphere you'll understand why every defense project costs a trillion dollars. There is absolutely no willingness to make tradeoffs as the design progresses and you find out what's practical and necessary and what's not. I'm not talking about meeting difficult requirements if they serve a purpose (that's what you're paid for) but being unwilling to compromise on any spec that somebody at the beginning of the project pulled out of their posterior and obviously doesn't need to be so stringent. An elephant is a mouse built to government specifications. Ok, you can get such things changed, but it requires 10 hours from program managers for every hour of engineering. Conversely, don't even think about offering a feature or capability that will be useful and easy to implement but is not in the spec. They'll just start writing additional specs to define it and screw you by insisting you meet those.
As you might imagine, I'm very happy to be back in the commercial world.
So you've worked at Google? Beta is the goal.
I've done agile for the past few years and always waterfall before that. Was looking forward to agile because it sounded more flexible, but that's not what I've observed in practice. Everybody is so touchy about finishing up all of the sprint tasks by the end of the two week period, that there is a strong disincentive to bring anything new in, when you're finished up. No one wants to skew the metrics.
Between the aribtrary development cycle and the constant meetings, I find it far less productive than waterfall. Especially since so much waterfall is implemented in an interative fashion anyway.
"Proper software engineering" doesn't work.
As a Software Engineer in the formal sense (Engineering is regulated profession here in Canada) I can assure you that "proper software engineering" works great - and it's often Agile. Software Engineering is just like any other type of engineering, you have to pick the right tool for the job. That said, a lot of under-qualified people go around claiming to be Software Engineers and think that generating piles of paperwork will make their crap code (and crappier designs) smell better. They are just as bad as these people
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.
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
If anyone thinks that there is complete, 100%, nailed down design for a 75-story skyscraper before any digging starts, and that the design for the 69th floor is similarly nailed down before the 3rd floor is finished, they need to spend some time on a construction site. The overall shape of the building, the structural design, the very bottom and top floors, and the allowable parameters for design of the later floors, sure. But the exact design of floors 50-72? No. Plan for what happens when the selected elevator supplier goes bankrupt, the ship carrying a key delivery of structural steel sinks, the developer finally signs a tenant for 68-70 and he wants an internal staircase and private elevator for his offices? No. Look up "fast-track" in a construction dictionary.
sPh
If you're not doing Xtreme Agile, you're not doing Agile right.
That is correct comrade. Failure is always caused by insufficient ideological zeal and purity.
Until the thing is built or the software is shipped there are many options and care should be taken that artificial administrative constraints don't remove too many of them.
Exactly, and as someone who does both hardware and software I can tell you that that's better understood by Whoever Controls The Great Spec in hardware than in software. Hardware is understood to have physical constraints, so not every change is seen as the result of a screw-up. It's a mentality. I'll also admit that there is a tendency to get sloppy in software specs because it is easier to make changes. Hardware, with the need to order materials, have things fabbed, tape out a chip, whatever, imposes a certain discipline that's lacking when you know you can change the source code at anytime. Being both, I'm not saying this is because hardware engineers are virtuous and software engineers are sloppy, but because engineers are human (at least some of them).
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?
I work in a government office as a developer. We get lots of projects that come from management, who may or may not actually understand the business they're managing. If they do, they can give you some idea of what they want. If they don't... they can give you a very vague, buzzword-laden description of what they want.
What would tend to happen is people would go off and try to use something like waterfall. They'd go gather requirements, build a big specification, design, etc etc. The managers in question would sign off. We'd build it. We'd then learn at the end that it actually doesn't do what they need it to do, and their business actually doesn't work the way they said it did. Why? Because managers and users suck at dealing with this type of stuff (in my experience). In house, consultants, it doesn't matter. This has been done wrong so many times that we decided to try something more agile.
And it's worked for us. We build the pieces that people actually do know we need (either because they're based on a paper process that we can look at, or because some user can articulate it). We get that into people's hands. They tell us what they hate, what they still have to do manually, and what would make their lives easier. Then we go off and build those pieces.
It's not actually saving us time, but the users have been MUCH happier with the end products. And since I like happy users and dislike spending time building things that are pointless just because two years ago someone thought it should be in the requirements, this works out pretty well for me.
It's not the right way to do every project or in every environment, but my users certainly don't hate it. (Quite the opposite, we get a lot more feedback from people asking for improvements now because they've seen it acted on more readily.)
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
You've fallen into the trap of using their terminology. As soon as 'the problem' is defined in terms of 'upfront design', you've already lost half the ideological battle.
'The problem' (with methodology) is that people want to avoid the difficult work of thinking hard about the business/customer's problem and coming up with solutions that meet all their needs. But there isn't a substitute for thinking hard about the problem and almost certainly never will be.
The earlier you do that hard thinking about the customer's problems that you are trying to solve the cheaper, faster and better quality the result will be.
Cheaper? Yes, because bugfixing that is done later in the project is a lot more expensive (as numerous software engineering studies have shown)
Faster? Yes, because there's less rework. (Also, since there is usually a time = money equivalency, you can't have it done cheap unless it is also done fast.
Higher quality? Yes, because you don't just randomly stumble across quality. Good design trumps bad design every single time.
Agile causes anxiety in the clients because the first thing you do after the requirements have been gathered is to ask the client to prioritise them. Naturally the client is going to start imagining worst case scenarios, where the developers can't do everything they've been asked to do*, and so they push back, saying that everything is important, and then the developers want to know what is the most importantest (sic). The solution is to do technical prioritisation. If I go to Honda to tell them how to build my car, and then tell them that the tyres and steering wheel are the most important things to me so they should start building those first, Honda will politely tell me to let the experts do their thing. By analogy the whole thing of making the clients prioritise the features really only works when you've already got a car, and they're choosing what options to add (read as: additional features after you've done everything that was on the initial requirements)
*Not unreasonable, given that even the Agile evangelists say that 60% of software projects fail.**
**Before Agile became the dominant methodology the failure rate was widely reported as 30%.***
***Make of this what you will.
Agile can also cause anxiety in the customer for other reasons. Imagine if you wanted a wooden chair and your developers all ran into the forest and each started madly chopping down a different tree. When you tell them the particular type of lumber you want it to be made out of they tell you to bog off because they're not at that stage of the project yet. Of course, that's not actually what happens. In fact everyone is chopping madly into the same tree (but all at different heights ... )
Disclaimer: none of the Agile projects I've ever been on have failed. But then neither have any of the waterfall or RAD projects, or even those with a null or ad hoc methodology. The common denominator for success is not the methodology.
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
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"
Of course there's a big difference. Software is essentially the most malleable and fungible thing humans have ever devised. The big problem in software engineering that doesn't arise in automotive engineering is that in software engineering, the requirements are frequently in flux. If you can fix your requirements as precisely as the requirements for a car, than yes, there is no difference. But in general this isn't true. Unless you're writing software for NASA or something similar, most such requirements often can't be so easily nailed down. You get a giant spec, build the thing, and then realise that the process the software is designed to integrate into doesn't quite work the way the spec says it should. I've been in the software business for close to 20 years and except for a brief stint in embedded systems this has always been the case in my entire professional career. We build something and halfway through the design we find it doesn't quite work the way they customer wants it, even though yesterday they said that was what they wanted it. Are you going to tell the customer: "fuck you, you said it should work that way and that's the way we're going to build it!"? That is not the way to treat any customer, most especially when you can, with some additional effort for which you should be duly compensated, accomodate their desires. Defective brake pads can cost a car company billions in recall and replacement. Similar bugs in software can be fixed almost painlessly by comparison. Software can also be far more complex than cars. A typical car probably has a few thousand distinct parts. Software like the Linux kernel has distinct parts in the billions. Try to tell me again how there is no difference between designing cars and designing software.
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!
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.
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."
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.