Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sequence diagrams, the only good thing UML brought to software development

mermaidchart.com

Post reply on HN
Print view View original

211–220 of 427 posts

Re: Sequence diagrams, the only good thing UML brought to software development

#211

Post by ivan_gammel »

feoren wrote: post #48
ivan_gammel wrote: post #34

Earlier quoted context omitted.

Every software engineering team in my 20+ years career actually used 2-5 types of UML diagrams: classes, sequences, deployment, activity, state. I think it mostly depends on maturity of the team and engineering culture, whether UML is used or not. There’s certainly some value in it.

> I think it mostly depends on maturity of the team and engineering culture, whether UML is used or not. I suspect that's true: teams with a very immature engineering culture probably do use a lot more UML. It's a good way to feel like you're doing something useful instead of actually doing the hard part. Mature teams write code.

Part of engineering culture in general, not just software engineering, is ability to share knowledge though documentation and best practices. If you share the source code, you communicate your solution on a very low level. It is often necessary to zoom out to see the big picture and there visualization helps. You can create ad-hoc diagrams, but their expressive power is low: without a convention it’s basically just space, text, arrows and generic shapes. To increase the expressive power you need a visual language in which different shapes and lines have some semantics. And here comes UML and other diagram languages. If you are not using them, it is likely that you are not communicating efficiently. Can a mature team fail at communication? I leave the answer to you.

Re: Sequence diagrams, the only good thing UML brought to software development

#212

Post by ilyt »

dahwolf wrote: post #158

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…

No, that's the era of worst, shittiest legacy software to date. The computers were just fast enough to handle layers and layers of extraction and oh boy industry loved to pile them one and UML was just another way to pile up the rot

Re: Sequence diagrams, the only good thing UML brought to software development

#213

Post by ilyt »

yafbum wrote: post #198
dahwolf wrote: post #158

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…

We haven't told ourselves that shipping garbage in short cycles is the only way to do things. The market has pretty much determined that companies that over invest in formal software design activities lose out competitively in the long run, and the survivors are the ones with the right balance. You're welcome to prove the market wrong.

And they just shipped garbage in longer cycles... as anyone that had to deal with such designed legacy apps can confirm.

Re: Sequence diagrams, the only good thing UML brought to software development

#215

Post by greiskul »

jrumbut wrote: post #209
jrochkind1 wrote: post #195

Earlier quoted context omitted.

