Is Designing Different To Coding?

Рет қаралды 20,258

Жыл бұрын

In software development, what is the relationship between “Code” and “Design”? Is code the responsibility of one set of people, and design another, or are these part of a continuum in software design where code, design and architecture are essential just different aspects of the same activity? Software design patterns are realised in code, and programming can be thought of as merely how we capture and communicate our design decisions.
In this episode, Dave Farley, author of “Continuous Delivery” and “Modern Software Engineering" explores this relationship between software design and describes how this is less about coding vs design or designer vs developer and much more that design is always fundamental to what we do as software developers.
-----------------------------------------------------------------------------------
⭐ PATREON:
Join the Continuous Delivery community and access extra perks & content!
JOIN HERE ➡️ bit.ly/ContinuousDeliveryPatreon
-------------------------------------------------------------------------------------
👕 T-SHIRTS:
A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!
🔗 Check out their collection HERE: bit.ly/3vTkWy3
🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery
-----------------------------------------------------------------------------------
🖇 LINKS:
“Do Programming Languages Affect Productivity 1?” ➡️ www.researchgate.net/publicat...
“Do Programming Languages Affect Productivity 2?” ➡️ www.cincomsmalltalk.com/main/...
“What is Productivity?” ➡️ / the-third-decade-of-pr...
“Entropy”, Wikipedia ➡️ en.wikipedia.org/wiki/Entropy
-------------------------------------------------------------------------------------
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is available as paperback, or kindle here ➡️ amzn.to/3DwdwT3
and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
📖 "Continuous Delivery Pipelines" by Dave Farley
Paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 “The DevOps Handbook”, by Gene Kim, Jez Humble, Patrick Debois & John Willis ➡️ amzn.to/2LsoPmr
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Roost, An Ephemeral DevOps Platform, automates your DevOps pipeline. It creates ephemeral DevOps environments on-demand or based on pull requests. Roost reduces DevOps complexities and shortens release cycles with fewer engineers. ➡️ bit.ly/CD2Roost
Tricentis is an AI-powered platform helping you to deliver digital innovation faster and with less risk by providing a fundamentally better approach to test automation. Discover the power of continuous testing with Tricentis. ➡️ bit.ly/TricentisCD
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com

Пікірлер: 61

@ContinuousDelivery Жыл бұрын

Try our Free TDD Tutorial: courses.cd.training/courses/tdd-tutorial

@driversteve9345 Жыл бұрын

Your book "Modern Software Engineering" isn't available in the US on Amazon?

@vanivari359 Жыл бұрын

I had to firefight multiple large projects, all suffered at their core from this problem. Unstructured code of basically unsupervised junior developers which was not maintainable anymore after just a year. Side-effects everywhere based on the error described in the first 10 minutes. Off course those teams all worked super agile, all the scrum rituals, all the JIRA plugins, they even hired agile consultants to do scrum even more scrummy, some even created clean code. But for some "strange reason" productivity just got worse and worse and worse - until they brought in experienced architects who started to structure the code, create modules, interfaces etc. This stuff is indeed THE JOB.

@YonoZekenZoid Жыл бұрын

as an engineer with 20 years on the job, I found myself giggling, then laughing at the example with "code 1" and "code 2" in it. I've seen this same kind of "approach" too many times. I remember, at one company, there was a JavaScript file, with functions called GetSnippet1, GetSnippet2, etc, with about 10 lines of code each, that basically performed an RPC-style call to the server with instructions for doing any task. each function had the corresponding GetSnippetCallback, which was about 10 lines of code too. they were largely identical, and the file was over 10k lines long. whenever you wanted to implement some new functionality, you'd write your code on the server side, and then basically copy and paste a GetSnippet and GetSnippetCallback pair. I once got reprimanded for calling mine, GetSnippetWithCheeseAndOnions and GetSnippetWithCheeseAndOnions, in protest.

@petropzqi Жыл бұрын

Currently reading modern software development. When I'm reading it I can hear how David is standing in front of me telling me to start think about design and hoe its key to success. I really enjoy the book and can't wait until I can start to read continuous delivery.

@sewera.account Жыл бұрын

I have the same experience. I can hear this book read by Dave to me when I'm reading!

@jimrobison772 Жыл бұрын

Same, I read the book and heard his voice throughout

@BestHKisDLM Жыл бұрын

Sadly the audio book is narrated very differently. It’s not Dave but a woman voice actor and I can’t focus on it since I still translate it with Dave’s voice.

@bernardobuffa2391 Жыл бұрын

my favorite phrase of the video: every line of code you write, you are taking design decisions, even unintentionally.... Pure Gold!

