I understand you're joking about Agile, but the previous holy path was waterfall, which was a hideously expensive way to get to failure.

Except that Waterfall was never really advocated: https://davesquared.net/2008/01/contentious-myth-of-waterfal...

It was conceived as a straw man which was being dissed so vigorously that people started believing it was real.

It was advocated, it was not meant to be advocated, but it was.

And Agile has it's fault and it has become filled with consultants, buzzwords and all kinds of things but early days when I built an internal system used in factories for a large company. The old ways of building and documenting software there was pretty much waterfall and there was a lot of middle-management, reporting, architects, documenting etc.

I was a part of a pretty young team + one offshore team in India (that was not great but not bad either) and we had a great boss who fought for us when we wanted to develop using pretty standard Scrum instead and we had a great product owner who immediately got what we were after and had great domain knowledge.

That project went sooo much better than previous ones and even if there were a lot of fighting and escalations in the beginning the whole concept of "Just call into our demo's we have every three weeks and see what we are developing and then give feedback" was like a revelation for some would be users of the system or owners of processes we implemented.

> Except that Waterfall was never really advocated

I've heard countless people advocate for waterfall. I was formally taught waterfall years ago. It was how many people approached development for a long time, and how some people still approach it today.

Here's just one concrete example I could find in seconds - an article from 2006 advocating for its benefits https://www.techrepublic.com/article/understanding-the-pros-....

Still being taught in school; my CS program in Rome had it as one of the "software engineering methods" chapters, it was part of the finals curriculum and everything.

I thought that was true, but I had a vendor just last week state out loud, “We use a waterfall methodology.” It is alive and well, even if the smartest thinkers in the field never subscribed to it literally.

Oh yes it was advocated. Maybe the actual term "waterfall" was invented in order to criticize the methodology, but it was describing and criticizing a real, commonly used methodology.

Waterfall is really how you manage other large construction projects like building a house or a bridge. So it is not completely crazy to think you can also develop software that way. It took many failures to realize software demanded a different approach.

Waterfall represents the default approach to managing chaos. One or two programmers with a single customer have an easy time getting a job done. When the budget gets into the millions, the project fails from having too many chefs in the kitchen, etc. So the gut reaction is to overload the front end with process. Finish requirements first, create a high level design, split it up into components that can be implemented, create a detailed design for each component, implement the design, integrate, test. I heard a ton of times as a consultant from average people, "we needed to specify more of this up front and create better designs ahead of implementation."

It doesn't work this way because software development is the process of figuring out the actual requirements and a good design. You don't have to follow an agile methodology to acheive a successful project, but you do have to have feedback loops that reduce the risk of wasted effort.

In the engineering analogy, I like to tell people that the compiler is the builder. All coding is an exercise in architecture and engineering that produces a detailed design (the code).

I've seen too many projects where the specification guys were basically writing the whole program suite in English and then expecting it to just translate smoothly to computer code.

Then their beautiful 5 year late 2000 page specification slams head first into the realities of computers and the project immediately becomes quagmired. It's basically the Soviet model of computer programming, where you try to make all of the design decisions from the top but the people at the top don't have the whole picture and can't make good decisions and the scope is way too large for mere mortals to learn enough to make said decisions.

> It doesn't work this way because software development is the process of figuring out the actual requirements and a good design.

In my experience very few people truly understands why engineering is something expensive at its core, and it's usually this particular lack of understanding that ironically ends up making making things even more expensive and produces worse value-for-money, and so the vicious cycle continues.

> It was conceived as a straw man which was being dissed so vigorously that people started believing it was real.

So much this.

I've been in the industry for about 30 years, and I've never once seen a place that used a methodology that could be called "waterfall" as described by many agile proponents.

I've been at it just as long. I've been certified in a multi-week course to work as a developer (around 2000-2002) in a waterfall system that included a VCS and some issue tracking I believe.

It was always a "no true scotsman" issue. If it didn't work, it was because we didn't adhere to it and didn't gather the requirements completely enough. So, sure, waterfall never existed in the sense that it never worked out, but it certainly existed in the sense that it was pursued to the tune of countless man hours and countless dollars.

I started out in defense and it was standard practice there, especially in regards to contract management. I had to take a formal training class in the process.

