I used one of those tools at one point, Rational Rose.
It was possible to get it to generate code, as I recall it basically gave you stubs of classes and methods and you would then go and code the implementation of each method.
It seemed like it could save you some amount of effort at basic boilerplate stuff but at the cost of putting the same or more effort into the UML.
UML was the swan song of the classic waterfall SDLC gang. Agile and TDD came along and nobody looked back.
> We are tired of being told we're socialy awkward idiots who need to be manipulated to work... because none of the 10 managers on the project can do... Programming, Motherfucker.
Developers are better at self-organizing than people think. That is the real driving force in modern software. You can eliminate all the ceremonies of scrum and still have a functioning team. You can remove the scrum master and in some cases even the product manager and still have a functioning team.
Despite popular belief: developers CAN understand the product. In some cases developers can understand the product better than a product manager can. Also, developers can have a good approximation to what the customer wants, even without talking to the customer, by just looking at analytics data, log aggregations and bug reports.
The modern incarnation of agile gives too much power to product people and disempowers engineers, turning companies into tech debt mills. The original incarnation of agile empowered engineers and allowed them to collectively negotiate with the product manager.
Agreed. Original agile connected developers and customers through valuing sw features. Today's agile is whip-cracking with the value of features obscured from developers who waste customer time doing unjustifiable work. It's more of a social game than one that benefits customers, so it can not last forever.
Thanks. I think you've done a better work at describing the situation than I did.
The original agile manifesto emphasized collaboration with the customer. Scrum defined roles such as product manager and scrum master, and then the industry injected even more roles in between the customer and the developer...
Fast forward to 2021, we have "agile" developers that have never met a customer. So much for customer collaboration.
> Also, developers can have a good approximation to what the customer wants, even without talking to the customer,
Yoep, sure, maybe we even don't need clients. Just developers creating products for themselves. Or just coding for the sake of coding. I've seen that too mamy times. That's why we need product people.
The largest software companies in existence were born during a time when the role of product manager did not even exist.
Just like the largest corporations in existence became profitable and expansive before they hired MBAs.
Product managers and MBAs are the best examples of the Texas Sharpshooter cognitive fallacy. You shoot into a wall and then paint a target around it. Being successful at those roles is about painting targets around any successful initiative and claim it was your idea.
Powerpoint presentations are not reality, picking up the customer service phone, auditing the code, talking to internal and external users and keeping in touch with reality is.
I dunno I disagree—the fact is a lot of people just dive into coding and don’t spend much time with design.
There’s a ton of value in the idea of diagramming code and then generating sources. UML is a starting point but the journey is far from over.
The more appropriate idea is that you create documentation in the form of diagrams for free. Just like in TDD you get unit-tests for free.
Folks always talk about self-documenting code—and that’s great. But what about conveying a complex system to a new team of engineers? Diagrams are frankly priceless if done well.
Also, looking at something like Kubernetes where a declarative YAML file generates magic underneath is somewhat similar. A step beyond what we have would be nice diagramming capabilities over the YAML to auto generate the plumbing underneath.
Personally, I think future advances in development _will_ be done as higher level ideas—pictures worth a thousand lines of code—AI will do the rest.
> The more appropriate idea is that you create documentation in the form of diagrams for free.
The problem is the diagrams are hard to create and hard to update and usually don't remain synchronized to the code. If there was a good way to create documents from the code (perhaps with some annotations required), it could just be a Make target and boom, free(ish) documentation.
I’ve recently gotten reacquainted with Doxygen, and it allows you to embed PlantUML source right in your source code or Markdown files. Easy to write, easy to update, and stored as plaintext right in your source tree. I don’t love Doxygen, but it’s doing a great job at what I’m trying to do (document a complex C++ project)
I use PlantUML in org-mode as well! That's actually where I started, but found it much easier to recruit other people to write their own documentation (with sequence and state diagrams) by not requiring them to use Emacs :)
I feel like my ideal workflow would be a middleground between doing the design up front and just jumping into coding. Before you start coding I feel like you don't have much of an idea of what problems you will run into, resulting in diagrams based on the wrong assumptions. But with code it's easy to loose track of the high level structure of what you are writing. Writing code, then diagramming the high level structure, and then going back to fix the code seems like a good way to go.
Absolutely! That is similar to artists doing thumbnail sketches to figure out the composition; then once things are reasonably worked out, the chosen composition can be worked onto the final canvas; then the details follow.
That is a nice benefit of good development frameworks: how easy is it to explore new ideas? And frankly that’s why there’s an uptick in higher level languages.
Granted, but you can do the same and much more with different methods, and avoid fighting the frustrating, unreliable and time-consuming UML tools altogether.
I used RR at Uni in the early 2000s. It felt very clunky even then. It was also a pig to use - somewhere along the line it become known as Crashional Rose.
Yes. We had a joke that either RR wasn't properly software-engineered the way RR proponents demand, so they weren't even dogfooding. Or it was and the process clearly doesn't work, even for its proponents. Because obviously, RR was crap.
I had the same experience in 1999. I never understood how that software could be so bad. A student using something in a student manner shouldn't be able to crash the thing in multiple different ways. It would be like if I opened Blender as a newbie, hit a button somewhere, and clicked in the viewport and it hard-crashed. I'm sure it's possible to crash Blender, but for a newbie it ought to be harder than that!
And then for this to be held up as the example of how software engineering was going to be in the future is just icing on the cake.
I have many and sundry quibbles with various things I was taught in university ~20 years ago, but most of them I at least understand where they were coming from and some of them have simply been superceded, of course. But that software engineering course with Rational Rose has the distinction that, in hindsight, I don't think I agree with a single thing they taught.
The problem with tools that generate code is that they are often unidirectional. If there is no way to get code changes to propagate back to the visual model, the latter is likely to fall into disrepair pretty quickly.
It could be possible to do something interesting in this space, where UML can be used generate template code, and later on, another tool could extract UML from the code, compare it to the baseline, and flag any discrepancies. From there, you can either sign off on the discrepancies (and replace your hand-made UML with the extracted one) or fix your code. Bit of a kludge, but at least automatic verification is possible unlike documentation
If only it were that simple but the code is so expressive that you can't really create the UML as easily from it as the other way around. You just can do too much stuff in code that the UML generator would just not understand at all. Or you'd have to basically code in a very specific manner. Not fun. Of course since I last tried it they probably got better at it.
I even remember back in university you'd have to write your custom code _in_ the UML tools dialogs if you didn't want it to be overwritten next time you tried to generate code. Of course these were just simple text boxes. Horrible dev experience.
The trick is propagating "backwards" to the model feedback from tests, not changes, preserving the normal loop of receiving requirements, writing code (in this case the "model"), compiling it to something else (including generated code that fools would be tempted to modify) and running the program.
Honeywell "automatically generated" all of the flight code for the James Webb Space Telescope using Rational Rose in the early 2000s. They were still trying to fix the code when I was at NASA Goddard in the mid-2010s.
The difference I was trying to highlight is that UML (at least in my experience) was still very much focused on "big design up front" and production of design artifacts (vast numbers of diagrams) that agile and TDD approaches explicitly rejected.
I don't remember rapid iteration being a part of any UML-based methodology that I ever used. By the time the diagrams were complete enough to capture implementation details, they were too unwieldy. Did any UML tools support common refactorings, or would you have to manually change potentially dozens of affected diagrams?
Maybe I'm cynical, but it seems like these people are in a farcical cycle of repeatedly inventing some new master theory of programming only to find it's actually a disaster a few years later and then to switch to something apparently diametrically opposed.
Of course, they have a book on sale to explain the new idea...
How much time was wasted and how many projects were damaged by the bad idea of UML and design up-front that they were pushing as hard as they could less than two decades ago? How many developers are being stressed by endless manic sprinting and micro-managing processes under the name of Agile?
Maybe they should stop? Or apply some actual science? Some of this in-group call themselves scientists but all they do is pontificate. I'm not really sure many of them spend much time actually programming.
My impression as an undergrad learning UML was that it gave an architectural level view - so the effort would go in at a different level of thinking, not just in a different part of the process?
Yeah it turned into that before kinda dying. Now in the "real world" those tools are only used for diagrams that explain what's called a "slice" of the architecture, but no one really gives a whole architectural view of a system on UML. Not even for a simple component.
But the glimpse you got of it as an undergrad was UML trying to give it's last kick before dying. The whole quest for a formal definition and a standard for it doesn't make sense if you only want to use it to give an architectural level view.
Years ago I had a contract with IBM so I got Rose for free. It had really neat demos but once you started using it, it was basically useless or worse. You got a few stub classes and then spent the rest of the time keeping the models in sync with reality.
I think only Clearcase had a bigger negative impact on productivity than Rose.
It was possible to get it to generate code, as I recall it basically gave you stubs of classes and methods and you would then go and code the implementation of each method.
It seemed like it could save you some amount of effort at basic boilerplate stuff but at the cost of putting the same or more effort into the UML.
UML was the swan song of the classic waterfall SDLC gang. Agile and TDD came along and nobody looked back.