UML comes out of a different culture of development, that of the Rational software crew. They had their own much more heavyweight process than the Agile folks: RUP, or the Rational Unified Process: https://en.wikipedia.org/wiki/Rational_Software#UML_and_RUP

There was a little overlap; in particular, Martin Fowler wrote an intentionally thin book called "UML Distilled". But the UML world was generally heavy on both up-front architecture and formal, heavyweight design process. The Agile world at the time was energetically opposed to that, thinking that the main value of UML was in having a consistent language for us to all sketch on whiteboards together.

Too bad people didn't bother reading the Unified Process book, which clearly specifies the use of iterative and incremental development and the creation of just enough UML diagrams to communicate and document a system design. It even argues that working software should be used to describe an architecture in the Elaboration phase rather than a 10000 words document. It can actually be considered as one of the first agile methodologies. RUP and other flavors of UP just added tools and guides aimed to facilitate the implementation of UP, but it was misunderstood that every template and section must be filled out instead of actually thinking what to use depending on the project. Unfortunately the whole thing was ultimately bastardized by the non-technical template zombies that thought software development is like building a skyscraper.

The CASE motivated tooling got in the way.

My go to joke: RationalRose is like an 800lb angry gorilla sitting between you and your work.

Alistair Cockburn did a great post mortem about that era.

Characterizing people as non-linear, first-order components in software development [1999] http://alistair.cockburn.us/Characterizing+people+as+non-lin...

During that time, I strongly preferred lo-fi paper prototyping for UI. And I'd scratch out UML diagrams. Worked fine for intra-team. But it just didn't fly with management. We had to make everything more formal and pretty.

Oh well.

It’s funny looking back at what we used to call software development methodologies. Booch and Rumbaugh were primarily focused on modeling. Any talk of process meant a dynamic description of the program.

Jacobson was a little more method focused. You can see how his introduction of use cases started the idea of talking to your customer about what they need.

I remember seeing Rose and thinking this will make a huge improvement only to be repeatedly confused and frustrated that it seemed to make everything take longer.

Finally! I get share my Booch story:

At OOPLSA 98, Booch convened the first society of software architects (or some such).

Having read all his writing (ditto Yourdon, Brooks, Rumblaugh, etc), I was super excited.

During the Q&A I finally got to ask “What is software architecture?”

Booch replied “Software architecture is what software architects do.”

Bubble popped.

I gave up seeking the council of the priesthood and blazed my own path.

Wow. In some ways, that's the worst possible answer. In my view, software architecture is what every developer contributes to, which means we have to be thoughtful about how we collaborate on it.

Every time I see a shop with designated Software Architects who hog the architecture work, it's a fucking mess. Because then Software Architects don't get rewarded in their careers for making software. They get rewarded for writing white papers and coming up with "brilliant" architectures and impressing executives who know less than them about technology. Which is mostly inversely correlated with actually making it easier for developers to get real work done.

I totally agree that it was taken over by zombies, and also agree it had some good ideas.

But I don't think it was quite as incremental and iterative as all that. One, it was more a "process framework" than an actual process, so iteration length could be whatever the grand poobahs wanted. They were entirely fine with multi-month iterations. Two, as the "RUP hump" chart shows, it was always pretty waterfall-ish. And three, whatever the words in the book, the RUP adopters were generally large-company shops, and he who pays the piper calls the tune.

I definitely remember the RUP people coming to the early Agile conferences and being very suspicious of our wild ways. So I'm not sure even its originators would have called it an Agile process.

Thanks for your misc comments in this thread.

This particular comment, the "UML Distilled" reminder, triggered a few hindsight notions.

Much like XML and J2EE tainted Java, I'm now having trouble distinguishing between UML and OOAD. Though I preferred Fusion to UML, I'm now wondering if any OOAD based methodology had a chance.

"...thinking that the main value of UML was in having a consistent language..."

Guilty. For a long time, I very much wanted executable models, roundtripping. I got over it. Now I place more weight on concision, DSLs.

But here's the new (to me) notion:

Maybe UMLs (and RUP) greatest benefit was the idea of having a list of questions to ask. You know, a methodology.

Writing this out, it sounds stupid, so please forgive my stumbling.

But two things stand out from the 90s, which I'm missing terribly today.

I miss Joel Spolsky's 12 steps to better code. What's today's equivalent? I haven't found it.

I miss strategy, strategic thinking. With all this agile stuff, I have no idea what anyone's talking about. Yes, UML & RUP were terrible. But at least we were trying to bring order to chaos. With agile, it feels like we forfeited, that we should just accept the chaos.

I don't think the gist of successfully developing software has changed that much since the early 90s, at least in consultancy: You work in iterations where the team and client develop, refine and prioritize the features of the system until the system is good enough to be considered finished. There is an initial vision and strategy that needs to be developed in the first iterations. The UP implementations describe ways on how to do this, though the agile community has come up with more creative frameworks: design sprint, product vision box, customer service map, etc. The strategy is reviewed each iteration with the re-priorization of the features. For this it's important to have revisions on the documents created on the first iterations.

The challenge as I see it is that clients usually don't buy into this and they believe that developing software is like making sandwiches or turning buttons on and off when in fact is a discovery process of abstract things. They then demand a fixed budget, fixed time and fixed milestones for a fixed scope ("You are the expert, you should know how much time this takes."). To sell the project the salespeople from software companies deliver this, those who don't are considered incompetent. In this conditions agile methodologies are prone to fail but not for the methodology, but because most of the time those sold promises are done with incomplete information or tailored to be optimistic to sell the project. Metrics from agile methodologies show from the beginning that the project won't meet the expectations and then chaos ensues: they stop collaborating with the client to hide the reality of the project, "managers" pressure the team to do more in each iteration, they stop doing the disciplines altogether, iteration and daily reviews are treated as long meetings where people commiting errors are shamed and scolded and frictions start to emerge between all persons involved. This is where I believe the whole notion of "agile sucks" comes from.

Much agreement. Been there, been done like that.

What’s more waterfall than the sales team throwing a poorly baked contract over the wall to the dev team and telling them “make it work”?

I think "accepting the chaos" is fair. We've accepted it because it works - or rather, Scrum is about doing the minimum amount of "bringing order" necessary to move forward, and no more. Which makes sense - people like the idea of tidiness, but you shouldn't put more effort into organisation than you're getting out of it.