The WORST Way to Develop Software
HTML-код
- Опубликовано: 6 фев 2024
- Waterfall is a poor fit for software development, there are some deep and fundamental differences that position the agile vs waterfall as profoundly different. Waterfall development is built on the assumption that we can divide the problem of software development up into a series of distinct, discrete stages, with each stage handing on presumably perfect outputs that initiate the work of the next stage. This is clearly an illusion, in practice waterfall development doesn’t work like this, because there will be mistakes, but waterfall does build barriers to feedback that allow us to clearly see the mistakes, and make it very difficult to correct them when we do find them. Agile development starts from a more stable, and profoundly different starting point, that is it assumes that we will make mistakes, and so is built to detect them more easily through iteration and well-established mechanisms that support feedback.
In this episode, Dave Farley author of best-selling books “Continuous Delivery”, “CD Pipelines” and “Modern Software Engineering” explores why “Waterfall” persists as an approach to software development, when it is patently so unsuited to the exploratory nature of software engineering, and what works better.
-
🎓 FREE CD FUNDAMENTALS COURSE:
Introducing the concepts, explaining the benefits and key practices, and suggesting first steps to start with Continuous Delivery. Study CD FOR FREE, online with me. Find out more HERE ➡️ courses.cd.training/courses/c...
-
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content! ➡️ bit.ly/ContinuousDeliveryPatreon
-
🖇 LINKS:
🔗 "Royce's Paper" ➡️ www.praxisframework.org/files...
-
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: ➡️ bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-
BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com
#softwareengineer #developer #agile #waterfall 
Наука
🎓 FREE CD FUNDAMENTALS COURSE: Introducing the concepts, explaining the benefits and key practices, and suggesting first steps to start with Continuous Delivery. Study CD FOR FREE, online with me. Find out more HERE ➡ courses.cd.training/courses/cd-fundamentals
We didn't teach software engineers how to build and deliver software in school, so they had to learn these processes on the job. The vast majority of these engineers ended up at companies following very traditional software development practices. Fast forward 20-30 years and some of those engineers are now senior leaders in software organizations, pushing the same practices they learned in their earlier days. After spending decades climbing the corporate ladder, they aren't going to put their job and career at risk by adopting newer methodologies they have no experience using. Many of the challenges we see in software engineering today are largely leadership challenges and we likely need a new generation of leaders to address them.
Well said.
Iterative development has been around since 50s. They certainly weren't doing big bang releases for the Apollo mission because the hole dieing thing.
Smart people do common sense things around a problem to solve.
Someone from the DOD coined waterfall and it got into the sales books of project management institutes everywhere. Turns out it's just the same thing weve been doing in sequential manufacturing since Ford so everyone was comfy with it, especially those that got there mbas and leadership experience from playbooks based off of ge, GM, Ford. Which were the leading organizations in the world so why question it aye?
On it, Ser 🫡
I would add that waterfall delivers "precise" time and cost estimatives, and lower management loves "precise" numbers, specially when they can be squeezed into the corporation's chronograms making things look better. Everyone knows the numbers won't be even close of the actual values, but they can later blame the developers for being "bad at estimating effort". And that's why waterfall will NEVER end.
I am not so sure. I have been in many so-called Agile projects, all with good people and with a supportive management. All of them have eventually become sequential in nature, and it has not been because it has been forced, but because it did not match the need of anyone in the teams or the organizations.
The only people that seems to have thrived in those settings are people that are extrovert and really like to talk a lot, but not do a lot. Many meetings, many white board sessions and many conversations that did not really become something concrete.
This is of course very anecdotal based on less than 50 projects and just in Sweden, but I have worked in several companies with hundreds if not thousands of coworkers that pretty much all have the same experiences.
What I do agree with is that the vast majority of people that say they work in Agile ways all seem to have picked up chaotic ad-hoc versions of sequential work with standups rather than anything that even remotely look like Agile. So maybe that is why most people I know always seem to favor sequential work with short iterations over Agile...
If you want to push back against waterfall, you need to be prepared to also push back against project based funding models. In my experience that's where the core impedance mismatch lies between teams that want to build software well, and the organisations that they are a part of.
Bingo
exactly. if you want to see this on steroids look into large scale SAFe 'projects' where each 'product iteration' ( i.e. mini waterfall) is 'sponsored' by a different business unit
"be prepared to also push back against project based funding models" - unless you are in mid-upper management, your advices and warnings will fall on deaf ears most of the times.
That's right. From my observation, the waterfall is initiated by business, when they decide that nothing short of "this 1 year worth of functionality" is valuable for them. This starts the whole planning, design, estimation etc., which eventually turns into a classic waterfall project, but with 2 weeks sprints, so the managers feel good about "doing Agile" :). On top of that, business is not interested in reviewing partial work, as it's not "valuable".
Agile methodologies had different funding models more than 20 years ago. Unfortunately there was little interest.
“Walking on water and developing software from a specification are easy if both are frozen.” - Edward V Berard
In my experience, waterfall tended to get one of two responses from the customer:
* That's what I asked for, but not what I wanted.
* That is what I wanted, but it's what I wanted a year ago. The business has changed, and I now want something different.
Tbh for me it is just people never understanding each other, because they look at the project through completely different glasses. The "designers" have a completely different understanding, than testers or devs. So they can never even talk to each other about small details without huge effort or huge missunderstandings.
* That's what I asked for, but not what I wanted. - I'm afraid that's on the customer. Nobody is able to read minds.
* That is what I wanted, but it's what I wanted a year ago. The business has changed, and I now want something different. - this is what usually happends with waterfall proejcts. When they're done, they are obsolete.
@@ForgottenKnight1 The first issue is a result of failure to communicate. This could be due to natural language being ambiguous. Then when the customer sees the actual product, ambiguity disappears, and they see what's really there, and the mismatch in communication becomes apparent.
The second issue is business needs changing as you mentioned.
Both of these can happen with Waterfall and Agile! The difference is that with Waterfall it can take months or years until you've identified the issue. With Agile it may only take days or weeks, and the issue is probably much easier to address with a shorter timespan.
I don’t think ANY development process would work when Time To Market is king. I have seen waterfall work very well in projects where time to market doesn’t rule. They weren’t small either, but quite large and complex ones in telecommunication. As soon as the time to market concept started to compress development times, project failures grew dramatically. I have also seen agile projects fail spectacularly when management gets nervous and begins to interfere in the development activities. They don’t trust that the developer can actually talk to the customer properly (apparently you can’t tell the customer you don’t understand that requirement and they need to clarify!). Also management HATES IT when the total project effort and timeline is not locked down before we start - this is in agile projects. The problem is, the phrase “agile project” is really a contradiction in terms…
"* That's what I asked for, but not what I wanted." - Then the requirement's aspect of the project failed. Both in the planning and in the execution. Failure to identify what was needed is the basis for requirements, after all.
"That is what I wanted, but it's what I wanted a year ago. The business has changed, and I now want something different." - Failing to work with requirements, especially during long projects, is another failure. Requirements are not static, they are living for the full length of the project.
So this does not sound like a problem stemming from sequential methodologies, but a failure to communicate, collaborate and iterate requirements and business needs.
I have had management demand that the project followed the waterfall steps, following the comment that it feels like the right way to go. The best solution i found was to perform waterfall within the scope of a single month long sprint. Perform all the steps but only for a single feature at a time, it is essentially agile with some variation in the sprint execution. It satisfied managements desire while still limiting the risk exposure to a single month.
People criticized this approach as not being pure agile but in the end we all get paid to do what management wants.
I call this "rapids": waterfall in just 2 weeks.
@@chpsilva Thats a good one, the rapids but they were month long sprints, essentially a 2 week sprint doing the design , requirements and system design works. the second 2 weeks were executed like a typical sprint performing implementation and test.
I remember one exec having kittens over the idea that we were writing test cases before implementation. he just couldn't get it.
Another reason why waterfall and feedback don't work in practice is that "higher" levels are also mostly associated with higher status within the organisation. Think business, requirements engineering, software architecture, etc. These are not just elements of the waterfall but in reality actual hierarchical structures.
I agree and would like to add that in many cases it's not a real, but self-perceived high status. Some people try to stick to the waterfall model because it makes them look higher status. It took me many years to understand that.
I feel like this railing against waterfall is a rant from a bygone decade.
What I actually find common is that teams will eschew any and all forms of design & planning altogether and produce utter shite the first time round instead.
They will tell themselves, it's fine, its agile, we can refactor later.
But guess what, manager comes and says, DEADLINE, refactoring not a priority!
So in essence, what happens is the baby gets thrown out with the bathwater, you wanted to be "dynamic to change" but in reality, what you've got is something resembling barely organised chaos.
OK you might say, this is preferable, at least we've got some sort of buggy implementation to give to a customer instead of a 2000 word design document.
But what I would like to see is a balance of approaches and to move away from "just apply methodology, switch brain off" style of dogmatism that seems to be everywhere.
I may have been unfortunate but this is all I’ve seen, worse this replaced the traditional system development process. Progress in many places has stalled as the design of many concurrent components has become incoherent and chaotic… this was enforced with scrum and even worse in places that enforced SAFe. When dealing with physical systems where failures can kill you just can’t certify what has been done anymore because the teams were immature and unable to manage the configured baseline. Ironically what management had not seen in one place I worked is we were already agile in principles (which is all agile manifesto is). We weekly IDTs, Kanban, when major issues came up we had daily stand ups, as the lead system engineer I talked daily with 3/4 detailed development engineers and were getting quick to evolve design and requirements in a controlled manner on the basis we understood they were there to facilitate discussion. Then… we had to use Scrum and had to BE agile and it all fell apart as no one understood the lingo, or how these new processes fitted with our extant ways of working and development processes 😂
Waterfall is alive and well in my company. They just don't realize it. (we use scrum)
Yes this. People are so afraid of being acused of doing waterfall that they've given up almost entirely on planning and design.
Did anyone actually follow waterfall process? I've been doing this stuff since 1978 and have _never_ seen anything like waterfall actually used. What I have seen frequently is "process theater" where people believed, or acted like they believed they were following something like waterfall. But the actual production of any software, by the people doing the work, was always done in a XP/agile-ish manner. One symptom of this I've seen many times is when a design document is written that is _never_ read. The system gets implemented anyway, so there's some design in someone's head, but it's not the one in the design document. The design document only existed to meet someone's request that it be written. At best the process of writing it may have caused some thinking to be done about the system before writing code. Same thing with plans. People made plans, but they were a fantasy and immediately went off the rails.
Yes, I've seen this too. At some point you have to abandon the process to ship software. But make it look like you're following it, to keep higher ups happy.
But at that point you're not doing agile either, you're often just hacking together software without the discipline and practices that ensure quality code (like a test first approach, ci/cd etc).
@@manishm9478 Everyone's winging it. Same as politics. My software team is no more "agile" than my nation is "capitalist", there is corruption and rule bending at every turn, so much so that pretending that there is some kind of philosophical underpinning to it all is deceptive. The "shitshow methodology" is how software actually gets built.
I’ve worked in a medical device company that used a V-shaped model (an implementation of waterfall with heavy V&V).
Process theatre is completely accurate. The company pretended that they follow certain SOPs to fend off audits. That included filling out template documents that demonstrated an expansive plan for how the software will be put together and maintained. It’s not the requirements part that was problematic. That part was great because the requirements DIDN’T change much on a pre-production device. It was the fake traceability and risk analysis and other bs that provide no value to anyone reading these docs. It may have been valuable to the person writing the docs but not to a reader. Everything was very high-level and when it came to the actual implementation, I haven’t the slightest idea which features went in the code because the implementation was poorly traced to these documents.
I work at a place without those rigid standards now and it is a lot more “do whatever you want. It’s a lot less micromanage-ey but the mess is much worse than a place with some standardization. Letting people follow agile processes winds up making a mess. True waterfall is just upfront planning at the end of the day. Details might change but if you’re constantly shifting goal posts, I’d consider that poor project management altogether and the end result will reflect that.
Real world waterfall has always involved feedback, going back to earlier phases, getting input from the programmers on timelines and regularly modifying the plan. The rigid idea of waterfall seems to be more a caricature based on the earliest proposed model of waterfall. I suspect that caricature exists primarily to enable "agile" consultants to sell expensive services to companies.
I do think good documentation is always easier to reference than the code, but these days it tends not to exist, so the only option us is using the code.
@@loganmedia1142 agreed re documentation. Sometimes even though code is harder to read, it's better to use it as the source of truth anyway if devs aren't able or willing to produce good written documentation 🥲
On the project I am currently assigned to one of our teammates had ran into the classic waterfall case of product manager and designer creating designs to be presented to the developers, who then said these are all wrong and can't be implemented this way. The solution was of course not to invest heavily into perfecting the designs and then passing them forward but involving developers in the design process and getting their feedback early.
It is really funny to hear ‘waterfall must die’ over and over again, and hear that agile is different. But there are mental activities we have to do in the order:
1. Understand what it shall do either from customer or ideation
2. Define HL structure
3. Implement details
4. Check if works as expected
5. Fix
6. Ship to customer
Different order is useless and troublesome. The only difference is the size and length of the iteration.
And the fact that you do or do not separate the jobs of these phases into different teams.
Did you even watch the video? This is exactly what he was criticizing.
How do you do step-1 if the customer themselves don't understand what they want.
How do you do step-2, if you don't know enough about your own systems, the environment you operate in and information which you either forgot to account for or is hidden from you?
If you didn't do step-1 and 2 right, then you'll spend step-3 building the wrong thing, confirming incorrectly that it works correctly in step-4, and fixing things which don't need to be fixed in step-5. All while wasting precious money and time, which you'll release 2 years down the line.
The expectation of a big bang release delivering value in one swoop is pure delusion; Continuously working with the customer in **ALL** phases is the only real way to do anything even remotely complex. Everything else is just process overhead justifying salaries for non-productive people.
He is not even advocating for a different order? And also, the size of the iterations are a vital point in arguing against waterfall?
truth
It may sound like a trivial difference, but in my experience the iteration size matters immensely. An iteration cycle of a week means your plans can be sketches on a whiteboard or paper, meetings can be short chats, the code is structured simply and releasing is easy. An iteration cycle of a quarter means detailed plans (because people will forget the design after a month or two), long meetings, complex code to fit all the features, and risky all-or-nothing deployments.
Agile is just series of small waterfalls.
Change my mind.
I won't. The size of iteration matters, it's the whole point. If you work in 3 week sprints, you run 3 week sized risks of doing the wrong thing.
It is. And that's good. Isn't it?
And that is how waterfall typically worked in the real world. A long term plan with regular, typically weekly, adjustments to the plan. Also normal to chat every day about progress and problems.
On the other hand, slipping in new stories multiple times during a short sprint is also a bad idea :) More often than not (in my experience), the engineers in agile teams are not empowered to say "no, it's not a good idea for us to accept this into this sprint".
Or you don't have sprints and just start a new story from the backlog once you've finished the previous one ?
It works surprisingly well :)
@@wilyacalima1280 RIGHT??? Like, that’s what we’re are always doing anyway, because if you get done early you’re supposed to pull something off the stack to work on anyway… I get that the cycle gives artificial deadlines to keep momentum but.. so much effort forcing it to work
The problem is that management wants certainty, whether that's a predictable expectation or not. They want to know how much to budget for this world-changing new feature (and how soon after that you can start the next world-changing feature), sales wants to know when they can promise the customers it'll be ready (if they're good, that is - not all salespeople are that considerate), and finance wants to know how much revenue they can expect to see. Unfortunately, none of these has certainty, but that doesn't stop people from trying to insist they should, especially when uncertainty is the less comfortable reality.
I first encountered the Waterfall model at University (Greenwich, UK) . The lecturer, a 'consultant' who always wore a suit chuckled as he recalled attending a conference where the speakers had suggested feedback & revision right back to the top of the waterfall post delivery. He also believed that coders and designers should be separate roles and that "Anyone can be a programmer!".
I thought he was an overpaid, narcissistic idiot then and I still hold that view.
What do you mean by designer? UI design (web design) or „architect“?
@@pianochess1882 All the waterfall stages before code is written. Designers give coders the specification; coders just implement it.
But that does not sound too different to ivory tower "agile" consultants today. They've just changed the terminology they use.
@@loganmedia1142 I can't comment on others' unpublished opinions, but textbook Agile involves close cooperation if not combined duties to allow iterative design as problems are discovered and requirements change.
On the other hand the Waterfall model assumes the requirements will remain static, that everyone at each level will do a perfect job and that no one will encounter any structural problems.
I have never really observed the neat waterfall sequence in software development. I have always been a part of a process that iteratively builds, tests, designs and updates requirements. I feel it is human intuition. What I see in “agile”, is teams never really thinking beyond their nose. It is like deciding to go on a picnic, and not putting any attention into the planning. So you arrive at the beach, and then realise “oh, I need some drinks. Then after getting the drinks, you arrive back at the beach thinking “oh, I need some meat”. So on, and so on. There is nothing wrong with planning. You just should never get too attached to it, and you should focus on the factors that could make or break your plan early on.
I guess you have never seen a real waterfall project or a real agile project then. Sure, waterfall in reality is always somewhat water down in practice, because it is pretty close to insane without. But as I said, if you can't change direction you aren't agile and most projects can't change direction. In your "waterfall-light" projects did you do all of the testing at the end?
@@ContinuousDelivery not sure if you read what I said. I said that testing has always been done throughout on all the projects I have worked on in software. You put words in my mouth about waterfall light. I have worked on teams who pride themselves on agile best practice. But I can't say that the principle of learning fast and early was the result. The actual was ceremonies, JIRA tickets, regular release SCHEDULES, story point estimates etc There was almost no focus on "are we fighting the right battle", and "let's feel the waters".
Ah right - we've never seen real waterfall or agile projects. No True Scotsman at it's best. Well, you know what? We've never seen it because it doesn't exist. @RowanGontier is spot on: agile shops pride themselves in following ceremonies and putting points on ill-defined stories.
@@maxlarose2258I would argue agile is really better suited for startups with just devs, target users, but uncertain product market fit and no upfront contracts/sales. Or for maintenance projects which already have users but everyone wants some customization.
Any large company that is executing on contracts absolutely CAN use waterfall because they are fulfilling a contract (concrete requirements defined up front). You can be flexible and stuff throughout of course but ultimately, businesses need some level of standardized practice to distribute work across their team. It’s different than indie dev or R&D where you’re bringing ideas to life through trial/error. If the customer completely changes the ask, that’s not the fault of the devs who built what was previously asked. You can always plan for adaptions and scalability/extensibility. However, managers can’t plan out a project and schedule a delivery date with agile unless the contact says “whenever you’re done”.
The grievance really arises from corporate nonsense that we’re all stuck in rather than the principles of waterfall or agile. I’ve worked in both settings and the problem is ultimately that I don’t have agency to decide what I’m doing. The managers make promises and decisions that were bad and I ultimately pay the price.
That's real world waterfall. In fact the very basic waterfall people like to criticise was superseded long ago, even before people talked about being agile. And you're right of course, building and testing was always done continuously throughout the project. Typical waterfall projects would change direction whenever needed too.
Maybe there were really companies that put a rigid plan in place, then went away and worked on it for years before checking how they were doing or testing anything, but in three decades I've never seen it.
Waterfall success is mostly due to management thinking of creative processes as production processes. It is basically an attempt to apply assembly line optimizations to a process that, as pointed out in the video, is explorative for the most (hard) part. You can see it happening on other complex (as it, involving multiple people) creative processes as well, such as research, authoring books etc. The reason it has not been eradicated is that a significant part of development is repetitive, a lot of software products are basically the same thing with the same challenges. This validates the idea that supply chain is appliable to software, and since the world economy after industrial revolution is based on the supply chain, the waterfall process is confortable for management. It also gives this nice illusion of knowing how much work is left and when things are expected to hit the market, which is the only thing that is being discussed with higher management.
The chimney example.
When contracting new software, buyer wants to transfer risk to provider. Sales team wants commission. SW team are expected to come up with timescale and cost that mitigates the risk as much as possible. Ouch.
Many software teams claim there can never be an estimate. Team needs to be active in sales process, just waving hands in air and pointing at the agile bible doesn’t help.
When you do your chimneys will you go with the builder who gives a fixed price for all, or the one that say open budget.
No one method works, sales also need to push back. We can’t commit to deliver by this date, but we can commit to work on it with you over next 2 years. Everything doesn’t need to be delivered day 1. “Why is this needed” often reveals customer doesn’t know either. But sales often want to say yes rather than “I think YOU might be confused”
The yes we can commit to x is very attractive to both customer and sales $$$$
I worked in a company where we estimated the cost of a project using waterfall and Rational Unified Process - RUP made us figure out all the constraint and problems with delivery and the cost of doing so - we estimated a couple of years work and about a million dollars. The waterfall manager just picked a figure of $100,000 and 3 months to deliver. So the company went with the waterfall method because it cost less. 3 months later the project had barely moved and they had spent $200,000 on it so far. I asked a higher up manager why they went with the waterfall and he said "it cost less and would take less time. We would never get a budget of a million dollars, $100,000 is do-able". I said yes but it isn't and he said "oh we knew it would run over and it is still less than the RUP estimate' - absolutely insane!
It is a common practice in some unscrupulous companies that they give low estimates and then screw the customers over since they know the customers can't afford to change to a new provider, so they are basically forced to pay to see their project completed.
It is a shitty way to do business and as such it tends to be big companies that do it since they can bully people and because they can risk loosing a client or two in the process.
Processes that fit into waterfall are favored because project management are used to break down projects in phases in order to create estimations for everything - in order to set a budget. Often being very specific and sure about what should be done. Most should be known early. And then that influences contract, costs, and strictness. The problem that they don't see, or just accept, is that the accumulated unknowns affect the project's time and costs further down the line. For instance, delays that will influence people in that project. They try to correct it with margins but... what if we could just accept that nothing works out exactly the way we first intended. That we will learn along the way. And that when we don't get overwhelmed by projects and control we will less likely exceed any budget by much.
If you know what you are doing when you make the estimates, you factor in the unknown. Good developers do like Scotty in Star Trek :) Always overestimate and overdeliver. Never underestimate and underdeliver. No one ever thanked you for a low estimate that was not completed in time. Everyone will thank you for a high estimate that is delivered early.
There is another reason for phased projects, and that is that you have multiple checkpoints where a project can be scrapped if the value is lower than the cost. You also have all finance in the world operating on annual cycles, and that affects all work in a company.
Great video, but it will never change. Not because it shouldn't, but because, just as not all ideas are equal, not all stakeholders are equal either. All forms of agile development presuppose something that just isn't there in soft dev. Cooperation between stakeholders. Not going into details, a certain feature was DEMANDED by business owner. It was "visually designed" by the concept designer. And was handed out to the devs to implement. It was a s**t idea, was "we're doing it different from everyone (for the sake of being different not for added value)", was a clusterfsck to implement and violated every "good practice" on the target platform. And we obviously provided feedback and got told to "do it anyway"...
p.s. the owner codes, the designers code, all understood the problems we'd face and that it would be a "sub optimal mess". But it would be a cold day in hell before they let common sense interfere with their "vision"...
Totally agree with this point. Software development involves much more than software developers. Other stakeholders for various reasons (lack of knowledge, politics etc) often oppose this. And therefore nothing changes and things remain terrible.
Dave this is one of the best descriptions of why not to do waterfall
Thanks ☺
when people talk about how agile is better waterfall, they always talk about a type of waterfall that is barely exist anymore. The "iterative waterfall" using by different vendors is at least better than scrum
Yes, let's embrace waterfall with sprints, double the agile coaches/project managers = double the fun.
From a legal point of view, waterfall is easy to understand and can be balanced between the customer and the developer. Agile however is practically impossible to properly balance in a contract, as no developer can to commit to a certain result using an agile methodology.
Hello to you, Dave and your team. I have recently subscribed and am happy to have done so with so much great contents. Thank you! This video made me about other resources, mainly the "Mythical Man-Month" essay from Frederick P. Brooks and I have a question. In your conclusions, you mention our inability to predict the future as the main culprit for not being able to answer the 'how much' and 'how long' questions. However, how do you articulate this with the issues in managing complexity, especially complexity of managing people, arising from the neccessary division of labour in complex endeavours?
The original paper wasn't recognizing Waterfall as what we SHOULD be doing. It was documenting what they ARE doing. And, as you mention, the paper pointed out flaws in that process.
Most of "management science" was developed during the Industrial Revolution, where assembly lines were the way everything worked. Insomuch as many software development managers (or project managers) are trained in management science, they will seek to turn everything into an assembly line. When all you have is a hammer ....
I think this was said about 20 years ago.... I don't know any IT teams doing this today. We're certainly on CI/CD pipelines, etc
We were building and testing every day 30 years ago.
Most of these models were generally created as part of the expansion of the computing and software discipline going into the 70s and 80s and mostly associated with US government projects and R&D. The problem is that "agile", "spiral" and "waterfall" are just words that can be defined differently by everyone who hears them. And even beyond that, can be applied differently by every team that applies them to their own situation. Technically at a very high level, the intent of waterfall is to say that certain steps are required as precursors to other steps in the development of software. And this happens all the time when you look at other disciplines such as engineering, where you have to do the analysis, design and validation before you actually start building something. Also, you have to remember the time when that waterfall paper was written. Software development was nowhere as simple as it is today and many of the techniques and practices were still being created. You didn't have tools like CI/CD or even source control as sophisticated as you do today. Different time and different environment. Conversely, the popularity of the agile archetype is based on a post 1990 internet startup model of software development where you could take your time and build the "next big thing" before going public. But even then, most companies are not startups and don't have infinite cash to spend on building the "next big thing". And many times most companies don't work on large government projects, which are the biggest users of these development models such as waterfall (and agile and PMP). Ultimately though, businesses only care about trying to give some higher degree of quality and success in project outputs along with lower costs, which is why, no matter what the philosophy is behind the terms, they will always impose a more rigid dogmatic implementation of those ideas. And that is where most of the problems come into play at a fundamental level. Also, fun fact, the reason for the large amount of failures in IT isn't simply because of the software development methodology.
Even when we are being agile we still have to do the initial analysis and design. In a way they hide it away and try to pretend it doesn't happen, but in fact a huge amount of time is devoted to it. Companies also do still make long term plans because they need projections to plan ahead.
@@loganmedia1142 Exactly. Waterfall is simply a basic outline of things that have to be done as part of building software, ie test the code before delivery. Doesn't mean you have to to that as the very last step or all at one time. Just like agile doesn't mean you don't have requirements, just that it isn't necessary to have 10 levels of requirements docs fleshed out and signed off before starting to code something (and a large number of projects are never going to see system requirements docs to begin with).
One thing underpinning the Waterfall model is that development happens at many different levels of abstraction. As a person can only grasp a limited spread from high to low abstraction, the steps in Waterfall are often done by different people.
The fault in the Waterfall model is that it assumes people working at higher levels of abstraction can predict with 100% confidence the needs for the lower levels and are isolated from any discrepancy. This feels very safe for managers, who are thus isolated from the nitty-gritty details in a project, but is not how the world operates.
Spot On! I'm grateful that I stumbled upon your channel. Here in India, most IT professionals have a strong resistance on the Build Fast Fail Fast strategy as they assume that anything going wrong means it'll cause delays and budget overruns. Until then most of us will never understand the real problem that a waterfall methodology does to an entire software project.
Very well put, as always. However, in my company, we do quite a few public tender offers. The price, besides being fix price, is often lowered by management to increase the chances of success. Other criteria also matter, of course. But because it is fix price there is no other way than to make a thousand assumptions already in the offer phase, just like in a waterfall project. A huge chunk of time is then spent on scope management, discussing every deviation from the offer. What would be your recommendation for such projects, where scope, price and even quality is fixed from the get-go? The only remaining variable is the deadline, but for some projects, even that is fixed. 🤣
How does "Quarterly Planning" fit into the Agile process? Does it make sense to create a backlog of work on for the next 3 months or is it too much planning?
My response would be "what is actionable about this?", followed up by "these are just gueses - if they can be wrong, and they will, why bother in the first place?".
You always end up having to make guesses about the future. If you don't have that planning then most of the time what happens is simply chaos.
We should call waterfall "blindfolded development" and then maybe the problems would be more obvious.
It's basically the idea of picking a direction to walk, putting a blindfold on, walking and then hoping you will get to your destination, even though your destination is a moving target and the route to get there is complex and ever changing.
Or look at a map of your commute to work, plan which roads you're going to drive on, put a blindfold on, get in your car, start driving and see if you get to the right place in one piece.
Agile is just taking the blindfold off and then making course corrections as you go so that you avoid obstacles and get to the right place, but people don't seem to understand that about agile either, even though when you put it that way it's so obvious that it will work better.
People think they are doing agile because they are splitting up work into smaller parts just to fit into sprints and going to scrum ceremonies but then don't release the software to users to get feedback until the "MVP" is done, months after starting, and then think agile doesn't work, because they missed the single most important thing about agile, which is to get fast feedback from users and make course corrections.
There is online one thing worse that waterfall - it is badly implemented SCRUM😂
Scrum itself isn't great. Should be viewed as at best training wheels, to be taken off as soon as possible.
Hello sir. For well known projects, like modifying a banking software to follow law change, i don t understand why it would be a bad thing: analysis first, then code instead of code based on vague or inexistant spécifications, with no documentation or analysis. Code architecture and organisation seem to be 2 different things.
Fast Company wrote a lengthy article on how software for the space shuttle was developed. Their development method was the epitome of the waterfall method. Article is called "they write the right stuff" and is highly recommendable, even if it is so old that the shuttle was still flying.
It wasn't always done that way though, look at how SpaceX write software for the most successful rockets every - it is exactly how I describe things on this channel, full TDD, CI, Trunk based development. The Flight control systems for the Mercury missions was also a VERY early version of TDD.
I worked where we had this as a three month process. The bureaucratic overhead was absolutely insane. The devs were frustrated because new information would make the plan obsolete. One scrum master even said he would be reluctant to allow us to add tickets after the plan was set. Some fool in management tried to neutralize everyones frustrations by saying that it's "Scaled Agile". Oh ok, I guess it's ok then.
One thing that will keep making waterfall come back is hardware design. Rework is substantially more expensive if you're trying to redesign a pickup into a sporty little convertible, and before you commit to expensive prototypes, you need to make that viable design space as well defined as possible. Hardware designers often dip their toes into the software for prototypes, operating in a mostly waterfall style. Then, they get brought into software teams as they "do software". But they don't do agile, they're trained and experienced in mostly waterfall, on short 1-2 month "software" jobs.
Even software projects don't work if you don't have some forward planning beyond the next few weeks. For the same reason, that you can't easily rework your system if you've made architectural mistakes.
I never make mistakes anyway for sure bro.
Prponents of waterfall mostly refer to physical world. Well, I've got an example from software area: how are you going to do billing system for Tier-1 telecom (think Sprint or T-mobile) agile way? What your product increment would be?
Or banking systems, or train operation software, or a national healthcare record keeping system, or anything where it's necessary - or the paying customer believes it is necessary - to introduce it all in one go.
I really like your comparison with developing a new method for building a bridge.
Many wonder why Software is different from all other technical disciplines in how unpredictable it is. But in actual fact, it isn't different. It is just that people compare SW development with the factory-like production of standard products. Whereas SW development needs to be compared with product development.
Just look at the requirements for being a software developer. Most developers have either a Master or Bachelor degree, sometimes even a Doctorate. Like we see in teams that do product development. SW development has little use for people with limited education, people who could happily be employed in a factory.
Experimentation is good for a software making company start up idk just saying I am trying to streamline development in a new company I started with friend and we often face the problem of pricing and timelines for our clients . How do we solve this .
Today even HRs use "agile" in many corporations. All it is is just models and there is not a reason to be agile zealot. Sometimes you need more documentation for a project than it's required to complete next sprint. Integration and testing today has nothing to do with waterfall/agile. You do it or not. You can implement CI/CD and still work in waterfall. Also many projects does not care to be deployable in every moment. Separating your work by "sprints" does not prevent you to have previous documentation of features. Also "agile" systems, like scrum has different bureaucratic overhead, like ie. forced meetings, product owners/scrum masters, kanban. They are associated with agile and it's mostly bullshit.
I think it's really underappreciated how tools like Sketch and Figma force a waterfall process. They let designers create a deceptively complete design detached from any implementation details, and they're considered etched in stone by the time they get to developers, often literally since developers don't often have write access to them. On my current project we developers went through months of iteration with the project owner on where departure from the designs were necessary, only for the designer to come back and list every change as a bug that needed to be fixed.
The fun thing is that we always do those implementation steps, regardless of methodology. The only difference between the methodologies is how we collaborate around them. Incremental ways of working always makes more sense than exploratory ways of working if you are working with planned development. The problem with incremental work is that when done incorrectly, it leads to silos between the different steps. This is the same for Agile ways of working that when done incorrectly it becomes chaotic ad-hoc prone poop.
The trick is not to discard incremental ways of working, or experts, and try to use a loose iterative approach with generalists. It is to shorten the steps in the incremental steps, make sure communication and collaboration exists, and of course to allow whatever we do to move freely between the steps when needed.
If you want to do something fun, then take any methodology you currently think is better and break it up in what activities you do and then compare the incremental methodology if it was done in the same time frame. Waterfall is always perceived as slow and painful, but if you take waterfall and place it in a 3-week increment...well, it looks a lot different then :)
That's also actually how waterfall normally worked. There was of course the longer term plan, but it was adjusted constantly.
Thanks for sharing
I'm on the waterfall side of the argument, I think the bridge building metaphor is apt. Imagine a world where you don't plan anything, start building at a random side of a river because someone that didn't think too much about it said you had to, then it falls on you to do all the work to think about how to actually accomplish this, taking measurements, running logistics and then you actually set out to build it, and you get the first 10 feet done and they are brilliant. Then you have the same dope from before tell you 'that actually, he doesn't like the bridge starting there and wants you to move it a block up from where it is'.
Agile (and all the others too) really excel in business environments where the business owners (the money) have no clue what they are doing, and have highly opinionated about that which they don't understand... that gives programmers the wiggle room to try and accommodate frequent and dumb changes at the cost of strict adherence to solid (which also allows for many devs to develop in tandem) and the overhead of the agile process and constant meetings. And further, scrum is great giving those same business owners the 'feeling of being involved' by letting the play around with points all day - mainly as a distraction from the obligatory sideline coaching about things taking too long and other greatest hits.
That said, that's just a way to work WITH businesses... that's not an ideal way to WORK. period.
If it was your bridge that you were building, you might want to have a think about it... what would work, how to make it work, and what it would take to make it work... then once all the figuring is done ON PAPER and all the permits are paid up.... then you have a plan and you can execute on it QUICKLY. No need for constant course corrections, no need to sacrifice stability of the bridge because half way through it some dope told you to do it completely differently now for no good reason... there's no technical debt... you just plan stuff and you do the stuff you plan.
IN THE EVENT THERE IS UNSTABLE GROUND UNDER WHERE THE BRIDGE WOULD BE BUILT, then one of two things happened: something you could not control changed, or you didn't plan well enough. The result is the absolute same (and the same with agile): HAVE A THINK ON WHAT TO DO ABOUT IT... make a plan, and execute on it.
The older I get, the less unforeseen unstable ground I 'overlook', and I think with enough experience that typically isn't a real problem.
It's just a rehash of the old but true adage: failing to plan is planning to fail.
I think businesses get a pass on that because they can fail as much as they want as long as they cover payroll and especially if they are going to be super critical while bikeshedding the crap out of everything... they get what they pay for, and if they want to pay a premium for 'not wanting to plan stuff', then I'm happy to take their money. But when it's my money on the line, I generally would be much happier with a skeleton crew that has a really well thought out plan, that can just get it done and get it done well the first time.
Ironically the more the organisation explicitly talks about agile (and in particular the very enterprisey implementations like Scrum) and methodologies in general, the less agile it is. I've been part of tiny teams (quite a few consisting only of me, or a designer and me) and large teams; and the smaller ones are usually always more agile no matter what words the project managers use; and the larger ones is slow waterfall called Scrum or something. I've even seen one team devolve from a relatively agile team (as agile as it's possible to be inside a huge organisation that otherwise use waterfall-scrum) to a much slower and less successful team once they started including more of the silly scrum rituals like "supersprint".
The best teams are small, ideally less than 5 people, one or two designers, one or two programmers (preferrably one that is good at and like user interface programming and one that likes and is good at data structures and data processing and other backend stuff, that way they can cooperate without almost no chance of accidentally working on the very same thing even without having to constantly sync what they are planning to do); and if this is not a hobby project but part of an organisation: some manager type whose job is mainly to filter requests from the rest of the organisation to give the team room to work uninterrupted most of the time.
Honestly, looking back to 1989, I have never seen the waterfall method in action-only in textbooks.
One thjng I still see is the reliance on estimates. It only works IMO for very small changes (8-24 hours).
Beyond that it’s just a WAG. We just come up with a number then triple it. Even then it’s always wrong because the “product manager” violates his/her policy by endless new and growing requirements.
Of course I know this is a useless rant right? Everyone here experiences the exact same thing 😊
Not saying waterfall is good, but with waterfall it did seem like requirements were clearer and open issues were properly managed. With Agile requirements are often unclear and open issues are kicked down the road and never seem to be resolved.
The slow/no feedback of waterfall was THE major downfall.
There is continuous feedback in real waterfall.
waterfall is fine for non commercial small team environments. the reason for agile and even solid is being able to fold in new developers and have old developers leave without too much trouble and concurrently have large amounts of programmers working at the same time, and scrum just allows the business owners have the ability to change their minds about what they want and not get pissy about it taking too long. I think uncle bob said it best (I'll try and find the quote in a sec) something about how businesses only know what they don't want and that's why scrum is a thing, it gives them some skin in the game by allowing them to just play with a bunch of cards to feel like they are connected even remotely to the process.
For smaller teams, you actually CAN plan out what you want and execute on it fast, and I personally find monolithic execution from concept to implementation to yield stronger, performant, intentional and vastly faster development times, BUT at the expense of maintainability (or more accurately, waffling on core features). That trade off makes sense, if you don't get cold feet every two weeks and want things done drastically and foundationally different, then actually knowing what you want means you can make really good choices early on that focuses on that specific implementation and you can get it done amazingly quick... because honestly, how many times has fundamental changes been highly sought after after the project was planned well? Programmers generally don't want to make sweeping changes, but you know who does? businesses! Because that's how business works... adapt to the market or die. The problem that nobody really bothered to ask in the digital age is: Should software be maintained forever (weekly or monthly patches continually, constantly introducing bugs and instability into the codebase, because foundationally it wasn't really thought out very well because it's changed a hundred times over the same amount of weeks), or should you have something that works well, then STARTING OVER FROM THE GROUND UP to make something else that works well that incorporates new and exciting features into it. I'm not even sure that you save any time or money 'maintaining' software, because the literal technical debt is 0 if you start over from scratch and you can get what you need much faster and much more intentionally. Less bugs, Less error prone, More performant, More readability, No technical debt, No dread.
What did they use on the Apollo?
As long as there are objectives and budgets, there will be waterfall, you can hide it, you can hate it, you can try to ignore it, pretend you're a modern dev, doing agile, or whatever you want, but waterfall will be there, always breathing on your neck. Waterfall is not even a methodology, it is just a very simplified description of how plan things, based on the most essential idea of dividing a problem into simpler parts to solve it. In the end if you have to finish preparing your camp for the attack of an enemy that is going to kill your tribe, it doesn't matter if you do agile, pray to god or hire mercenaries, if you are not ready when they come, you are dead. Every complex social process created operates within that simple inescapable truth.
But how do you protect yourself from clients that keep changing requirements if you don't settle to a single requirements specification?
Because most clients if we use other development models allows the clients to go outside the budget and you basically going to work for less than agreed and stresses and other things happen in such state.
What I do is have fixed daily meetings weekly (few times), and ad-hoc meetings per need.
If I have experimented something I offer the clients alternative where possible to improve the software, and then I am showcasing them the experiments. Sometimes this approach halves down the development time.
Also I breakdown the project into: prototype, development version and deployment version for each stack type like frontent, backend, other services; if I work in a team each stack is being developed in parallel, if I work alone I manage the stacks in milestones, alas, because if I implement the UI faster, the client will have tendencies to rapidly change requirements outside budget and I am all alone nobody to aid me.
The higher ups are currently writing the BRS for the replacement for the application we are maintaining. Unfortunately, we are still constantly adding functionality to the application as the business and products we sell evolve. I dont know how they are ever going to finalize the BRS to get to the next phase without it instantly becoming obsolete.
In a meeting I mentioned having begun to code a change for a project. My supervisor said that I should have completed the design before starting to code. My response was, "But that's how I find out whether my design is any good."
Managers who plan in the waterfall paradigm are also notoriously resistant to refactoring code. In the waterfall paradigm, the entire application must be rewritten and tested before any of the modified code can be deployed, and so this creates the illusion of a massive undertaking with enormous costs. And when they can be persuaded to approve the rewrite, or are ordered to do so from above, they insist on making it a big project, handled by a separate team, which is forever playing catch-up with the team that is making improvements to the application.
And waterfall makes maintenance development more difficult and expensive, because a bad design decision can never be fixed, because, again, nothing can move forward until everything is ready to move forward. So developers struggle for years with an application with major design flaws, because fixing the bad design is always deemed too risky.
Its popular because Ford's idea of an assembly line to produce products took over as a business model. The idea that everything could be produced as a linear progression.
I agree with this, but it’s not clear how formal methods fit into it. I guess it doesn’t matter if your requirement is informal or formal, or if the test is formal proof of correctness or unit testing, small iterated steps are the main issue. So you can still get to a formally proven correct design against formal requirements, but it never starts with a full set of formal requirements. Is this your thinking ee safety critical systems in an agile process?
Yes, the key here is to work iteratively in small steps, evolutionary design, formal methods, if they fit the problem, but they won't work either unless you take the small steps.
thanks for the video!
Spooky timing. Just last week I put together a presentation on Royce's paper, and made almost exactly the same points. Even the quotes match. There must be another side to this, that explains why waterfall is so prevalent in the face of zero supporting evidence.
Personally, I think that our measurement systems grew up in agricultural communities, measuring how well everyone is harvesting wheat. So our instinct is to add up everyone's effort in isolation. And from that, treat each step in a process as independent also.
I'm thinking of the McKinsey article on How to Measure Developer Productivity. (Shudder)
Thanks for the video =)
I kind of wish I could just sit down all of the upper management at my work and make them watch these videos.
Never knew about this paper. Holy crap ! Gotta read it
Does waterfall work in introductory programming courses? After all, the tasks in these courses do not change, and the programs are very simple.
At that point waterfall stops to hold any meaning. Such a program is like a single task in a sprint backlog in size
To add to the previous response: if we're talking about larger, more complex student projects, waterfall in my experience always leads to lower quality results than an agile approach.
@@Arhnuld If you are forced to make a toy waterfall project, you will learn that real projects don't work with waterfall.
But Agile is Waterfall, just on a small scale. While in waterfall a "design, specification, implementation, test" cycle can be a year or even more. In an agile development process this cycle time is one sprint or one week or even one day, or even less, but the steps are there.
Only when done badly. In th best file teams that I have worked on all of the stages are happening all of the time, mostly concurrently. For example, even on teams where we had external QA folk, they would be doing manual testing of a feature while it was being built. These are VERY different approaches. In agile there is no point, other than when the work is finished, where we aren't willing, and happy to go back and change things, anything. Any team that complains otherwise, isn;t really agile yet!
Is SAFe waterfall in disguise?
I thought SAFe was agile but for business as a whole.
Software engineers being software engineers add a layer of abstraction where every waterfall step contains hidden agile cycles, so those who think waterfall works have clever engineers saving their arse.
No, rather it is because waterfall actually calls for regular feedback.
There is a very simple way to solve this: Get rid of waterfall corporate leadership. We now have a perverse culture where the top decisionmakers and shareholders are working on a waterfall model and then try to integrate to "agile wow" in the development layer. That means that everyone from scrum master and higher, will be supporting a waterfall based hierarchy, supplemented with agile tools instead of all permeating agile wow and thinking process. The higher ups want to know when something is ready, how much resources to ok for it etc. To summarise, as long as you have suits and pencil necks running the show, real agile will be a pipedream.
What's the deliberate small controlled step towards building your chimney the builders won't estimate for?
Are you going to let them take the roof off, realise it's going to cost a million pounds, say no, and let them just leave the roof off? Or maybe commit to it whatever the cost is going to be, and end up with a million pound bill you can't pay?
If not, why do you expect customers who want software to take the same risk?
This is not a defence of waterfall (though in reality, waterfall exists only as a straw man for overenthusiastic proponents of Agile to deride). It's an observation that Agile is suitable for some problems, and not others... and that customers often won't buy into the Agile approach even if it would work best (for good reason, from their point of view).
That is not how you sensibly manage risk though, there are risks that you can't estimate for, so you progress in small steps, and evaluate if you want to continue after each small step. We will pay of scaffolding to fix the things that are estimable, and while it is there, the builders will explore and investigate the "problem chimney" in more depth and then we will decide what to do.
In financing terms this is EXACTLY the same funding model as a software startup. Invest some seed capital, try stuff out until you learn enough to know whether or not to continue.
This is how we deal with uncertainty in the real world, it is in the fake work of perfect estimates and fixed price contracts where we don't.
Waterfall is not a straw man, it is the reality of most software projects that I have seen. If you plan all of the features before you start work on the code, that is waterfall development. If you test when you think the work is finished, that is waterfall. If your PO or UI team throws requirements into the Dev team without working alongside them on those requirements, if your dev team hand over the system to a QA team to do the testing and to and provide written instructions to the Ops team about how to deploy the code. These are all extremely common activities, and are all waterfall baed approaches.
People might do 'linear processes' thats because in this universe time goes forwards, but nobody does 'waterfall', so stop peddling the idea. You are basically saying that some people when a phase of something has been completed have the rules that they MUST NOT GO BACK. nobody does this, because even managers have common sense.
Sooo true. Let‘s do better.
commenest.
had to rewind and verify.
thanks, dave.
😆
It won't die if the project management / company setup doesn't change as well.
You are doomed if you want to do agile/scrum/kanban/etc... development in a waterfall project/company setup.
You will only waste money and your sanity.
I kinda disagree that waterfall is always the worst option. Waterfall can done adequotely well (most systems existing today are probably done that way). You can and do learn and adjust direction through steering group decisions. The best part of waterfall is that it's quite well understood in organizations and executed quite well. And I've never seen a big organization do Agile well. Usually it's "waterfall with sprints" (because investment decisions still done by high level boards). It is correct to criticize shortcomings of waterfall but one should not assume things will get better by just switching to something else, it's not the categorically worst option.
PS. Agile is a process work methodology, developing a product indefinetely. This is roughly true for product companies, but not enterprise.
It's good to vocalise this but we're preaching to the converted. The problem starts at the conversation over budget. Too many consultancies offer fixed price deals with agreed scope and dead lines lines. Then it's over to the poor souls to deliver it.
This is the only problem we need to solve. The rest will waterfall into place.
After looking to the amazing Microsoft Teams as example, I can assure that Agile is also bad.
There are no guarantees, only better an worse choices. Waterfall is always a worse choice.
@@ContinuousDelivery I do understand that waterfall is prone to problems, but looking into Agile also shows it's deep problems, on my last 20 years I notice that the lack of disconnect with the userbase is much more harmful and Microsoft is the king "no-care-for-user" example. Aka the awful quality of Teams.
Marvin! 😁
In software development, probably. Anywhere else, no fucking way.
"If we aren't doing something new, we're doing it wrong"
This isn't true much of the time. Many good pieces of software are built with 95% existing well understood pieces and patterns. You still have to write the code because those pieces haven't been arranged exactly in that manner previously.
Example. CRUD web apps. I've experienced others in the past, permutations on the same styles of system where the company produces variations on requirements and on different kinds of hardware.
When doing it right, with an experienced team, the length of time can be predicted and delivered on time in an understood budget. If your organization can't hang onto people long term, or you go too far out of pocket in system scope, it will kill your predictability.
First time I've heard the game of telephone referred to as Chinese whispers
Yeah, make a military aircraft only with TDD and document-less Agile, it will solve everything. Waterfall of today are communicating stations of interdependent development-processes where the software is simply too large and integrated with huge electronic systems. It is by far not as effective as XP and Scrum, but on the other hand it works for military aircraft systems.
Or try to deliver airport firefighter truck starting from bicycle with 2gallon bucket for water.
Tricky ones…being at war and putting out a fire are all time critical problems to solve.
If you suddenly found yourself in those situations and you had to build something from scratch to help your cause…you’d be getting those things to bare minimum spec and getting them into action ASAP and then refine from there. No good waiting for well planned fully featured aircraft or fire engines. You’d lose your war and your house would be ashes.
It’s obvious I know, but In the business world time is money. Things need to be generating money and feedback asap. Waterfall just doesn’t cut it.
I've been watching a few of these videos, and - with the best intentions - I'll say this all feels very dated. My advice for people here is to spend a bit of time looking into how the software power houses of our generation have done it. Google, Amazon, Apple, Netflix. Most of us aren't building software for consultancies or agencies, where software is 'exploratory' and customers don't know what they want. Not a single system at Amazon or Google didn't go through some form of design phase. It would be such a monumental waste of resource to not spend a few days thinking a system that will then take weeks and months to build - reviewing it with other (and more experienced) software engineers who can see around corners and help steer clear of common issues. For sure, systems evolve over time, but each of these evolutionary steps is thought through to some extent (and often very large extents).
It's probably still around because it isn't demonstrably ineffective. Real waterfall works well.
You might have compared and contrasted Boeing/NASA with SpaceX in terms of productivity and safety...
I disagree. In the past 20 years of IT I've come across waterfall just once as agile was (is?) apparently the universal answer to everything. Good luck doing agile in a project with 90% legacy systems and all the original users, business owners and developers pensioned off for at least a decennium. Good luck doing agile in an embedded setting. Agile has it's place but so has waterfall.
Agile works fine in both of your counter examples, Tesla is a full-blown Continuous Delivery company for example, including for the more than 100 ECUs in each car. Read "Large scale agile development by Gary Gruver which describes how they transformed the HP LaserJet codebase and approach.
Bullshit, waterfall is just fine when the requirement are FIXED, as it's good for constructing a skyscraper, you don't revise the foundation when you are on the 15th floor. There is software case that are FIX. I don't do that now, but when I was writing credit card reader, I had to follow Mastercard/Visa requirement to the letter.
Are there any positive videos by this sub anymore? Always so dire, so negative, so sloggingly dull. I look at the video thumbnail and title, and it turns me off. It's almost every video. If I were a young, aspiring software engineer, this sub alone would make me think twice about my career choice.
I don't get your obsession with waterfall. I'm now 30 years in the business and I never came across a waterfall project that did the strict waterfall where everything only flows donw and it is impossible or extremely hard to do changes inbetween. I think in my part of the industry the strict waterfall died before I even began my career. Maybe country and coulture also plays a role on how strict you live it. You can absolutely deliver good software that meets the expectations of business.. I agree that there are more efficient wasy to build software but I disagree that you are doomed when the boundaries of your software projekt require you to work in a flexible-waterfall model. If a software project fails, it's because of people, not because of the process, that is my experience in 30 years of making software.
Ever worked in a company where the requirements were done first, before development started? and the testing was done after the coding was finished? Then that was a waterfall.
Most companies that I consult in have fixed deadlines for their projects because all the planning was done before the coding started. Still a waterfall even when they call it Scrum!
The thing that waterfall has going for it is the plan. And plans are useful to salespeople because it tells them when they can start billing customers. In the eyes of the shareholders, salespeople are the only ones that earn profit at a software company. That is why waterfall persists in the industry. Capitalism for the not-win.
Towards the end your argument has some weakness for people who expect waterfall to work. They will ask you the following: "What I'm asking for has surely been done before, more or less. Why is everything brandnew, don't have standards how to solve everyday problems? I don't need new, I want the same as [points to some existing software]." I'm 100% with you regarding waterfall. But I'd be interested in hearing what you answer to questions like above.
What I'm hinting at: The question if indeed there are not enough standardized solutions to problems is one we have to ask ourselves. I don't think the answer is entirely simple.
I remember an earlier video expanding the point that, even if some specific problem has been solved before, it most likely had
- Different developers/team
- Different time/place
- Different resources/stakes
- Differen *context*
I'd be ready to tell a waterfall believer that due to our human way to be able to describe problems only vaguely, every single problem is unique due to the ever changing context. (...I feel like I've argued something like this to my boss.)
Most important for me is if no one on your team has done it before and the sauce is secret… all you know is that it is possible
Almost every large corporate company I've worked for in the last few years, still use this approach. Drives me crazy.
I'm sorry but at 3:43 you have not yet fully described Waterfall nor have you explained any problems with it and you're already pushing your courses. Please reformat for next time where you demonstrate why your course is worth anything (by explaining why it's time for waterfall to die) before saying you have a course that has all the answers and I should go see it now.
Failure is innovation's best friend. If you cut the failure, you cut the innovation.
Waterfall was excellent for when all the requirements for a system were known from the beginning and were completely defined. All of those projects were completed in the late 20th century. Now it's obsolete.
That was also not the case back then. Or what projects are you referring to?
No, when using waterfall we were checking regularly and adjusting.
Waterfall works well with some projects. People with experience knows nothing is black/white. Oh well,time to unsubscribe
“Chinese whispers” A racist phrase. And the channel asks us to be “respectful”. Hypocrite.
How will you build an aircraft control system using agile?