> And they'd know the classics, like memorizing all design patterns. That sentence is bringing back ptsd-like flashbacks. I remember distinctly how much everyone thought that approach you describe was broken when it was the trendy thing. I'm not sure how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous. [The…

To be fair to the design patterns people, a lot of them got baked into pieces of infrastructure like web servers and frameworks, while others are part of frequently included libraries. If I went through and inspected any Node, Rails, Django, etc app I would find many Gang of Four design patterns, but very few of them would be in the project-specific code. They got implemented well, and now programmers can build new t…

Design patterns are missing language features.

http://norvig.com/design-patterns/

Re: Sequence diagrams, the only good thing UML brought to software development

#216

Post by eropple »

opportune wrote: post #180
dahwolf wrote: post #158

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…

That’s because software architecture is something any senior employee should be able to do, and it’s not as important as people thought. Like many abandoned corporate practices, I think it was abandoned for good reason. It may have made sense under different circumstances, like when you had a large army of cheap offshore devs who could not be trusted to architect a maintainable application. If I had some ivory tower…

As much as I do think that software architecture does matter (though it should probably be somebody with a staff or principal hat, not a specific job title) I recently took a job at a place that really does like architect titles. Mine's even "lead architect".

It is pretty funny when somebody runs into me and realizes for the first time that I have the job because I build stuff and write code, not because I'm good at LucidChart. I'm planning things out beyond immediate needs, but not because I'm looking for job security--it's because I've built the thing we're doing before and would like to not make the same mistakes I've made in the past. I'm over here demanding adequate standards of code and low- to mid-level design, and the "wait he's serious?" of it is sometimes honestly pretty fun to run up against.

I am good at LucidChart though.

Re: Sequence diagrams, the only good thing UML brought to software development

#217

Post by ozim »

doctor_eval wrote: post #187
lainga wrote: post #179

Earlier quoted context omitted.

Has anything replaced UML? I mean, if there are teams out there that aren't shunning design, what do they use to create architecture diagrams?

I can’t remember where I read this (Martin Fowler maybe?), but I agree that “box and line” diagrams should be enough for most design cases. I was eager to use UML when it came out but I agree with the article, the only thing I kept was sequence diagrams. Most of the rest of it was just a complicated way to represent stuff that is best represented in code or plain documentation. I’m also not afraid to use stuff that’s…

I like use case diagrams as well. Thing is these should be short lived and used to make specific illustration in specific time. Not some holy grail of documentation that people should take as some god given truth for whole life of the system.

Re: Sequence diagrams, the only good thing UML brought to software development

#218

Post by RachelF »

yafbum wrote: post #198
dahwolf wrote: post #158

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…

We haven't told ourselves that shipping garbage in short cycles is the only way to do things. The market has pretty much determined that companies that over invest in formal software design activities lose out competitively in the long run, and the survivors are the ones with the right balance. You're welcome to prove the market wrong.

In truth it depends on the software. For web or phone or desktop apps which can be upgraded on the fly, short cycles are ok.

On the other hand, Boeing's crappy software practices resulting in the 737-MAX crashes are an area where short-cuts killed people.

Re: Sequence diagrams, the only good thing UML brought to software development

#219

Post by ivan_gammel »

taeric wrote: post #46
ivan_gammel wrote: post #34

Earlier quoted context omitted.

Every software engineering team in my 20+ years career actually used 2-5 types of UML diagrams: classes, sequences, deployment, activity, state. I think it mostly depends on maturity of the team and engineering culture, whether UML is used or not. There’s certainly some value in it.

With the odd caveat that you probably use sketches of these diagrams? As soon as you are trying to cram in all of the extra details stuff like class diagrams can do, you are probably wasting time.

I do not understand your question. If I do not deviate from convention but omit unimportant details, is it a sketch for you?

If you have a project document template from PMBoK, do you feel obliged to fill all the sections or you document only information relevant to your project? With UML it’s the same: it offers a lot, but you do not have to use everything to produce a conforming diagram.

Re: Sequence diagrams, the only good thing UML brought to software development

#220

Post by devin »

jrochkind1 wrote: post #195
dahwolf wrote: post #158

In some ways, software development practices have degraded since that era. It largely has to do with the need for speed which comes at the expense of careful consideration, quality, integrity and the formal standards that support it. In fact, I believe it pretty much killed the profession of software architect. Many teams had it as a dedicated role, and this indeed would be a person documenting/designing systems usin…

> And they'd know the classics, like memorizing all design patterns. That sentence is bringing back ptsd-like flashbacks. I remember distinctly how much everyone thought that approach you describe was broken when it was the trendy thing. I'm not sure how universal it ever was, but it was at one point a trendy thing that everyone thought they should be doing... and that so many people subject to found disastrous. [The…

I tend to agree about the time thing, namely that people aren't given enough of it to sit down and take their time with design decisions. If you squint you can kind of see that "software architects" are a business's way of creating a "solution" to this problem, but with lackluster results.

That said, I've been at places where management did a pretty good job of making sure that there was enough time to do this kind of work with middling results. People have to enjoy the work or feel invested in a way that makes them care about "3 years from now", and sadly in a lot of places there's a lot of "whatever, it'll be fine for as long as I work here."

It seemed to me that in let's say 50% of cases, having the extra time didn't really matter. Assumptions about what was being built were proven incorrect not long after a design was laid down and work had begun, or particular engineering types would create increasingly complicated designs with their time rather than doing the hard work of distilling the problem, sometimes including $PET_TECHNOLOGY as part of their solution.

The "let's design something truly great" really has to be in a team's DNA in my experience or you wind up with a good design that isn't followed, one person who does all the work, a gold plated design, etc.

Post reply on HN