@ContinuousDelivery Жыл бұрын

Glad you liked it!

@jonathansaindon788 Жыл бұрын

Exactly, for example, coding to concrete classes you are choosing to make it harder to unit test.

@bernardobuffa2391 Жыл бұрын

@@jonathansaindon788 Ideed. I never practised this literailly, but, in theory, you can imagine a whole software system based on interfaces (I mean Java interfaces or ObjectiveC protocols)

@ssssssstssssssss Жыл бұрын

I think coding is a part of design. When I design software I often write out code samples to get a feeling for how it will be used and update if it is hard to use. And I go back and forth between diagramming, writing pseudocode, considering use cases and writing code. I don't think of them as separate at all.

@Dasein23 Жыл бұрын

You’re right. Coding IS design.

@jimhumelsine9187 Жыл бұрын

I loved this video. I design with diagrams, mostly UML class diagrams. I'm a big proponent of design patterns, so my design tends to be structured with these ideas. I do a lot of thinking about the code while it's still in diagram form. I move things around, change their relationships, think a bit about abstraction, etc. Then when I'm satisfied with the design, I start the implementation using TDD to keep me honest. If I've done this well, then the implementation goes pretty fast. The code practically writes itself and it tends to just work. I also find that behavior tends to "scream" where it belongs in the design. Not only does this make the initial design a bit more obvious, but it makes enhancements easier too. And if the new behaviors don't quite fit the original design model, it's usually fairly easy to modify, since we're starting with a modular design. CAVEAT: This has worked very well for me for adding new behaviors either in a green field environment or in a section of code that I can carve off. But I haven't quite figured out how to apply it directly into legacy code. Legacy code seems to have too much baggage associated with it.

@petebrown6356 Жыл бұрын

Code is just the implementation of the design, the language used is based on requirements. I was sitting here thinking, abstract UI from business logic from persistence, use well defined interfaces, with applicable design patterns like singletons, factories, etc. so you have good separation of concerns and force people to use your code as intended, moving toward service oriented architectures....then you basically do exactly that :)

@jezzamobile Жыл бұрын

Helpful video, appreciated 👍

@yapdog Жыл бұрын

Yep. We were separated at birth, Dave. I'm sure I'd already mentioned to you that for a number of years I've been deving an OS for creators. I originally came up with the idea in ~2002-03 and have been evolving it since. It was refreshing to come across your channel a while back; I feel I've been on the right track all this time every time i watch your vids, especially when you present a name for these concepts. It's validating. Thanx, m'man, for creating such a fantastic channel.

@Alanblumenmkt Жыл бұрын

Everytime I watch your videos, i understand why coding in Germany is so difficult, we make all posible mistakes here.

@waltermelo1033 Жыл бұрын

Learning UX Design. helped me a lot to think more about the problem I'm going to solve. and, I applied it back to coding (and no-coding too) and it improved the quality of my projects greatly. Those courses around Design, they focus on planning about the problem not on tools for the job. and I think that is something really lacking on Development couses. we get so lost on frameworks, syntax, no one teaches how to actually design a solution that is scalable and you can make changes fast without breaking it.

@ContinuousDelivery Жыл бұрын

I agree with you about the mis-focus on tools and tech over design. Design is the whole ball game for me. I make no distinction between architecture, coding, development and design really. The tools are the tools, the mechanisms that we use to realise a design, and however skilled in tool use you are as a developer, it is meaningless if you lack skill in design, conversely, if you are skilled in design, you can achieve success even with a cursory understanding of tools and frameworks. Great dev needs both, but still design first IMO.

@juliocesarcoriochoa9108 Жыл бұрын

I'm a beginner developer, and I appreciate your advices. Now I can see how useful is the design before the code.

@ContinuousDelivery Жыл бұрын

Not just "design before", sure think a bit about your design, but also monitor it as it evolves and correct it when you learn new things - TDD helps a lot with this!

@juliocesarcoriochoa9108 Жыл бұрын

@@ContinuousDelivery Woow, Thanks a lot for your answer and recommendation, I'll start learning the Domain Drive Design.

@juliocesarcoriochoa9108 Жыл бұрын

Yesterday I was watching a video about creating eCommerce from GOTO and I notice that at the beginning of the video, it uses Event-Driven. I started to review and I have some interesting differences, but I would like to know what is your point of view about that.

@markhathaway9456 Жыл бұрын

Software is where the complexity and uncertainty and limited resources of the real world meets hardware. Programmers think a REPL is ideal to test and fix and test and fix, but a process to design with knowledge of the use-cases, resource limitations, etc. adds a lot to what the programmer should write. A programmer can work within their narrow confines, but the software will step onto the stage of the real world and there it's tested harshly.