It was also the only process I learned in college ('94) and was strongly advocated in my classes.

Most attacks from the agile community probably are coming from a place of never having actually seen or practiced the real thing however. For example it does flow backwards at times, it's not the nonsense straight line process that gets straw-manned sometimes.

> Most attacks from the agile community probably are coming from a place of never having actually seen or practiced the real thing

This is rather my point. In "waterfall" shops I've worked at, the way it has never worked is that the application is completely designed up front, then implemented. The reality is that there has always been iteration involved, and there has always been refining and modification of design, and etc.

The only thing (aside from "ceremonies") I see agile bringing that didn't exist in my experiences with "waterfall" is the notion of bringing the customer in as a constant part of the development process -- which is a welcome addition.

The rest of Agile that I see can be thought of as refinements to waterfall, not as something entirely different.

I worked in a place that called it "spiral". Because they did the phases of waterfall over and over again, until finally drilling down through the roof of Hell.

Yes, it was horrible.

Yes, it got worse when they added the mandatory omnibus all-hands standup scheduled for 8:45-9:00 every morning, that always somehow lasted until at least 9:30, because everyone was continually justifying their existence.

And it was redundant with the spreadsheets that recorded the time spent on any particular task, down to the second.

waterfall wasn't advocated because there hadn't been a movement for alternatives yet, it was just the default, like the iphone 2G, nobody called it iphone 2g when it came out, but in the context of newer models that's how we differentiate it

Waterfall on a per-feature basis is how we did things about a decade ago. It may be rare, but it's not a strawman.

thank you. I try not to post just to vehemently agree, but this is a pretty egregious case of revisionism.

we were just so blind back then that we thought we could predict the future. When faced with direct evidence that things weren't going according to plan, or that the commercial landscape had changed, we stubbornly went back to our Gantt charts and insisted that it just couldn't be so.

so we just never got anything done..until some genius decided we had to meet every morning and schedule everything in 2 week intervals.

The problem is neither agile nor waterfall.

The problem is applying a methodology because it is the current fad.

Management should be adapted to the conditions: the scale of the project, the nature and availability of the customer, the personalities and roles of the team members,... Sometimes, the best results looks like waterfall, sometimes it looks like agile, sometimes it looks like there is no methodology at all. When things "just work" you don't realize there is a process, that's the sign of a manager doing a good job. The worst case is usually when a manager follows a methodology "by the book", except for the parts that don't fit or are "too expensive". Not realizing that pieces go together and changing one will affect the others.

The same could be said of design patterns in programming. They are good to know, but they are just guidelines. Using a design pattern for the sake of it usually leads to terrible, often bloated code.

Most of what we call agile today is processes for the sake of processes and waterfalls in disguise.

Yes! I remember when I was in University (1990s) how they taught us about how waterfall was bad and iterative development processes were just starting (XP was still not invented).

Iterative development processes where beautiful, and had great ideas. The problem with today's "Agile" methods as implemented in the industry is that they usually only do the first iteration and stop there, making it practically mainly waterfall.

The best situation I had was two in an office (it was an academic institution just being started and there was plently of space at the time).

One other person means company if you both want to chat, and generally silence when you need to get stuff done.

As the institute grew I think they squeezed 5 people into tHe same office. Which meant random informal meetings appearing frequently. My productivity plumeted.

Just to get the alternate view out there too: I had an office once with a door that closed. As an extrovert it was awful. I felt lonely all day. The only way to get any human contact besides email and text was to leave and go walk the halls or find some common area. I ended up pretty much never using it and instead worked from the break room. From time to time they’d give me an officemate to share the office, but they were all extroverts too, so of course were never around.

Different strokes for different folks. I love open offices and wouldn’t go back to closed ones if given the choice. I also have difficulty WFH for the same reasons.

More employers should offer more choices, as everyone is different and what suits one worker might be awful for another.

As a thought experiment, imagine that a company offered each employee a choice - a private work area or a cacophonous open bullpen. You and I both know that 90% of the employees would choose the private work areas, and all five of you “extroverts” would move into the open area. What we have is an extremely tiny minority forcing their preferences on everybody else, not caring much about the negative impact. Of course, we also all know that open offices are about surveillance and saving a few dollars (on paper) and not about collaboration anyway.

> Just to get the alternate view out there too

This always comes up in these discussions. Extroverts say they prefer the open office format because they can talk to others. That's nice and all, but shouldn't you be working rather than satisfying your desire to talk to others? (The same goes for workers not in an open office not playing on HN all day.)

It's not necessarily just to idly chat with other people, but has more to do with where you get your energy. I find I'm most productive and energized when surrounded by other people. Conversation is a part of it, and the ability to collaborate on the fly is great. If I'm heads down on something it's fine to be isolated every so often, but if it's for more than a few days my energy level is sunk and my productivity actually decreases dramatically.

I get it and I totally appreciate my extrovert colleagues. I think the ability to have both is good. Sometimes I do like to work with others.

It's just that often open-plan offices are an all-or-nothing affair. It's a weird way to construct a space for people to work and collaborate given how different we all are.

These conversations always seem to be extremely one-sided, and it's frustrating. I wouldn't even classify myself as an extrovert; it's a continuum and people fall all over the place. Ultimately, though, an ideal office needs to cater to everyone.

Some of my favorite offices have been ones that have the typical open office structure, but also lots and lots of "hiding places" and different areas. I'm super ADHD and changes in scenery were helpful, and being able to adapt my environment to the task at hand, or even give people having impromptu conversations a refuge so the desk areas weren't noisy.

The startup I work at currently encourages everyone to work from home tuesdays and thursdays. It makes for a great mix; when I'm in the office I can engage with my coworkers, catch up, or have those deeper discussions that inevitably come up face-to-face. Work that requires intense concentration can be batched for those days, or I can opt to take additional time at home if necessary.

Workplaces themselves are so egregiously one-sides in the other direction that these discussions have to be one-sided, because by definition it’s the huge, huge majority of people who find the existing actually workplaces to be one-sidesly disergonomic.

You’re worried that the discussion is one-sides. I’m worried that physical workplaces are one-sided, today, for real, to such an extent that it’s deeply cognitively harmful to many people.

I mean, clearly it's not working for a large chunk of people, otherwise this article wouldn't keep appearing on the front page of HN regularly.

What I'm saying is there's a way to meet in the middle.

Is there? About the only thing I've seen suggested that might work is to offer everyone a choice but as another poster commented, the vast majority would choose an office over an open floorplan.

Group rooms, shared offices, etc., would be an acceptable compromise for some but far from all. These middle solutions still have the negatives of the open floorplan just on a smaller scale. If you prefer cola and I prefer water, watered down cola isn't going to make either of us very happy.

Socializing is great, but maybe you can find an outlet for that outside of work?

What I'm saying is that it goes beyond socializing; if I'm cut off from other people and heads-down all the time I get depressed and it's counter-productive. I socialize plenty outside of work, but I am happiest and most productive at when I can feed off other people's energy.

It's a balance, though, and overstimulation is still an issue, and I need periods of quiet and concentration like anyone else.

The people walking in and out, rinsing out their coffee cups, overhearing discussions that are occasionally useful but usually not is the problem for those of us distracted and stressed out by open-plan offices.

As far as preferences go, though, if you get even a small part of the external stimulus you want, it's already started wearing on us. Perhaps larger companies could try offering quiet floors with lots of barriers vs "social" open-plan floors.

That depends on what they are talking about.

Extroverts think out loud, so they need someone to talk with just to think. So long as the other person is an extrovert that is okay because they both work the same way.

Extroverts - because they talk and ask questions are often the first to know. If the company has decided some project isn't doing the introverts can waste a lot of time continuing on a canceled project. Also extroverts can sometimes discover a quick/easy need to fill - a 10 minute script at the right time can sometimes be more valuable than a years of effort an introvert puts into the main project.

If you have an office environment you should NEVER have an open office policy. The extroverts who like interaction/interruptions won't be in their office in the first place, while those who hate it need their door closed.

I'm an extreme extrovert, and I despise open plan offices, because my productivity doesn't involve the social interaction I enjoy so much. When I'm in the Zone, I have no such desires.

On the other hand, I favor pair programming. But even then, it should be done in two-person offices with a door, not in cacophanous cafeterias.

At one point I had an office that I shared with a couple other people. I had shelves, blackboards, and a couple people to talk to. Outside the office was common space. It was great!

Downside: the arrangement was likely quite expensive.