We are currently releasing older YOW! videos to serve as a valuable archive, preserving historical content. It is possible that a video is perceived as outdated. We believe it offers insightful glimpses into the past, enriching our understanding of history and development.
The Practical Guide to Structured Systems Design - Meilir Page-Jones; Modern Structured Analysis - Edward Yourdon; Complete Systems Analysis - James & Suzanne Robertson; Developing Structured Systems - Brian Dickinson. Old School
Great talk loved it, but one thing the guys who uploaded didn't consider is that you can't scan the QR code at the end of the video simply because it's blocked by other video suggestions...yaaay
Great presentation! I've been dealing with design docs for years and wrote about this subject, Not enough is being done - many SE still choose not to properly design their work beforehand. Evolutionary design is good when you are not sure what is being done - or when something is going to change soon. Using the YAGNI principle you don't need to design more than you know currently. If you do - put it in the design because these aspects are going to answer the future SE whom would ask "Why did they do that". The design doc should be the answer .
Come from manufacturing industry. The idea of not having at least a guiding model (blueprint) sounds completely absurd to me. I very much like that this method is incredibly similar what I decided on, myself. You're not trying to micromanage every aspect, but not choosing a route just means you're driving around willy-nilly and likely wasting time/money having to change routes after having already done work.
Depends on which drawbacks you're finding problematic. If your primary problem would be for example coworkers that aren't willing to put in even the 15 minutes required to learn a minimal subset of UML then it's not the diagramming method that's the problem.
Not doing design is a backslash to having Enterprise architected fizzbuzzes caused by the OO software "design". Like we currently know the refactoring book can be replaced by a lambda expression.
1 decomposition techniques 2 modularity Workshops crc Why drsogn 1 enough upfront design To uncover unknown unknowns Notion of direction Teams rush in stuff Forget about (0really) obvious thinge All about technical leadership(0eotk with, not follow necessarily Conversations High level superficial upfront design Micro service architecture
![Design is [Business] - The Merging Reality of Design and Business](http://i.ytimg.com/vi/z9I9hMHIouo/mqdefault.jpg)
We are currently releasing older YOW! videos to serve as a valuable archive, preserving historical content. It is possible that a video is perceived as outdated. We believe it offers insightful glimpses into the past, enriching our understanding of history and development.
The Practical Guide to Structured Systems Design - Meilir Page-Jones; Modern Structured Analysis - Edward Yourdon; Complete Systems Analysis - James & Suzanne Robertson; Developing Structured Systems - Brian Dickinson. Old School
Great talk loved it, but one thing the guys who uploaded didn't consider is that you can't scan the QR code at the end of the video simply because it's blocked by other video suggestions...yaaay
Great presentation!
I've been dealing with design docs for years and wrote about this subject,
Not enough is being done - many SE still choose not to properly design their work beforehand.
Evolutionary design is good when you are not sure what is being done - or when something is going to change soon.
Using the YAGNI principle you don't need to design more than you know currently.
If you do - put it in the design because these aspects are going to answer the future SE whom would ask "Why did they do that".
The design doc should be the answer .
Come from manufacturing industry. The idea of not having at least a guiding model (blueprint) sounds completely absurd to me. I very much like that this method is incredibly similar what I decided on, myself. You're not trying to micromanage every aspect, but not choosing a route just means you're driving around willy-nilly and likely wasting time/money having to change routes after having already done work.
What's a good alternative to UML and CASE considering those things have serious drawbacks
Depends on which drawbacks you're finding problematic. If your primary problem would be for example coworkers that aren't willing to put in even the 15 minutes required to learn a minimal subset of UML then it's not the diagramming method that's the problem.
I see the IGN rating system has made its appearance. 7:37
Very good content
Not doing design is a backslash to having Enterprise architected fizzbuzzes caused by the OO software "design". Like we currently know the refactoring book can be replaced by a lambda expression.
en.wikipedia.org/wiki/Erhu, the 2 string guitar might have worked.
1 decomposition techniques
2 modularity
Workshops crc
Why drsogn
1 enough upfront design
To uncover unknown unknowns
Notion of direction
Teams rush in stuff
Forget about (0really) obvious thinge
All about technical leadership(0eotk with, not follow necessarily
Conversations
High level superficial upfront design
Micro service architecture