Links to referenced books can be found in the video description. Link to Fred Brooks' original article "No Silver Bullet Essence and Accidents of Software Engineering": ieeexplore.ieee.org/document/1663532 Wikipedia: en.wikipedia.org/wiki/No_Silver_Bullet
Systems Engineering is got to be the most difficult way to solve problems but the most effective. This is because "Systems" are of the highest order when it comes to the creation of things, which is just a basic fundamental in defining "Engineering". So, the thinking should be toward the lowest order of creating things which is the basic unit of a thing, be it "atom" or "cell" or anything at the very foundational level. Thank You. My understanding of what was discussed towards solving problems.
13:30 Iteration isn't enough though... you might get stuck in a local maxima. You need broader knowledge and synthesis to know how far back down a mountain you will need to descent, i.e., how fundamental your error is.
Tools do not define success, they only progress our reaching a solution to a problem. So, it is about the understanding of the problem and the way we use the tools to solve the problem. We are not trying to solve problems using the tools better because new, better tools become crafted later on, which helps us to progress faster and better in our solution to the problem.
If I had to summarize, Modern Software Engineering presents what I call as the "Dual Challenge": Embracing New (& often complex) architectures leveraging Digital technology
I mostly agree with Dave on the subject of technology specific books... but there's always a couple of exceptions to the rule.... I've always thought Douglas Crockford's "the Good Parts" was vital reading if you're a JS developer or not just because of the ideas it smuggles across in it's technology specific text.
I get what you mean but on the 10X idea: No 10X improvement? Please. Sure there is. In fact there are loads of examples in specific markets and they are not 10X but 350X, 800X, ... Here is the idea: Remove all management and keep a couple of liaisons towards the clients. In other words, minimise the distance between engineer and client and stop polluting the processes with useless crap. In engineering there are certain ideas you can try out to see what results in a better efficiency... and 5% of them actually work. But 100 managers create 100 ideas. If you have 100 ideas in trial phase, it is impossible to measure which one works and which does not. So they assume all of it works. Couple of years pass, and they eventually end up with thousands of ideas which is dragging the entire company to a crawl. Naturally, you throw more engineers at the problem (which "need managing") and you end up with a company of 2000 people before a single engineer comes along and completely uproots your entire market with one single elegant open source github entry. Who is to blame? ... An engineer created the disruptor, so the engineers are at fault, naturally. If only we could have these 350X developers ...
Links to referenced books can be found in the video description.
Link to Fred Brooks' original article "No Silver Bullet Essence and Accidents of Software Engineering":
ieeexplore.ieee.org/document/1663532
Wikipedia: en.wikipedia.org/wiki/No_Silver_Bullet
Systems Engineering is got to be the most difficult way to solve problems but the most effective. This is because "Systems" are of the highest order when it comes to the creation of things, which is just a basic fundamental in defining "Engineering". So, the thinking should be toward the lowest order of creating things which is the basic unit of a thing, be it "atom" or "cell" or anything at the very foundational level. Thank You. My understanding of what was discussed towards solving problems.
Amazing conversation between professionals. Loved how open they spoke. Great video🦾🦾
J
.., kgtgx
u
LgSa byra b big a CD
Loved the discussion and banter between experienced software engineers passionate about the subject. Thank you.
13:30 Iteration isn't enough though... you might get stuck in a local maxima. You need broader knowledge and synthesis to know how far back down a mountain you will need to descent, i.e., how fundamental your error is.
This was good to watch
Tools do not define success, they only progress our reaching a solution to a problem. So, it is about the understanding of the problem and the way we use the tools to solve the problem. We are not trying to solve problems using the tools better because new, better tools become crafted later on, which helps us to progress faster and better in our solution to the problem.
Great talk, personally i find reducing complexity always works in software development, no matter the context
If I had to summarize, Modern Software Engineering presents what I call as the "Dual Challenge":
Embracing
New (& often complex) architectures leveraging Digital technology
While keeping
Release cycles short
Good Video
Such a sincere opening :).
I mostly agree with Dave on the subject of technology specific books... but there's always a couple of exceptions to the rule.... I've always thought Douglas Crockford's "the Good Parts" was vital reading if you're a JS developer or not just because of the ideas it smuggles across in it's technology specific text.
I get what you mean but on the 10X idea:
No 10X improvement? Please. Sure there is. In fact there are loads of examples in specific markets and they are not 10X but 350X, 800X, ...
Here is the idea: Remove all management and keep a couple of liaisons towards the clients. In other words, minimise the distance between engineer and client and stop polluting the processes with useless crap.
In engineering there are certain ideas you can try out to see what results in a better efficiency... and 5% of them actually work. But 100 managers create 100 ideas. If you have 100 ideas in trial phase, it is impossible to measure which one works and which does not. So they assume all of it works. Couple of years pass, and they eventually end up with thousands of ideas which is dragging the entire company to a crawl.
Naturally, you throw more engineers at the problem (which "need managing") and you end up with a company of 2000 people before a single engineer comes along and completely uproots your entire market with one single elegant open source github entry. Who is to blame? ... An engineer created the disruptor, so the engineers are at fault, naturally. If only we could have these 350X developers ...
there is no 10x !
... but a lot 0.1x