Looking for books & other references mentioned in this video? Check out the video description for all the links! Want early access to videos & exclusive perks? Join our channel membership today: th-cam.com/channels/s_tLP3AiwYKwdUHpltJPuA.htmljoin Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
I would argue there isn’t even craftsmanship: Most projects are outcome oriented cobbled together code messes - minimal effort, maximum output - because none-techs are managers, hence no budget, therefore the “hacker”. Like a carpenter skipping the measuring tape due to additional expense.
For a long time I have distinguished between programming and software engineering. Progamming is a small fraction of what a software engineer does. And also promoting the importance of having people with software understanding in management positions. Even electrical engineers in management positions often don't understand software.
I'm an engineer with 30 years experience, and 20 years ago I've leaving IT to industry. This is a marvellous explanation about what engineering really is.
The problem with that iterative approach (in software development and in real life and in optimization algorithms) is that if you don't look far ahead enough, you might end up in a dead end because you always optimize for the short term result. But in many real world situations, a straight line is not the shortest connection between two points.
Lets not confuse iterative approach with sheer ignorance. Even with great amount of planning you could end up in the dead end. If you will eventually reach dead end - you want to reach it sooner than later and take different path - here is why iterative approach works.
@@MisFakapek One can think of it as a rocket's minor course corrections. That's why the big-picture direction has to be defined clearly and the feedback is needed to compare the goal direction to the actual direction. From that you can derive a correction.
I am sympathetic to the idea of "engineering" in software development, but I think it requires a push towards professionalization. In Canada, "engineer" is a protected title, and IMO we should not even suggest that we in software development are engineers by using the "engineering" phrase until we are welcomed by the other branches of the broad field. I am interested in how professionalization happened in other fields where professionalization is found in some contexts and not in others to study how this might work. (I am thinking of the clinical vs. experimental psychology split, as well as professionalized vs. unprofessionalized chemists.)
You're using the word "professionalism" to describe government regulated certification. Certification is an entirely political and legal construct, used in order to put legal accountability on engineers or other specialized workers, rather than higher level decision makers. It _should_ also imply that the engineer veto higher level decisions, which is a plus, but that can also solved with standard contracts. In my eyes certification has nothing to do with how professional, rigorous or effective engineering is, or whether we can call something engineering in the first place. And for a Software Engineering certificate to have _any_ utility at all, it likely has to be domain specific for example Medical Software Engineering, Civil Software Engineering etc. Otherwise it doesn't provide the kind of guarantees that higher ups actually want.
@@clickrushI agree with this take. A lot of people assume that because there is some government verification around other engineering disciplines that they are somehow more professional, more rigorous, or more prestigious than other fields. There’s no government certification for being a physicist or mathematician, and those professions make up a significant portion of the smartest people on the planet. There is also this view that code is buggy and there are issue because there isn’t a government certificate. But that won’t fix the issue. There are a lot of software bugs because software is extremely complicated, especially compare to the other engineering disciplines. There is a lot more critical thinking, design, logic, and interlocking parts in even simple websites than there are in most other engineering projects. And even when you have truly complicated and state of the art revolutions in engineering, it’s generally been carried out by research scientists and PhD engineers.
@@prestonrasmussen1758 A pilot of the Wright Flyer has to deal with the tool he's using and a pilot of a modern passenger aircraft (of any size) has huge advantages because of the engineering effort put into that tool. Programmers are also somewhat in the hands of the tool makers and designers and even mathematicians who provide us some underlying theory. But the pilot also brings a lot to a modern airplane. They know a lot more than the Wright brothers and they have vastly more experience, including ground-based flight simulators. It's a different world and the accident rates reflect those 2 things combined.
illustrating iteration with a photo of a Spitfire and a Eurofighter is interesting. there was iteration between the Spitfire MkI, II, IV, VIII, IX, XIV, 19 and 22… but between the Spitfire, first-gen jets, Lightning, Phantom, Tornado, Eurofighter and JSF the steps weren't iteration so much as radical transformation each time
16:40 I don't mean to be picky ;) But the S IV-B stage of the Saturn V violates the single responsibility principle... it's not just for getting to Earth orbit... it also performs the trans-lunar injection burn.
Joking aside; "Single Responsibility Principle" is the pop-slogan version (that is often taken way too literally) of the core message to "Gather together those things that change for the same reason, and separate those things that change for different reasons" (#76 of "97 Things Every Programmer Should Know") Cohesion can't be reduced to "Single Responsibility".
@@PeerReyndersI'm massively disappointed... you took my perfectly adequate nerd trolling and turned it into a dull technical argument that Robert Martin would be proud of... if only it wasn't deciding his sacred doctrine.
Great talk, great philosophy about algorithms for general problem-solving and engineering. I get that why designing the hardware of the iPhone is a different kind of engineering, but I don't see how building rockets is a better model for engineering than building bridges. Mobile phones of the same model are almost identical, but no two bridges and no two rockets are the same. Probably a few thousand early bridges collapsed and a few tens of early rockets exploded before we learned how to build reliable ones. Yet it seems a few million software projects have already failed, and we keep failing at high rates. I think it would be worth investigating why is it harder to learn from previous failures in software engineering than in other disciplines.
Software doesn't usually fail all that hard at the execution end. At least not in completely unfixable ways. Most software dies because of business reasons (over time, over budget, poor market research, competition etc.).
@@lepidoptera9337 True, but I believe the execution is also a factor. I've seen companies hire less experienced developers to reduce costs, like hiring engineers at half the price, and then spending three times the time on it with an arguably worse end result. I think this phenomenon does exist and it must have at least some effect on the overall business success. Maybe it's just an eastern European thing.
@@tamashegedus7720 That is also a factor. In a talk Robert Cecil Martin (Uncle Bob) pointed out that in an exponentially growing industry most employees are necessarily young and inexperienced. I don't think that's the real problem, though. It's usually middle management and the C-level that make the wrong decisions that kill things. It's never the occasional bug in some junior developer code that makes a project go belly up.
100% agree with this. I did UWE's Software Engineering in the First Year it was available (back in the mists of time), which was the first Software Engineering course in the UK. At the time there was a lot of discussion between whether it was a BSc or a BEng as we were taught Scientific Method approach. It was not a surprise when Agile came along 10 years later, rewriting the PDCA Loop into something some of us had already been doing against the wishes of the idiot waterfall overlords. We were right they were and continue to be wrong. I've always argued there is a massive difference between Developers and Software Engineers: developers hack until it's just about works, Software Engineers build systems that are sustainable. Keep promoting the good fight. The Scientific Method and Good engineering practice saves sanity and also highlights those that are not good for the industry.
Excellent stuff, as always, @Dave. 'We should be ready to make mistakes as quickly and cheaply as we can': I completely agree with this. However, in my experience, the management/stakeholder support is crucial to make this happen. If failures are seen as wastage only, then this maxim is rendered ineffective. In several comments below, a 'Developer' or a 'Programmer' is being used in a not-so-subtle dismissive way. I don't know what that is so. A 'Software Engineer' has to be a 'Programmer' at heart, anyway. Put differently, how comfortable shall one be in finding an excellent Software Engineer who has not practised/been exposed to the aspect of 'Software Programming' as a skill?
I don’t agree we create new. Obviously some do. Software product development would tend to make something new, but I can’t think of an IT project that was creating something new. I wish it would be so, because those are mind numbing.
If you think about it, from the outset the speaker did not substantiate the idea that software development SHOULD be engineering. The rest of the talk falls flat without that justification.
Engineering is simply the occupation of achieving certain technical goals with reasonable cost and effort. It is based on a number of practically tested principles like KISS, design reuse, separation of concerns etc.. Bridges have the advantage that they can be calculated in detail. Software... not so much, except when standard algorithms are in play. OTOH, a blue screen of death is OK once in a while, blue water of death... usually not so much.
I suppose that to a certain extent, It's a matter of what you want. If you don't care about quality or maintainability or flexibility, then you can use any method. Maybe you'll get something you like, maybe not. In our society we've developed SCIENCE and ENGINEERING to study our world and to use processes and ideas to make things. It works. It's been refined quite a lot. So, some people want to use that to get what they want from their software.
Engineers don’t build bridges. They design them. You don’t see engineers pouring concrete or bolting connections, right? There’s another party that takes the design, figures out how much work it really takes and takes on the risk of bidding on the job and then has to actually build it. Software engineers have to do both the design and the build and oftentimes the bidding (in terms of time estimates).
"Every developer has very strong arguments why software development should be qualified as art, craft, trade, engineering, or science. When listening to all the reasons why software development is one thing or the other, many of the reasons make sense-some more than others, but they all make some sense." - Sandro Mancuso, The Software Craftsman. I really don't buy the "engineering better than craft" debate, it does not profit the community at all...
Looking for books & other references mentioned in this video?
Check out the video description for all the links!
Want early access to videos & exclusive perks?
Join our channel membership today: th-cam.com/channels/s_tLP3AiwYKwdUHpltJPuA.htmljoin
Question for you: What’s your biggest takeaway from this video? Let us know in the comments! ⬇
I love the phrasing of "production engineering" (civil engineering) vs. "design engineering" (software, product prototypes, etc.).
I would argue there isn’t even craftsmanship: Most projects are outcome oriented cobbled together code messes - minimal effort, maximum output - because none-techs are managers, hence no budget, therefore the “hacker”. Like a carpenter skipping the measuring tape due to additional expense.
I couldn't agree more
Indeed
Sadly, too true.
Sometimes moving closer to the target requires moving further away and changing direction.
For a long time I have distinguished between programming and software engineering. Progamming is a small fraction of what a software engineer does. And also promoting the importance of having people with software understanding in management positions. Even electrical engineers in management positions often don't understand software.
Fantastic content and delivery. I love the images as support for the words.
I'm an engineer with 30 years experience, and 20 years ago I've leaving IT to industry. This is a marvellous explanation about what engineering really is.
David you are wrong! Scrum guide does have word "code" :D The "Code" of conduct!
The problem with that iterative approach (in software development and in real life and in optimization algorithms) is that if you don't look far ahead enough, you might end up in a dead end because you always optimize for the short term result. But in many real world situations, a straight line is not the shortest connection between two points.
That's taking things a bit too literally. You still have an overall direction and ideas.
Lets not confuse iterative approach with sheer ignorance. Even with great amount of planning you could end up in the dead end. If you will eventually reach dead end - you want to reach it sooner than later and take different path - here is why iterative approach works.
@@MisFakapek One can think of it as a rocket's minor course corrections. That's why the big-picture direction has to be defined clearly and the feedback is needed to compare the goal direction to the actual direction. From that you can derive a correction.
I am sympathetic to the idea of "engineering" in software development, but I think it requires a push towards professionalization. In Canada, "engineer" is a protected title, and IMO we should not even suggest that we in software development are engineers by using the "engineering" phrase until we are welcomed by the other branches of the broad field. I am interested in how professionalization happened in other fields where professionalization is found in some contexts and not in others to study how this might work. (I am thinking of the clinical vs. experimental psychology split, as well as professionalized vs. unprofessionalized chemists.)
You're using the word "professionalism" to describe government regulated certification. Certification is an entirely political and legal construct, used in order to put legal accountability on engineers or other specialized workers, rather than higher level decision makers. It _should_ also imply that the engineer veto higher level decisions, which is a plus, but that can also solved with standard contracts.
In my eyes certification has nothing to do with how professional, rigorous or effective engineering is, or whether we can call something engineering in the first place. And for a Software Engineering certificate to have _any_ utility at all, it likely has to be domain specific for example Medical Software Engineering, Civil Software Engineering etc. Otherwise it doesn't provide the kind of guarantees that higher ups actually want.
@@clickrushI agree with this take. A lot of people assume that because there is some government verification around other engineering disciplines that they are somehow more professional, more rigorous, or more prestigious than other fields.
There’s no government certification for being a physicist or mathematician, and those professions make up a significant portion of the smartest people on the planet.
There is also this view that code is buggy and there are issue because there isn’t a government certificate. But that won’t fix the issue. There are a lot of software bugs because software is extremely complicated, especially compare to the other engineering disciplines. There is a lot more critical thinking, design, logic, and interlocking parts in even simple websites than there are in most other engineering projects.
And even when you have truly complicated and state of the art revolutions in engineering, it’s generally been carried out by research scientists and PhD engineers.
@@prestonrasmussen1758 A pilot of the Wright Flyer has to deal with the tool he's using and a pilot of a modern passenger aircraft (of any size) has huge advantages because of the engineering effort put into that tool. Programmers are also somewhat in the hands of the tool makers and designers and even mathematicians who provide us some underlying theory. But the pilot also brings a lot to a modern airplane. They know a lot more than the Wright brothers and they have vastly more experience, including ground-based flight simulators. It's a different world and the accident rates reflect those 2 things combined.
Thanks Dave! I think what you are saying is vital to the success of our industry!
illustrating iteration with a photo of a Spitfire and a Eurofighter is interesting. there was iteration between the Spitfire MkI, II, IV, VIII, IX, XIV, 19 and 22… but between the Spitfire, first-gen jets, Lightning, Phantom, Tornado, Eurofighter and JSF the steps weren't iteration so much as radical transformation each time
Wow! What an inspiring talk!
16:40 I don't mean to be picky ;) But the S IV-B stage of the Saturn V violates the single responsibility principle... it's not just for getting to Earth orbit... it also performs the trans-lunar injection burn.
Joking aside;
"Single Responsibility Principle" is the pop-slogan version (that is often taken way too literally) of the core message to
"Gather together those things that change for the same reason, and separate those things that change for different reasons"
(#76 of "97 Things Every Programmer Should Know")
Cohesion can't be reduced to "Single Responsibility".
@@PeerReyndersI'm massively disappointed... you took my perfectly adequate nerd trolling and turned it into a dull technical argument that Robert Martin would be proud of... if only it wasn't deciding his sacred doctrine.
Great talk, great philosophy about algorithms for general problem-solving and engineering. I get that why designing the hardware of the iPhone is a different kind of engineering, but I don't see how building rockets is a better model for engineering than building bridges. Mobile phones of the same model are almost identical, but no two bridges and no two rockets are the same. Probably a few thousand early bridges collapsed and a few tens of early rockets exploded before we learned how to build reliable ones. Yet it seems a few million software projects have already failed, and we keep failing at high rates. I think it would be worth investigating why is it harder to learn from previous failures in software engineering than in other disciplines.
Software doesn't usually fail all that hard at the execution end. At least not in completely unfixable ways. Most software dies because of business reasons (over time, over budget, poor market research, competition etc.).
@@lepidoptera9337 True, but I believe the execution is also a factor. I've seen companies hire less experienced developers to reduce costs, like hiring engineers at half the price, and then spending three times the time on it with an arguably worse end result. I think this phenomenon does exist and it must have at least some effect on the overall business success. Maybe it's just an eastern European thing.
@@tamashegedus7720 That is also a factor. In a talk Robert Cecil Martin (Uncle Bob) pointed out that in an exponentially growing industry most employees are necessarily young and inexperienced. I don't think that's the real problem, though. It's usually middle management and the C-level that make the wrong decisions that kill things. It's never the occasional bug in some junior developer code that makes a project go belly up.
100% agree with this.
I did UWE's Software Engineering in the First Year it was available (back in the mists of time), which was the first Software Engineering course in the UK. At the time there was a lot of discussion between whether it was a BSc or a BEng as we were taught Scientific Method approach.
It was not a surprise when Agile came along 10 years later, rewriting the PDCA Loop into something some of us had already been doing against the wishes of the idiot waterfall overlords. We were right they were and continue to be wrong.
I've always argued there is a massive difference between Developers and Software Engineers: developers hack until it's just about works, Software Engineers build systems that are sustainable.
Keep promoting the good fight. The Scientific Method and Good engineering practice saves sanity and also highlights those that are not good for the industry.
Excellent stuff, as always, @Dave. 'We should be ready to make mistakes as quickly and cheaply as we can': I completely agree with this. However, in my experience, the management/stakeholder support is crucial to make this happen. If failures are seen as wastage only, then this maxim is rendered ineffective.
In several comments below, a 'Developer' or a 'Programmer' is being used in a not-so-subtle dismissive way. I don't know what that is so. A 'Software Engineer' has to be a 'Programmer' at heart, anyway. Put differently, how comfortable shall one be in finding an excellent Software Engineer who has not practised/been exposed to the aspect of 'Software Programming' as a skill?
Thanks Dave !! Loved
Problem solving. With or without software.
#knowledge is power#experimetal#ideas
I don’t agree we create new. Obviously some do. Software product development would tend to make something new, but I can’t think of an IT project that was creating something new. I wish it would be so, because those are mind numbing.
If you think about it, from the outset the speaker did not substantiate the idea that software development SHOULD be engineering. The rest of the talk falls flat without that justification.
Engineering is simply the occupation of achieving certain technical goals with reasonable cost and effort. It is based on a number of practically tested principles like KISS, design reuse, separation of concerns etc.. Bridges have the advantage that they can be calculated in detail. Software... not so much, except when standard algorithms are in play. OTOH, a blue screen of death is OK once in a while, blue water of death... usually not so much.
I suppose that to a certain extent, It's a matter of what you want. If you don't care about quality or maintainability or flexibility, then you can use any method. Maybe you'll get something you like, maybe not. In our society we've developed SCIENCE and ENGINEERING to study our world and to use processes and ideas to make things. It works. It's been refined quite a lot. So, some people want to use that to get what they want from their software.
Engineers don’t build bridges. They design them. You don’t see engineers pouring concrete or bolting connections, right? There’s another party that takes the design, figures out how much work it really takes and takes on the risk of bidding on the job and then has to actually build it. Software engineers have to do both the design and the build and oftentimes the bidding (in terms of time estimates).
"Every developer has very strong arguments why software development should be qualified as art, craft, trade, engineering, or science. When listening to all the reasons why software development is one thing or the other, many of the reasons make sense-some more than others, but they all make some sense."
- Sandro Mancuso, The Software Craftsman.
I really don't buy the "engineering better than craft" debate, it does not profit the community at all...
Is this the socially acceptable way of saying Indian contractors are terrible?
Is this the socially acceptable way of saying African workers are aggressive?