@Flamechr Жыл бұрын

always enjoying these video's about why there is something call best practics. But it also reminds me about people that I work with that may benefit from these videos ;-).

@EnVideoZone Жыл бұрын

Sage Stuff. Thank you

@cccc2740 Жыл бұрын

Very good video..but its very difficult to do all this with huge legacy codebases which are what we developers mostly get to work with...you cant have mental model of huge systems to decide where to change the code...documentation, diagrams etc are rarely there to help..

@russellshahenian2357 Жыл бұрын

Hi Dave, thank you for all your work here. I appreciate it. Got your book. Question: does your perspective also applied to embedded software engineering?

@ContinuousDelivery Жыл бұрын

Yes, and is used in some leading examples, Tesla, SpaceX and Volvo Trucks to name a few. I have worked with a team to build a deployment pipeline to support FPGA programming and another to build firmware, and device drivers for complex scientific instruments.

@RewdanSprites Жыл бұрын

"The pinky and the brain, the pinky and the brain. One is a genius, the others insane". Great video! I was certainly happy to hear these viewpoints today as I'm looking at some code I wrote two years ago and was thinking "Why did I do it this way?". Future you will not be happy if you take hacky approaches.

@looseshape Жыл бұрын

I'd be interested in your opinions on how these principles may be affected by the need for high performance in data-intensive applications. How would you approach that problem? Not just in one area and a bottleneck profiling scenario, but when the application is dealing with a lot of data, a lot of the time, e.g. statistical and mathematical operations over large amounts of data in multiple data structures over multiple use cases.

@ContinuousDelivery Жыл бұрын

Actually you are describing the kind of systems that I spend the last couple of decades building, and forming these views. I don't think these principles change at all, in fact I think that the need for them is significantly enhanced in building very high performance systems. You achieve High performance by maximising the work done, while minimising the effort needed to do that work. You achieve that by keeping the code as simple as possible in any given context and minimising comms overheads, that speaks to modularity & cohesion and excellent abstraction. I was involved in build, and designing, one of the world's highest performance financial exchanges, and while doing so we came up with the idea of "Mechanical Sympathy" as one of our "guiding principles" that is developing our system in sympathy with how the underlying hardware works. So by good separation of concerns, each part focus on one part of the problem could be optimised, tailored, to extract the most from the hardware.

@aslkdjfzxcv9779 Жыл бұрын

love it!

@guilherme5094 Жыл бұрын

👍Thanks.

@Haasje_X Жыл бұрын

Love the shirt! Pinky and the Brain rule :)

@lucianoaugustoyamane Жыл бұрын

Valeu!

@ContinuousDelivery 10 ай бұрын

Thank you!

@siyaram2855 Жыл бұрын

What are your thoughts on the essay Coding won't exist in 5 year. Waiting for your reply. 🙏

@mgbrown09 Жыл бұрын

Design is about taking course grain requirements and breaking them into smaller requirements. As a result there is always a hierarchy of designs. Coding represents the lowest level of design. As an industry we are really bad at expressing the higher levels of design. Most of the high level designs I see, if there even is one, are in Word documents. We tried UML, but it seems to have fallen out of favour these days, I think because people tried to get too detailed with it and maybe our "CAD" software wasn't great.

@drewwilson8756 Жыл бұрын

So designing is loose coding for code?

@timseguine2 Жыл бұрын

Where I work we have a lot of non software engineers in other disciplines and many of them have passable coding ability for example in python and matlab. But they are ironically the most annoying people to talk to about software because all of their experience with programming is in single file source code bases with less than a couple 1000 lines of code. From that a lot of them seem to have come to the conclusion that "programming is easy". And yes, I agree it is easy. at that scope it is extremely easy. But that was never the point.

@aaaowski7048 Жыл бұрын

I understand better why front enders NEED oop. If mr. CD has to reiterate such basic concepts as encapsulation, abstraction, modularity >>>THE IMPORTANCE OF HAVING A MENTAL IMAGE OF THE SYSTEM YOURE WORKING WITH (mental facepalm) it speaks volume about the level of competence in the industry. I'm so glad i dodged working in a corporate setting. that would have made me soooo miserable... Learning systems and languages that always end up standing in my way, because OTHERS cant stop eating paint... I apply most principles if not all principles presented in this video by default. Its just common sense and good coding practices that arise from experience. I would have thought that corporate cures someone from their bad habits on day one, by the means of a metaphorical smack to the face named rigid hierarchy. Guess i was wrong. On so many things. I guess AGILE is actually good for the industry. But where i was right is that it IS a stand-in for a company's organizational and technological know how. Oh my god. And these people are paid so much. And they're so proud. I really am thankful i dodged that environment. Thats an insta-burnout for the likes of me.

