Great talk. Thank you. In industry where you can call someone senior after 3 years of learning the basics I don't really be suprised that we get it wrong so often.
Excellent, more in the minute 17 when he talks about one particular technology and implementation and you properly explain him that you are going one step further of abstraction Marvelous!
I had the incredible luck to learn programming in a shop that practiced something very close to what you describe as Continuous Delivery down to having a group devoted to what is now called DevOps. A decade before I started in the 70s, they worked with IBM to create CICS and maintained an in-house version called Pronto. I learned to write code for distributed systems by fixing production bugs and rewriting parts that suffered from the entropy of earlier misguided fixes. The data was distributed over time, not space. We were the electric utility for Chicago and surrounding suburbs. The customer dataset was so large that it took a week of nightly runs to process the entire thing and everything happened in cycles of various lengths. Anyway, I just wanted to point out that CD is a great but not necessarily new idea.
Dave, you are really in your element here. Very articulate, noticeably more than even in your own videos. Perhaps you could do more of a question and answer format (you can edit as much as you want to keep if flowing for your final cut), and get someone else to handle the recording so you are not constantly aware of it.
Hi Dave: I would love to hear your answer to a question that has been bothering me for a long time. What is the fundamental problem that "software design" solves? For a long time, I have been thinking about the lack of continuing education and software design training in the software industry. It bothered me that I needed about 10 years and some good luck before I really learned how to do software design well (and another five years or so to understand it well enough to be able to explain to someone else how it works and why it is important). I have often wondered why there are not better materials out there for the apprentice software developer. I was equal parts surprised and relieved to hear you and Simon discuss that same problem in the middle of this interview. When I started thinking about how to fill the gap, I was forced to think about the fundamentals of software design--starting with why do we need design? Here is my conclusion: Software design is the only tool that we have to try to constrain entropy. As briefly as I can, here is how I landed there: Computers are state machines. There is a wide variety of state transitions that are permitted by the computer, the set of allowable state transitions is the instruction set. The number of possible states and the number of possible state transitions is each so large that both of them are effectively infinite. In other words, the system is unconstrained. The unconstrained nature of the machine makes it a very powerful tool because it can be used to represent a very wide variety of problems. However, for a specific problem only a vanishingly small number of machine states is valid. A bug causes the system transition to a random invalid state (random in the sense that the bug can cause any state transition allowed by the instruction set). Over time, bugs move the state of the system further and further toward the most common states and away from the small number of valid states. In other words, bugs raise the entropy of the system state. Software design puts rules in place that constrain the allowable state transitions to a set small enough for a human to understand. Having such constraints makes the problem easier to understand and also makes bugs (violations of the constraints) easier to identify and understand. From this I define Sofware Design (as a verb) to fundamentally be the process of creating a set of constraints that serve to reduce the scope of the problem within a given context by restricting the set of valid state transitions available to the software developer. Thanks for the books (Continuous Delivery changed the way I think about my career) and the RUclips channel (I reference it frequently to my colleagues). You are doing good work.
I think that software design is primarily there to allow us to continue to change the code. Which is another way of say to reduce, or at least constrain, the entropy. The hallmark of high quality design is that the code based is easy to change, safely. That is really the topic of my "Modern SW Engineering" book.
Thank you for the video. During whole video I have smile in my face because you named a bunch of things that I see are wrong in our industry. I totally agree with everything you said. If I can add just one thing the rootcause of all of the issue is lack of proper education.
I'd like to add my opinion that the negative comparison between software "engineering" and the other kinds of engineering needs to be a little adjusted. Not because the software engineering is fantastic (of course is not), but because the quality of the rest of engineering is also really debatable. The comparison with buildings come in discussion over and over. I've seen a ton of new buildings with cracked walls, the miracle of architecture called Stata Building at MIT has serious issues of various kinds, jumping industry there are decades of issues with AlfaRomeos (not my personal experience), Teslas have some really funky (and maybe not that important) issues like not closing the trunk very well (personal experience), and so on. Basically is not that software engineering sucks and the rest of "engineerings" are so much better, but it seems that everything relevant and worth trying will probably have problems. And software is definitely an industry which tries to do new stuff all the time (and when is doesn't, it's fairly ok, I don't think there were many bugs in Wordle)
I didn't see any interruptions, but a skilled moderator ensuring a fluid, broad and lively discussion. If you wanted more detail from Simon and Dave, they both have a number of technical lectures available here on RUclips
I don't think I said that it is about architects, because I don't believe that it is. Do check out this week's upcoming episode, released on Wednesday, which talks about this in more detail.
@@ContinuousDelivery Thanks for the reply Dave. True, you didn't mention it. I just got this impression from the initial parts of the video. Looking forward to your new episode!
Great talk. Thank you. In industry where you can call someone senior after 3 years of learning the basics I don't really be suprised that we get it wrong so often.
Excellent, more in the minute 17 when he talks about one particular technology and implementation and you properly explain him that you are going one step further of abstraction
Marvelous!
I had the incredible luck to learn programming in a shop that practiced something very close to what you describe as Continuous Delivery down to having a group devoted to what is now called DevOps. A decade before I started in the 70s, they worked with IBM to create CICS and maintained an in-house version called Pronto. I learned to write code for distributed systems by fixing production bugs and rewriting parts that suffered from the entropy of earlier misguided fixes. The data was distributed over time, not space. We were the electric utility for Chicago and surrounding suburbs. The customer dataset was so large that it took a week of nightly runs to process the entire thing and everything happened in cycles of various lengths. Anyway, I just wanted to point out that CD is a great but not necessarily new idea.
Dave, you are really in your element here. Very articulate, noticeably more than even in your own videos. Perhaps you could do more of a question and answer format (you can edit as much as you want to keep if flowing for your final cut), and get someone else to handle the recording so you are not constantly aware of it.
Thanks, and thanks for the suggestion. We do a Q&A show for Patreons at the moment, but it's a thought.
Hi Dave: I would love to hear your answer to a question that has been bothering me for a long time. What is the fundamental problem that "software design" solves?
For a long time, I have been thinking about the lack of continuing education and software design training in the software industry. It bothered me that I needed about 10 years and some good luck before I really learned how to do software design well (and another five years or so to understand it well enough to be able to explain to someone else how it works and why it is important). I have often wondered why there are not better materials out there for the apprentice software developer. I was equal parts surprised and relieved to hear you and Simon discuss that same problem in the middle of this interview.
When I started thinking about how to fill the gap, I was forced to think about the fundamentals of software design--starting with why do we need design? Here is my conclusion: Software design is the only tool that we have to try to constrain entropy. As briefly as I can, here is how I landed there: Computers are state machines. There is a wide variety of state transitions that are permitted by the computer, the set of allowable state transitions is the instruction set. The number of possible states and the number of possible state transitions is each so large that both of them are effectively infinite. In other words, the system is unconstrained. The unconstrained nature of the machine makes it a very powerful tool because it can be used to represent a very wide variety of problems. However, for a specific problem only a vanishingly small number of machine states is valid. A bug causes the system transition to a random invalid state (random in the sense that the bug can cause any state transition allowed by the instruction set). Over time, bugs move the state of the system further and further toward the most common states and away from the small number of valid states. In other words, bugs raise the entropy of the system state. Software design puts rules in place that constrain the allowable state transitions to a set small enough for a human to understand. Having such constraints makes the problem easier to understand and also makes bugs (violations of the constraints) easier to identify and understand.
From this I define Sofware Design (as a verb) to fundamentally be the process of creating a set of constraints that serve to reduce the scope of the problem within a given context by restricting the set of valid state transitions available to the software developer.
Thanks for the books (Continuous Delivery changed the way I think about my career) and the RUclips channel (I reference it frequently to my colleagues). You are doing good work.
I think that software design is primarily there to allow us to continue to change the code. Which is another way of say to reduce, or at least constrain, the entropy. The hallmark of high quality design is that the code based is easy to change, safely. That is really the topic of my "Modern SW Engineering" book.
Thank you for the video. During whole video I have smile in my face because you named a bunch of things that I see are wrong in our industry. I totally agree with everything you said. If I can add just one thing the rootcause of all of the issue is lack of proper education.
My ears and eyes are ready!
Great Talk
I'd like to add my opinion that the negative comparison between software "engineering" and the other kinds of engineering needs to be a little adjusted. Not because the software engineering is fantastic (of course is not), but because the quality of the rest of engineering is also really debatable. The comparison with buildings come in discussion over and over. I've seen a ton of new buildings with cracked walls, the miracle of architecture called Stata Building at MIT has serious issues of various kinds, jumping industry there are decades of issues with AlfaRomeos (not my personal experience), Teslas have some really funky (and maybe not that important) issues like not closing the trunk very well (personal experience), and so on. Basically is not that software engineering sucks and the rest of "engineerings" are so much better, but it seems that everything relevant and worth trying will probably have problems. And software is definitely an industry which tries to do new stuff all the time (and when is doesn't, it's fairly ok, I don't think there were many bugs in Wordle)
Great talk!
Great talk, but I wish Hannes had not interrupted as much
agreed, he is super-disturbing - apart from that, an interesting talk
I didn't see any interruptions, but a skilled moderator ensuring a fluid, broad and lively discussion. If you wanted more detail from Simon and Dave, they both have a number of technical lectures available here on RUclips
Toooo much insist on architects role. It's about architecture not architects
I don't think I said that it is about architects, because I don't believe that it is. Do check out this week's upcoming episode, released on Wednesday, which talks about this in more detail.
@@ContinuousDelivery Thanks for the reply Dave. True, you didn't mention it. I just got this impression from the initial parts of the video. Looking forward to your new episode!