UML, Cucumber and modeling reality - MPJ's Musings - Fun Fun Function
Вставка
- Опубліковано 20 сер 2024
- 💖 Support the show by becoming a Patreon
/ funfunfunction
Some of my thoughts about about UML, Cucumber and other languages that try to describe software in pretty specific ways AND also provide an overview of it, and in so doing becomes pretty mediocre at both of them.
🔗 Help translate the show to your language
www.youtube.com...
🔗 mpj on Twitter
/ mpjme
![АЛАУДИНОВ у Скабеевой: эти их ВСУ нас НЕ ДОГОНЯТ 😁 [Пародия]](http://i.ytimg.com/vi/an0anqU4WGQ/mqdefault.jpg)
My experience is that some of UML is very useful.
1) I have used Sequence diagrams to show HOW a system needs to be used. It specifies what information goes into the system and what goes out, whether that be to another system, to different people or whatever else. That enabled me to add the fairly substantial functionality needed to an existing system to handle audits, auditors etc. For a bit of background, this was the third time the people got someone to write the functionality for them, and only the one I created got used because it actually did what they wanted it to do. The two before were the initial write of it which was ages ago, which just didn't handle the data it needed to, the one after that was created with something called "workflow", no idea what that was, but it didn't do what they needed.
2) Diagramming the data. E/R diagrams which label all the fields of the tables, the primary keys and the foreign keys have been very useful in designing an application as well as communicating between team members and the people who I write the system for.
For me using diagrams to say what happens inside a computer program have not been useful to me. Using diagrams to document how the system will be used, and for modelling the data, have been very useful.
+fungaldroid thanks for sharing!
No problem. Thanks for the show!
fungaldroid +1 to E/R diagrams being super useful. i prefer low res wireframes over use case diagrams though.
I'm a big fan of your channel and I learned a lot from your explainations - while being a software engineer for over ten years by myself. But this episode made me thinking because what you say differs with my experience and convidence as an engineer.
I experience currently a project which suffer from the fact, that avoiding "modeling" a system (or parts of it) properly leads to serious problems in the long run. A complex system needs an abrstaction, an overview, a rough description. UML provides a visual language for that purpose - not for details or all-embracing specification.
When you specify an IT system you should be aware of the scope and perspective in doing so - two factors UML encourage in its fundamental structure. a common problem or mistake at specifying an system is the attempt to embrace the hole system at once with all its complexity and detail. with UML you can "crack" this problem by looking at the system with different "views/googles" from different corners.
Additionally UML provides a efficient and fast method transporting "ideas" resp. "system designs"; I experienced engineers talking for hours about a problem, drawn with in a proper UML (the right type and scope) has cut this time to minutes with other engineers - assuming of course they know UML conventions more or less.
UML is a language, a visual language and as every language its usefullness depends of its use. Your thoughts on this opinion would interest me a lot. Keep going!
I think UML is very useful to communicate with customer and team, but the most useful part is USE CASES, that starts with very simple diagrams to determine the requirements and scope of the system, but is most useful when you go incrementally refining it in plain english (or your language, of course). If you really describe the UC well, you'll be able to create other UML diagrams to help describe the system. But this does not mean describe the system at hand in a waterfall manner at all, it could be as agile and incrementally as you need, from an overview of the system to a detailed description of the tasks in a sprint... I used to teach in a university in Brazil, and worked in practice too and I really saw good results in communication and as a tool to organize my own thoughts. .
I kind of use UML in a different way. When developing new code I use the concept of UML to describe program flow (activity and sequence diagrams) and needed classes (Class diagram). At this stage I just use the basic type of illustration that UML uses but do not focus on creating a valid UML diagram. After I developed that code with these illustrations in mind I extend the UML class diagram to really represent the relations between classes and class members. I do so because we (VR lab at Bauhaus Universität Weimar) often write code that won't be changed for some time or is passed ahead to another person. I really enjoy to get such UML documentations to understand the structure of program I'm gonna work on later. In my opinion that really saves time in understanding code, especially if you need to change only a few things and just want to know in which relation the affected class members stand.
lol
Just a detail:
"Gherkin" is the language which you write scenarios/steps. Cucumber is a framework which use files written in Gherkin to orchestrate the testing execution and reporting.
Behat, for instance, is the equivalent of Cucumber for PHP, but it uses Gherkin as well.
hi, like your channel, keep up the good work.
Some points I'd like to add.
-when developers get together and use a whiteboard, they will need to agree on a language of communicating the ideas and it's usually going to be rudimentary UML. Many times these diagrams end up being photographed and added to docs.
-agree that when you want specific parts of the code your best bet is reading code however to have a macro view of a whole ecosystem of applications and their interactions, it's a whole different ball game. Nothing will beat a good diagram, such as a sequence diagram.
-most of the time documents will fail because of human problems (ie not keeping docs up to date) not the language itself.
So, basically, partially agree about UML being an elaborate waste of time. Back in the 90's when UML was all the rage, sure. That was a big waste. But knowing some basics and using it in specific times is definitely worth it.
Cheers.
I think there are parallels with what you've said here and Law: nobody drafts legislation or writes contracts using pictures because it would be far too ambiguous. Further, communicating very precise meaning in human languages is sufficiently hard that there exists an entire profession whose job is to try to do this (i.e. lawyers). Even then they don't always get it clear and unambiguous.
Just like a lawyer's job is (generally) to turn their client's requirements into precise legal documents, the job of developers is (generally) to turn (human, fuzzy) requirements into precise code. In both cases, identifying and resolving ambiguities or inconsistencies in the process.
+Mike Talbot Very interesting parallel!!
Law is the programming language for society. There will always be bugs (loopholes and unintended consequences/results) and there will always need to be patches and updates for it.
I think one area where modeling languages excel is in designing APIs. If you're designing a library or a REST API, it is extremely helpful to define the exposed functionality before you code. No implementation details, just the API surface.
"very elaborate waste of time" is the best description for UML I've heard. Thanks man.
Hey have you ever tried writing board game rules. Had an absolute nightmare trying to make sure everyone understood the same (intended) meaning from the text.
Love this insight!
But you can still understand the game rules if there is no one around.
I've read a lot of them... and I always find them confusing. We bought Sushi-Go (on MPJ's) suggestion... and it took 3 educated adults - 30 minutes to figure it out. We did buy the 'party pack' or something... maybe they assumed you've played the original. I always think about re-writing the Catan rules.
sheriff derek Have a go. It's way harder than you think.
Actually when I was writing the rules for Enchanted Convoy (my game) I was really tempted to use psudocode for clarity in places. I decided against it in the end. Mostly because my wife couldn't read it that way, and she is always my first proof reader
Funny that you should bring up Cucumber (Gherkin is the BDD language as has been pointed out). We're looking into this where I work. Here's why I think it has a lot of merit.
In Scrum or any other development methodology, you have a team of developers and someone who specifies what they want from that team. This is obviously not specific to agile as this is the way the world works. The product owner describes a story and often times writes out acceptance criteria in that story. They try to write as much specificity as possible while being observant of their own time. The more answers that can be answered up front, the better the estimate will be on how much "time" it will take to complete the feature and the closer the feature will be to what they imagine it.
At the end of the sprint, you have a review of what was agreed upon at the beginning to be completed. Sometimes there's a discrepancy between what the owner said they wanted and what was actually created. The hard rule is that there is no blame, but whenever this happens, the owner and the developer(s) always attempt to defend their actions/words. Developers really like to have something completed and see their work being used. Owners want to get the feature they requested the way the envisioned it and without having to write it themselves.
Where Gherkin comes in is that there is an objective way to measure the success of communication. If the tests pass and the feature still isn't the way the owner envisioned it, they should write better behavior tests. If it doesn't pass, then the developer didn't code it to the specs.
I know this seems like a great way to apply something we shouldn't - blame. I don't see it as that. We want to be as descriptive as possible while still being terse. If the tests are passing and the features aren't coming out as the owner imagined, they can see that they need to be more descriptive. If they are passing and the features are being created as they imagined, but it takes them tons of time, they can probably be more terse.
Then, where this becomes BDD (which I'm not at the point of), is describing new, more abstract, components. I don't think BDD will help me in the future for the smaller components or the things that require a lot of detail. I think that would go into the realm of TDD or just regular build and test as you go.
I totally agree with you: I also felt like Gherkin or UML are a waste of time when describing very specific things. Talking about BDD, to be honest I'd love to see a company successfully applying it in their process. BDD (as a whole) reminds me what you explained about class hierarchies: they are designed "when you have the least understanding of the project" (from your video about composition vs inheritance). This usually leads people to generate UML from code, which is quite useless.
However I found those tools quite useful to describe high level views. Well used, UML saves a ton of time. Everytime you start working on a new project (especially if it's a big and old one) there's the overwhelming period when you're trying to find your way in the labyrinth. Sure the whiteboard is the best to get the big picture, but you can't always rely on your colleagues (lack of time or even experience on the topic). It's ambarassing when you need to ask all the time "how is component A related to component B" whereas with a high level UML you'd have got it straight away.
Concerning Gherkin (cucumber tests language) I first had the same reaction: "I kind of love it, but it's limiting me as a developer". Actually I only started using it since a few days, so I'm still completely convinced yet, but I found it really good for writing REST API specs. So yeah it is limiting when you compare it to something like mocha, but I think it deserves a chance. Have you ever used it on a project ?
Nice video anyway :)
I take issue with the broad claim that visual programming languages work badly. I am working with scratch right now as I teach my son programming and so far it is very capable, but that's just the beginning. So far we have approached visual programming as a way of making coding easier to understand, but this is an approach that can at best only achieve parity with textual counterparts. I am much more interested to see what we can achieve when we throw out ( at least temporarily ) the standard of text-based programming and explore visual programming in a more free environment.
Visual systems are already better at illustrating connections, composition, and flow. Max MSP is incredible for building complex audio signal processing applications and musical interfaces. Text-based programming is one-dimensional, every deviation from a linear, imperative flow requires some sort of textual construct that is basically a stand-in for an arrow on a drawing.
In some ways this is empowering, complexity is limited by the brains inability to think of too many things at once - but perhaps a more gestalt view of all the compositions, control logic, dependencies, etc could really help. But again this is the the boringly adjacent view of what visual programming could be.
Take a look at hexagony, esolangs.org/wiki/Hexagony, that a 2D, stack-based language which is equal parts academic esoteria and sick joke. BUT we have a language that is also capable of achieving new (maybe ridiculous) relationships between code and data, given how the instruction pointers move. So maybe visual programming languages could encode more into their topography than just basic relationships. Or maybe we could define things like loads and timing as segment lengths in some sort of graph and optimize code via spatial algorithms like a force directed graph.
These are quick and likely very inadequate examples, but the point is we can't just call the whole real of visual programming bad. Certainly we can;t paint UML and Max MSP with the same brush. We have been programming in earnest for less than a century. What will programming be like in 500 years? I love javascript but I sure hope we have something more compelling by then.
UML is very extensive and establishes general rules for communication. These rules can be freely used to create any kind of diagram you can think of, while having the same symbol mean the same thing.
The idea behind UML is a whiteboard-esque protocoll, which you can use as documentation of the whole development-process from start (meeting your customer the first time) to finish (stopping support for the software).
Every diagram type that you probably know as UML is just an exemplar application of the specification. If you look into the specification, then you realize that UML can be something different besides what you *know* as UML.
There is so much more to UML then class-diagrams (which are terrible; I'm on your side there).
EDIT: typo
Yes, code is for humans. And specs are bad.
But code is just a bunch of text. It's like a book.
If you're gonna make a movie you do a storyboard to give you an overview, you don't just go "the text is all you need". In the same way a diagram can give you an overview of a system, you don't just go "the code is all you need".
Code is still king.
The diagram is just an accessory.
But it's nice to have a visual aid to get a quick overview that reading a bunch of text can't give you.
+BenRangel absolutely! I completely and fully agree. The point I was trying to make was that simple per drawings are a better tool than UML for that.
I agree with you that uml does not work for code. Code is better described in code or something like Cucumber.
For databases though I find that a data model view where each box is a table and each arrow a foreign key works well.
I try to fit my data model fit on a single poster on the wall.
This has several benefits:
1 - it can help for writing queries
2 - as it is always visible, you tehnd to not forget about it and update it regularly (it doesn't go stale)
3 - it prevents me or others to go wild and create too many new tables (that would not fit on the poster anymore).
I also was really enthusiastic about Cucumber, but found it lacking in practice. There was always something unsatisfying about it that I couldn't quite express until I saw your vid. Very nicely put.
Thanks for sharing your thoughts. What's even more impressing than your knowledge is that you're able to share it in such accessible and also entertaining manner.
May I ask if you ever thought about (one or more) videos about writing a JavaScript transpiler? I think would be very interesting and educational.
I have watched this guy before and some of the things he is saying are true but I disagree with some of the stuff he says.
I don't think that you can flesh out every infinite detail of a piece of software with UML, however, you can use it to get an overall top level view of the objects, attributes and actions that the software project is made up of. It also helps to see the relationships between objects and in so doing further clarifies the actions between objects that exist.
I think it becomes an iterative process no matter what design tool or process you are using. You first want to get an overall top level perspective of what the software is supposed to be providing with respect to functionality and purpose. Once you have as complete a picture (including requirements), as you can get within reason and the time constraints allow, then I think you should start coding. I think it is foolhardy and irresponsible as a professional programmer though, to jump into the code too soon; before you have at least fleshed out your river banks. Almost all design philosophies incorporate some phase in their total software management lifecycle that includes the definition of requirements, ie functionality and purpose before attempting to start the implementation phase. The requirements, specifications, UML modeling can be revised to reflect changes in the design after the first few iterations of the design/code/test cycle. The thing is to, first get something that resembles your design and actually works (ie meets the requirements/specifications), then examine both your code and design and see where you can improve on one of both of them.
I don't believe your code is a good substitute for either your design or your documentation. The code is the Implementaion of you design and the Result of your documentation. All you have to do is ask someone that follows a previous developer that has not implemented any design or documentation on a project. It soon becomes an overwhelming and time consuming effort to reverse engineer the project and typically results in a poor design overall. Ask an engineer if he has ever built a building without a preexisting design or documentation. And then try and tell him that his design and documentation is the building itself. After staring you down for about 30 seconds he would probably say something like, "Do you think I want to look like I'm a totally irresponsible, incompetent fool?" Why should it be any different for a software project?
I think he is getting confused about what code is. Code is not the specifics of the design it is the result of the specifics as defined by the requirements and specifications. A hammer is not a description of the specification, it is a result or manifestation of a specification. It must weigh a certain amount, it must have a head that will drive nails, it must have a claw to pull nails, it must have a handle to grab onto. If you don't have any idea of what a hammer is before you start then how are you going to create a hammer. It's like he is saying a hammer is a hammer because it is a hammer, not because it performs certain functionality as specified by its design.
If you only expect to use either coding language or internal code documentation as your only description of what a program is supposed to do then you are looking at a very low level, ie at the minute details and lose the well-defined top down overview of what the project is supposed to be doing.
At 4:02 "English is not very expressive". That is your job as a software professional to bridge the gap, (ie be a translator) between English prose and what will be developed as the software requirements and specifications and ultimately the functionality that the piece of software will provide.
Gee, I didn't know I was going to write a blog on the subject, lol
The best "specification" is to give a list of conditions to answer the question "How will we know the software is done?" Answering that question (creating a completion criteria) should be done on a whiteboard initially until the programmers have enough information to start prototyping, then once you have a grasp of the actual functionality, blue print with TDD, then code to the tests. Iterate until all completion criteria are met.
Completion criteria is NOT a description of HOW the software functions, just what the output of a successfully developed software should look like when used.
Quote worth repeating: "UML - Very Elaborate Waste of Time"
I agree about cucumber / gherkin. I've worked on and seen a few projects using Behat which is the leading PHP bdd library. The promise is that a stakeholder / subject matter expert will read and write the code that looks like English but I haven't seen that happen. And I've seen a lot of gherkin code that didn't use any domain concepts and was just an awkward way of calling PHP functions.
To me a better alternative would seem to be developing a set of functions in a normal programming language like PHP, javascript, java or whatever the project uses, making sure they have really good descriptive names, and are all at the same level of abstraction, and then using those to write test cases. With a bit of support from a developer or QA the stakeholder should be able to read the test cases and tell you whether the tests do indeed assure the quality of the system.
I have never really heared about UML before this video, but I could imagine it would be great as a tool along with the code, when trying to learn a new codebase. Because you can use the graphical repensentation, to see how classes depend on each other.
+Viktor Strate yeah, that's the idea. However, as I tried to explain in the video, it doesn't work out in practice because UML isn't expressive enough to communicate detail, and too noisy to give an overview. Simple drawn diagrams are superior tools for most cases where UML is promoted.
IFML worked for me on a larger scale project.
I think these tools are fine for the initial design, but introduce a large cost if you want to keep them up to date. But I can imagine a large scale project where up to date model is a must, and developing every new feature begins with the model. The key is to find balance.
THANK YOU!! please try to talk about MDD, MDA and MDE in a future video. Absolutetly love to hear someone talk out loud how crappy all this things are for what they strive for. People have ben trying to push graphical/visual programming since ever and failing miserably, there is something about computer programs that seems to be textual in nature.
I feel as if whenever I do UML diagrams for projects, I end up making them just as a general overview and then start getting specific when I get into the code. I totally agree with your views on UML, whiteboards and straight code is the way to go MPJ 👍🏼
Very interesting topic! I constantly see adds for websites which help the regular users "visually" code their own websites - arranging frames and so on, I never take those seriously, but brings up two interesting questions - one is that i see this going in the direction towards self expression (same way as everyone became a photographer when they bought a DSLR camera) same way here - you pay for a service that enables you to manipulate something (to code) that before only people with some knowledge could manipulate (programmers). And secondly maybe it will soon start working out, when you think of advancements in AI. Thanks for the vid!
Perfect response... I wonder how do you create this elaborated responses? If there's some "path" to create all this thoughts about the questions, and put this together, it would be very good to me, because I have many discussions with my colleagues about all kind of technical questions...
There is a video or two about how he creates his videos. He briefly goes into how he mind maps ideas.
"...drawing boxes with lines between them" LOL 10 points!
Gherkin was created as a domain language "easy" to understand for customers. In my experience working with CucumberJS the ones who struggle a lot with Gherkin are the developers and Business Analysts. Therefore I could say that Gherkin is indeed easy for customers to understand, very difficult for developers to implement.
I feel UML is more about sharing information with people outside the development world. It (should be) an abstract representation of code, no?
That's what I've used it for. Sometimes you have to explain to the client how the basic relationships and resources are connected... but drawing on paper is much faster...
Love your comments about UML as well as overly detailed build specs. With BDD however I've actually had quite a bit of success, but only when someone from the business writes the spec.
The BDD test is very high level and coarse. I use BDD to document the critical features and high level requirements and drive the golden path integration tests with a couple edge cases.
For things which have heaps of permutations or aren't 'businessy' I'll use unit tests or a different style of integration tests e.g feeding in a spreadsheet to drive tests.
Try working i a project were developers doesn't fit around a wyteboard.
How do you document the usage of a data field (column) in a persistent storage (table) so that developers can use it correctly 10 years after 1st release.
Wyteboard works great for Code-and-Run contractors.
The primary target group for UML is not the developers of the 1st release.
+Erland Lestander you can simply write a text in the description in the actual database explaining what the field is for.
If you have a team that cannot fit around a whiteboard, you should probably break your team up as it is problematically big, but putting that aside, you can create digital documents with simple drawings using other tools than UML. The intent of the whiteboard example is just illustrative that simple tools are better than the heavyweight UML, not that whiteboards per se is the most suitable tool.
You can also make videos, im doing this nowdays , i make a video explaning the topic and pass around, it super easy and very effective
To write it in plain English , then you need to define the words so all agrees.
"Board game roles" problem.
- That is what UML is. -A defined language.
I would love using code to figure out how the different parts of the application fit together,
IF I was payed by the hour.
Using code to describe how communication is done to external systems, and why, seems like a really stupid idea.
That would be like describing the purpose of a car with taking it apart and describing its parts.
Using code to describe how other systems rely on your data and API's seems ... challenging.
As for videos, Good luck in handing that over to the third maintenance team 8 years down the road.
Or, try to edit it when things change...
"Read code to understand code."
But it is absolutely not the best way to understand the purpose of the code.
Code is an exact description of how a problem is solved.
- Not an exact description of the problem.
Your bookshelves inspire me to get more books 😄
mpj almost went full philosopher in this one, i think plato's theory of forms is very relevant to this topic
I have to say that programming languages are not good specification languages. Neither is UML or anything else so I'm glad you got that out of the way! So what is a good specification language for software? After all we have blueprints for buildings, etc...
Logic! Predicates!
Maths is a high-enough level language to describe system designs without having to describe the implementation (which is what program source code does). Designing programs can be done in the manipulation of predicates and their calculation (predicate calculus!). I believe it's quite an approachable branch of maths for programmers... since that's what programmers do all the time anyway: manipulate predicates.
The bonus of using mathematical specifications is that they are checkable or, with enough discipline, even provable!
our process requires documenting with UML diagrams. However we have a tool that reverse engineers the diagrams from code. So we do that, paste it into a word document and it is never looked at again.
+david howard seems like an agile and effective team that questions the value of all the tools in their process :)
Thank you for the video as always.
I found UML to be the most effective communication tool when talking about implementation details. I usually can advise after few minutes and be sure that me and my collegue are talking about the same thing. It gets ever more effective when talking with people who do not use the same languages as you. Quick raw design do also work for me. I don't really like UML for the reason you mention but specific usage can be effective. I would argue that you can do a good job without it and spending your time on something more fondamental like algorithm, math or physics is a better investment.
I would be interested to hear people who think it is a must have their project.
I think things get much better when you use fun fun functional programming techniques :D
I really like your take on this. I find UML and friends, are very good for rough explanation, especially to non-tech people. Like you say, it is not my code nore a very accurate description. I also find it useful to crystallize concepts in my head and as a rough todo list.
+Niel van Steenderen but why UML? Why not just drawings?
Now that you mentioned it, most recently I did the white board drawing first, took a photo of the final product, then did the digital version. I don't stick strictly to UML standards but use it to depict the process flow. I use something called yEd and it has some sorting and redrawing features. I have found that sometimes surprising insights can be found by throwing down the blocks|steps|processes with arrows, then reshuffling top down, right left, that sort of thing. Occasionally you see a pattern to the interlinking madness that was not evident on the physical. Then I use it as todo list and colour code the blocks as the bits get done, updating if needs be. I have even used them for hand overs. So you can see this service connected to that one, on that server with a rough idea (like 3 words kind of rough) of what it does.
This video... reminds me of what I thought of having to write outlines for papers as homework throughout my time in school. You want me to write an outline, where I parse out my claim, and the supporting evidence for each main idea that further supports my claim, and you want me to give it to you next monday. Then you want the paper 3 weeks from now. Why do I need to submit the paper in 3 weeks if I have to pretty much write the paper by next monday?
I like UML to flush out some ideas at the very very beginning of a project. I'll transform the diagrams into code and then never go back to the UML diagrams. But, again, at the very beginning of a project, I like UML very much.
Would be nice to hear in the same topic context about the DSL. It's only for the developers, but it much easier to explain relations to the customer and remember all the details to make a changes and modifications.
I believe tools like UMLs could be adopted much wider to understand/reverse engineer existing software. I don't think all sorts of UML diagrams are useful, but sequence diagrams and some of them really are. There are almost no tools to generate these from existing software and then consume it.
I would like to see UMLish tools like the Views are for Tables - in databases. Tables are the concrete specification, Views are the interesting "slices/cuttings" of set of tables. We should be able to "collapse" all the relevant/irrelevant parts of code for a given idea - like code folding (but its far not good enough).
By consuming textual code you are very restricted to link different parts of the software. Mind the number of navigational steps you make, or the number of tabs you have open, or the number of monitors you sit front of. I really think thats all the same bullshit.
this depends on the code and on the developer style. some people are visual and some are auditory. so it really depends.
What about data/api design?
loopback/strongloop is pretty visual and looks like it works.
Evgeniy Foucault I think that's the idea, communicating things in a visual manner with a simple notation. in that case, it shows the API design, not the domain objects.
Great video. I traveled through Gothenburg for the first time yesterday, and I wanted to stop and talk about programming with you 😳
I miss you, MPJ. I hope you’re doing well.
Bus stop, lamp post, flowers, road. Sweden. Not even French Stewart is so brazen about sharing where he lives with his fans.
@mpjme, in coming academic year I should make my diploma project. In it there is a requirement to make UML diagrams (activity, use case). What do you think about this situation? What alternatives may I use to UML?
+Muhammadjavohir Suratov if it has a requirement to use UML then you just use UML. You are in school, and the point is primarily to learn. The output artifact is very secondary to that. Use this as an opportunity to observe and analyze UML and develop opinions on it. Understanding something, having experience with it, and then avoiding it is wisdom, but avoiding tech without knowledge of it is just dismissal/ignorance/blind following of what mpj says. :)
funfunfunction thanks a lot :)
Muhammadjavohir Suratov Learning UML is not a bad thing. In fact, I use the UML concepts freely and abstract on the whiteboard to communicate my thoughts about code. And furthermore, you can use the UML drawing libraries/tools on the computerto draw high-level concepts. But I totally agree with @mpjme that trying to create code out of UML and vice versa is a bad idea (code generation in general imho).
Thank you very much for clearing this subject out ! :-)
Although it would be cool to have the thoughts of other developers working in different kinds of companies.
Boxes(objects) with arrows between them... Welcome to category theory
Just in time for my current situation.
I'm curious about event state engines in JavaScript. Would you do a video on those?
Pure Data actually works quite well as a visual programming language, but it is very different from what we are used to, and solves very specific problems.
See also:
en.wikipedia.org/wiki/Dataflow_programming
Pure Data is rather limited in what you can do with it, and it gets VERY confusion if you attempt to do complex things.
Dataflow programming is a buzzword paired a fuzzy description for programming with pure functions (ie functions that does not modify state and has a single entry and exit point).
Depends on a task, had some experience with MaxMSP making audio visualizations.
Also stuff like NodeRED, ifttt and noflo.js can be quite useful if you need to plug some functions to some events. And i am quite sure visual design of database relations can be done in visual way. So, connect chatbot to light bulb and add few check in between, write this action to log db. Some of "DevOps" ci/cd tools are pretty successful at this kind of thing too.
Facebook origami studio is another good example of this kind of workflow, it almost generates code. Also UnrealEngine got something like this, you can replace it with code if you like, but a lot of people using it to make awesomely complicated logic
That's why i said it's limited. For a lot of tasks it's certainly faster and the barrier to entry is lower then making the same thing with C++ or any other general purpose programming language.
They are okay if you can live with the limitation.
Unreal Engine 's Blueprint system is certainly capable of complicated logic, although i would not use the word "awesome" for it. It's always harder to interpret that, than code.
You said exactly what I was thinking: Pure Data is not a general purpose language. Sometimes doing basic stuff can be much more complicated than it would be in an imperative language, and in some cases I had to write my own externals. OTOH it abstracts complex DSP-related problems, so for doing what it is intended to it works very well, but won't replace node.js or php anytime soon.
Where's your yoshi ? lol
Great video btw!
I have studied UML, it is becomes a waste of time when you trying to write will software that works . When doing personal projects, I may use a Sketch Pad,Whiteboard, or LibreOffice Draw to write out some of my idea's.(not all) That is what the code and comments in code is for is for.
very nice video... " Why need UML Code is for humans" you nailed it ....
I think the problem is you are drawing, and not modelling. You have a domain, you create a domain model consisting of concepts and connections among the concepts. You can also model the functionality of the system various way, for example using activity diagrams. Then, you have business use cases, which can de described some way (text, gherkins, whatever) and the model is checked against them. If the model does not fullfill the requirements then it will has to be modified until it does. You can bring in all the magic from UML and SysML. The model is the truth of WHAT needs to be done, and the code and the infrastructure is an implementation of it. If done right it provides complete traceability which is especially important if the software needs to be audited. You can even do agile modeling driven design as well. Model driven design also plays very-very well with Domain Driven Design.
I am the only one annoyed with TreeHouse advertising?
I am not sure what the message "be a website developer in 6 weeks" means for the profession.
It's an advertisement. They're trying to get people to click the add
Sure, who need 6 weeks? I can teach you HTML in 10 minutes!
Loads of people need to pivot and switch careers later in life. I can't think of a better option than software development. The problem is most people don't go down this route because they think they don't/can't understand it. I'm for anything that makes it seem less frightening to newcomers. If you're worried about the field of web development becoming saturated with bad developers.... that's like worrying the ocean might get wetter.
Perhaps yes.
they do have really good courses, though. it took me 10 months instead of six weeks, but I did become a developer.
I think learning UML - or any kind of standard "drawing language" - would help everyone looking at the whiteboard to understand the problem/explanation.
PS: I agree UML is not as useful on modern development as it was for big companies process on the 80's, but we all should try at least to understand it.
comet3bc13 I've been there most of times, believe me. I think is sad since is a great tool for documentation as well. But I had the chance of working with it and it cuts a lot of time just to know ie: how to draw data structure's relationships..
This is one of the few videos with which I disagree. English is very expressive but it takes time to learn and use properly. Granted it doesn't replace an image and the phrase "a picture is worth a thousand words" still holds true. UML is great for explaining a concept quickly and general relationships. When collaborating with other developers, an outline of the architecture in UML _and_ flowcharts is necessary. I do agree with the idea that it isn't a replacement of code and writing code is essential to communicating details. But even with this in mind, that doesn't mean UML or Flowcharts or anything else that is quickly expressive are misguided and unnecessary. If you believe that, I would go into another whiteboard session and take note of what is being drawn.
What is the best tool to use, Hammer or Screwdriver...? UML or Use Case?
Doesn't it depend on who and what it is for?
Is there anything anyone can recommend for generating UML diagrams from a nodejs app that hasn't been documented?
While there isn’t such a thing as the best tool for all situations, some tools are really just pretty bad tools.
Worked with the best programmers in the world, none of them uses UML. I find that very difficult to believe. Could it be that they actually used it but because you never heard of it, you didn't know? Maybe it was just boxes and lines for you. Have you ever googled for design patterns? First thing you see is UML diagrams.
+Ceko nobody used it in their team communication that I can recall, no. They used more simple and direct communication - simple graphs that were devoid of the detail that UML has, and that often distracts from what you are communicating. If you're writing a book or article about design patterns UML is probably useful as the concepts described there are simple examples and the UML shortcomings I talk about are less prevalent. But I still think simple drawings are more suitable, honestly.
I believe, UML is for university, on beginning to understand a little how works, for some people that never touched a computer in life.
UNIX utilities about 05:16: "Are we a joke to you?"
Code is for humans! I love it! That is a phrase/concept that isn't given enough attention.
1:38 Amen to that. 3:21 Double amen to that. Shared documents aren't shared understanding. We should talk/draw/be more together instead of sharing just documents and hoping other stakeholders will get it. Jeff Patton explains it very well in his talks: ua-cam.com/video/AorAgSrHjKM/v-deo.htmlm6s
MPJ, I agree with you, but I think the problem is just related to paradigms that force you to define things strictly. Object-oriented languages have fewer side effects than imperative languages, but they try to remove side effects by defining things more deeply. It just brings more work and makes a visual language something counterproductive.
I think functional programming could be a paradigm that would have a place for that way of doing things since it is much simpler than the object-oriented design require a system to be.
Have you seen a programming language called Luna? (www.luna-lang.org/). I think is a good intermediate path until we get to real declarative programming, languages that will enable everyone to program complex systems.
So I am curious then how you have taken business requirements or specs and turned them into code?
UML has many layers and proper communication with the customer is part of the strength of UML's prototyping capabilities.
MPJ is mainly concerned with class- and object- UML which is often very pointless.
Mattias, make a video about Rust! please!
It's a great game
It's 5:14AM here :O
Its funny, after watching this, I realized I had the same feelings towards these specification languages.
Yes, it can make things easier to express to non developers, but at a terrific cost.
+John Rossitter yep!
Hei Mattias. Jeg sitter på andre siden av grensen, i Norge. Har benyttet State Diagram (Tilstands-diagram) i programutvikling i > 10 år med stor suksess
a) Real-Time Styresystemer - objective.no/Topp_Menyer/06-Frameworks/Frameworks.php
b) Concrete Maturity (HPC-09 v6) : objective.no/Lean
Systemene jeg har brukt til dette har en god del mangler, og jeg utviklet en ide til et system hvor Kode og Diagram alltid var synkronisert: (NO Round Trip: The Diagram is the Ground Truth)
Systemet (VcaSde) ble ferdigstilt i mai i år: objective.no/VcaSdeHome. Twitter: twitter.com/OT_VcaSde
VcaSde kan benyttes ved utvikling av Windows Applikasjoner og Xamarin Apps.
Hadde vært interessant om du tok kontakt så vi kunne snakket litt om dette! Jeg har etter hvert 27 års erfaring med software, hardware og alle mulige kombinasjoner.
Se føgende videoer:
objective.no/VcaSdeWhy
objective.no/VcaSdeInnerSecrets
objective.no/VcaSdeMakeIdeasFly
objective.no/VcaSdeContextPattern
objective.no/VcaSdeBugSearch
Info om State DIagram Context Pattern:
objective.no/VcaSdeContextInfo
Do any of you JS developers use any kind of project diagrams?
While I was mainly working with C# everyone used diagrams. But now that I'm mainly involved with JS I don't see anyone using diagrams at all. Of any kind.
+BenRangel Microsoft was into diagrams a lot for a while, all the tools and courses included them.
I absolutely agree with you! Still at times I use simplified UML to describe some high level of interaction between types. And for that I use yuml.me/ it might help y'all out.
It may be true that English is not very good for communicating specific ideas to each other.
However, it can be useful to communicating ideas to oneself.
Furthermore, I think knowing maths, and programming, can feed back into how you use English to make it more able to communicate specific thoughts.
I have personally written things that go anywhere from super vague descriptions, through pseudocode, up to actual code. All of which have helped me write the code afterwards.
Enochian language would be the perfect replacement for UML, at least it might call some angels when some coding problems arise, lol!
@funfunfunction what are your thoughts on generated code? Part of me wants to believe that it's a nifty tool for saving programmers time and maintenance costs through automation. Mostly it just seems like a hack to write software at higher levels of abstraction than your library/language allows for otherwise.
+Barely Functional mostly (not always) I find it to be a gimmick. Partly because I find that 95%+ of development is spent on maintenance of existing code - writing new code is already relatively easy and efficient and we don't need to become more productive there. Another aspect is that I find that if code generation is needed/beneficial for something then that is a smell that indicates that we're dealing with an API that is extremely verbose/boilerplatey or has been abstracted on the wrong level. This is not always the case, but one should stay wary.
funfunfunction - thanks for the reply and I agree in general. There are also cases where code generation can help with maintenance of large projects where the developers aren't communicating effectively. For example if the consumer of an API uses code auto-generated by the schema/API contract and a new version comes out then the new generated code could be used to try and find breaking changes if no other information is available. But it's always dangerous to trust static type systems to find logic errors.
+Barely Functional if a team is trying to mitigate the problem of bad communication with anything else than directly working on improving the communication, I would call that into question. In the case you are describing, it seems like a poor replacement for much better tools to solve the same problem, such as semantic versioning, documenting breaking changes, jscodeshift transformations or keeping the library in a monorepo so that changes cannot be made without the build failing.
+funfunfunction if only the proper use of the tools you describe were the rule instead of the exception in enterprise scale projects. Too often code generation is used as a form of archeology to make sense of the generation source that's poorly documented. Speaking of which, I also see UML used as a form of code archeology to generate diagrams as retroactive "designs" of the system when no one took the time to document the software architecture. You typically can't just use UML auto-generated directly from code since it shows way too many details, and instead have to invent conventions for how to roll up details into a higher level summary, but we're engineers who love to solve meta problems.
Code that is generated and never edited is fine, and generally doesn't need to be committed to the repo since it can be regenerated tomorrow, e.g. machine code generated from C, or javascript generated from typescript. Small bits of code generation can be useful to work around limitations of a language, e.g. IDEs generate getters and setters for Java because it doesn't have properties like C#. Generated code that's long and needs to be manually edited is generally best avoided.
Heavily agree!
I suppose the crux of the matter is to whom are you trying to communicate. Each document has an intended audience. Specifications are meant for managers and marketing -- they're broad and not overly specific. UML and ADL are meant for programmers to get a board overview of a system (too specific is bad). Code is meant to make it easier for humans to communicate with computers (not necessarily other humans -- If code was meant for humans, we wouldn't comment anything, ever). Visual programming languages are good for educating people with less abstraction handling -- right now, they're good for middle schoolers (6th grade). And humans communicate with other humans with all of the above (plus more!)
My point is that every tool we have is good when communicating with a particular constituent. We merely need to pick and choose which ones work for our particular project and dev team. Sometimes, UML is awesome (especially UI), but, in other cases, whiteboards, code, and comments are all we need.
My $0.02.
+Brian Sea i buy your argument in theory, but in practice I've felt that a simple drawing on a whiteboard is vastly superior to UML if the objective is to give a developer an overview of a system. UML simply has too much noise and distractions to be useful as an overview tool, but also lacks the expressiveness needed to give details.
I do not subscribe to the notion that just because someone built a tool and managed to popularize it, doesn't make it a good tool. Some tools are just bad.
I don't quite know what you mean when you say that UML is good for UI, but that seems highly doubtful to me. I would need to see a successful design team recommend it to be convinced. I've worked with world-class UI and UX designers and none of them used UML. The used a combination of more simple sketching software, hand drawn diagrams, Sketch, and Adobe After Effects.
"Some tools are just bad." -- Agreed! I've run into lots of tools that are just bad for the problem they were meant to "solve."
I'm not a huge fan of UML, in general. I've personally only used it for simple class hierarchies, datastore relationships, and UI (below) -- and none of them were very specific. I completely agree with you on the noisey bit.
I've used UML for use cases and code modeling of UIs. Though, when I look back at my experience, I used the UML as a jumping off point instead of the end result (it all morphed), because UML happened to be the "language" the other people knew. Perhaps I forced myself to use the tool.
In any case, I'm happy to know other folks (dis)like UML as much as I do. Thanks for responding!
+Brian Sea no problem at all, thanks for listening!
I think what you end up talking a lot about is Semiotics, you should have a look at Charles Morris Theory Of Semiotics. Nice video!
David West said something In his book that I find interesting: a model that can be understood by a computer is a programming language. Programming languages are not for humans, you don't see the world in terms of functions, modules, or classes. We use them because they allow us to tell the computer what to do. Whiteboard is for humans.
+Miguel Ángel Jiménez Achinte I reject that statement. The computer does not see functions, models or classes. Those are abstractions that are there for the benefit of the human programmer. They are later translated into machine code which the computer can understand.
I agree with you, those abstractions are there for our convenience. However, an abstraction truly created for humans shouldn't look like that; programming languages force us to think like computers.
+Miguel Ángel Jiménez Achinte I partially agree, in the sense that there are abstractions that are born by the limitations of a computer. A computer does not have infinite memory and processing power, which means we need to manage memory, which creates certain abstractions such as caches. However, a lot of it is genuinely there only for the benefit of the human. For example, the concept of a function precedes computers, it's a mathematical concept that humans created in order to make sense of reality and reduce duplication. Another example is the loop and the variable - the computer would much prefer to have things typed out inline.
Do we really think using variables? I see them as convenient abstractions too: variables instead of naked registries or addresses, and loops for procedural flow control. Functions are an interesting case though; I wonder if they are the equivalent of cache, for example, in our world. I mean, is it possible they belong to the computer world and were created here just to bear with our computation limitations?
Functions are not a computer concept. They are a tool in calculus and were invented in the 17th century:
en.wikipedia.org/wiki/History_of_the_function_concept
Who are those greatest programmers you worked with ? :D
Don't you think we could use specifications or diagrams to describe WHAT a software should do and NOT HOW it should do it?
+Saguaro no, that way of thinking about it doesn't work.
If a spec exactly described what, not why, it would effectively be a declarative programming language.
For example, JavaScript is an imperative programming language, largely concerned with how things are done, manipulating memory, moving things around etc. you're describing lots of things not inherent to the problem. However, there are also declarative programming languages, like SQL, which only describes what she want to happen. SQL doesn't concern itself at all with how the data is fetched, that is handled for us. SQL is essentially only describing what, not how.
I suggest you try to find a sql query and try to write a spec using English for it, as a thought experiment. You'll find that as you add more and more of the detail to your English spec, you'll find that it becomes more and more unwieldy in comparison to the SQL.
Well, maybe I wasn't clear, I should have given an example.
I didn't meant that it's good to describe exactly what a system should do but, you know, when building a software you have to know what you want. I don't really see myself like 'Hey, it should be cool to make an online pet store, let's start coding right away!'.
In my day to day work, we have tasks to do that just describe what the end user need to be able to do (we write user stories). It's something like: 'As a user, I should be able to see a list of available pets' and then we write acceptance tests. I'm quite new in scrum development but I think it works well.
Maybe I just misunderstood what you meant by not writing specs. Anyway I love what you do!
Good explanation!
muahaha first. also really been enjoying cucumber in a current side project.
Isn't Eve language similar? I mean, you basically mix there English and computer code.
I know some people who have worked with LabVIEW, which is a visual language for engineers. I don't know anyone who likes it though.
well said
Why no more crazy coffee runs?
+Purplecones time constraints basically, they take a lot of effort. I might bring them back in the future.
18 year as programmer only need a paper, whitebaord or just show the code
Coding is not everything when we developing system. anyway, thumb up!
so so true
Do you make a comment every function that you write? I have recently joined a company where I need to make a comment over every function.
+Albert Ozimek no, that would be a pretty dumb and arbitrary rule.
+Albert Ozimek many, if not most, functions that are well modularized and names are self documenting and does not need comments. In those cases, adding a comment adds no value, and just creates duplicate work, and information that risks going out of sync with the code.
great
Code is great way to describe software, except if were talking about javascript.
totally agree
"English is not very expressive" - MPJ, I am a huge fan and I have heard about 100 things you've said that were very helpful and very wise, but this does not make the list!
The English language has plenty of adjectives: an estimated 43,000!
And also >86,000 nouns...
(est. total words in English: 171,476...
est. portion that are adjectives: ~25%...
est. portion that are nouns: >50%)
en.oxforddictionaries.com/explore/how-many-words-are-there-in-the-english-language
2:28 ..like Javascript, C#, Java, C++, Perl... OK, maybe not Perl.
UML is good as a common language between non-coders, when you need to convey what a particular bit of code is doing in a logical, naturally-readable way.
My experience, however, is that non-coders don't really care how exactly it works... just that it does. And if it doesn't do something the way they expect, they're referred to as bugs.
Coders prefer to read code to understand... code. So ya, UML is useless.
+Chad Hynes you are bang on here. Explaining details of how something works to someone that doesn't need to know that just provides noise.