@ContinuousDelivery Жыл бұрын

Nothing to do with "Front Enders" I am afraid. A lot of code in big orgs, and small, suffers from this lack of design focus in my experience. Take a look at a few open source projects to see what I mean.

@aaaowski7048 Жыл бұрын

@@ContinuousDelivery Hmm, so its a common evil then... I would have thought that having to deal with more complex systems "teaches" an individual to be more orderly, more practical. And of course, i would expect that a full on corporate asset would provide a better quality of work than i do... When i think of it, working with C forced me to be orderly in my code. Do you think training might be to blame, or is it just part of human nature to be messy?

@PeerReynders Жыл бұрын

@@aaaowski7048 “But programming now isn't so much like that, said Sussman. Nowadays you muck around with incomprehensible or nonexistent man pages for software you don't know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job,…” -international lisp conference -- day two (2009)- Programming in-the-small by plumbing together some libraries or filling holes in some framework doesn't develop a sense of design that one can get from building something just from primitives. Having a sense of design in-the-small makes it easier to develop it in-the-large for systems.

@rokatainment Жыл бұрын

I have the feeling that you cross the border to architecture quite at some points. Probably you can point out the differences somehow clearly. I often have the feeling people are not that aware of the difference.

@ContinuousDelivery Жыл бұрын

I don't really think that there is a difference between code, design & architecture. It is all a single continuum. The role of "architect" sometimes muddies these waters, because sometimes, very wrongly in my view, architects aren't close to the code. There is more to architecture than only code, but then there is more to writing code than only code too. As one becomes more experienced, you may end up dealing with design at higher and higher levels of complexity, and that may lead you to abstract more, but architects who only understand things at an abstract level are, in my opinion, skating on very thin ice. So, for me, it is ALL DESIGN really, just at different resolutions of detail.

@rokatainment Жыл бұрын

@@ContinuousDelivery assigning an "dedicated architect" to multiple teams to make top-down decissions on products he/she is not really involved in, is an anti-pattern imho. For a lot of different reasons. Those tend to be some kind of "enterprise architects" in large orgs or so. I don't like that approach. When I talk about "doing architecture" I mean basically taking a step back and thinking about non-functional requirements to the system, and evaluating the "real needs" of the stakeholder. Documentation should be part of that, for the important things. Thus architecture shapes the design in more general way with crosscutting concepts and different views on the same system for different stakeholders. However, this should not be always one single person, but instead the whole team taking the responsibility for these cases. Must not always be the same one but the team may self decide how to handle that responsibility. So it's more like "a hat" wandering around in the team. As experienced developer I have learned to say no to a lot of request that would lead to software quality limbo. Most ending up in unmaintainable code. It was not always like this. Juniors should learn by taking responsibility and have a chance to prove themselves.

@bernardobuffa2391 Жыл бұрын

Pinky is the urged-programmer and the Brain is the designer! LOL

@guilherme5094 Жыл бұрын

🤣👍!

@ThomasWSmith-wm5xn Жыл бұрын

Pinky and the Brain shirt! Legendary level nerd reference.

@disgruntledtoons Жыл бұрын

Sure the two are different. Coding is when you find out whether your design is any good.

@LucTaylor Жыл бұрын

Oh no... I'm a straight line thinker :'(

@ContinuousDelivery Жыл бұрын

You can work on it 😉😎

@adambickford8720 Жыл бұрын

Context is king. Even everything dave is suggesting is a bad choice if the app is being maintained by nothing but junior devs (yes, this happens). They won't understand the tradeoffs and unknowingly compromise the design, losing all of the advantages while keeping the disadvantages and compounding them. A 'VB' solution might actually be the right call.

@ContinuousDelivery Жыл бұрын

I don't agree. If the junior devs always chose the option that increased modularity, cohesion had a better separation of concerns, abstraction that hid implementation detail and preferred looser-coupling, then they would NEVER build a big ball of mud. The design from juniors following these guides would not be perfect, better devs will create better designs than worse, but the junior's design will be better following these guidelines than without.

@adambickford8720 Жыл бұрын

@@ContinuousDelivery I mean with little to no mentoring. The senior devs were "too busy" on "more important" projects. Yes, this happens. I've seen jr devs handed a 'simple' java MVC rich client w/o understanding OO. The first thing they did was start making things static to "gain access" as DI was 'too complicated and overkill'. That's *far* worse to me than just having it be either case consistently. I'd rather maintain a VB app clearly written by juniors than cargo culting juniors gone wrong, even if it "shouldn't have".