I am not convinced about smalltalk superiority untill I see the data for Kotlin and Swift maybe also Rust (also I am not expecting stellar performance from it than it comes to feature per hour metrics)
Interestlingly, George Miller studied how many things people could keep in their mind at the same time, and the famous paper he wrote was "The Magical Number Seven, Plus or Minus Two."
The worst bugs I've ever had are when I start thinking the program is not doing what it should - The program ALWAYS does what it should it's just that I've told it to do the wrong thing. When you first start with the assumption you are right it's going to be a LONG day.
The reason Eiffel is right up there is it's focus on correctness, through a sound model of OO and assertions in the form of preconditions, postconditions, and invariants. Adding assertions, in a disciplined way, to your code in other languages takes you a big step forward in reliability. Method preconditions give the most bang for the buck; they test that the method is being called correctly, and are also documentation. And since they come out of the design, they provide the basis of early test stubs. I am sure 95% of this audience already knows all this.
This study kinda smells: Google go woke in recent years and the result suspiciously follow the narrative. I am not saying that psychological wellbeing is not important -- it is, just would prefer the study were made by somebody else
It was good to hear you mention Fred Brooks! You could have included that mention when talking about the speed-people myth...which is essentially a derivative of Brooks’ Law: Adding resources to a late project makes it even later!
The biggest thing to remember about "study says" or "data shows" arguments is that for every factor you can think of which influences a result but has not been either considered or accounted for when performing the study, the credibility of the results drops. That only gets worse when the study uses some complete nonsense metric to try and prove a point, similar to how companies measure hours worked rather than results produced. Yes, measuring one is easy while the other is almost infinitely complex and having an easy metric makes you feel good. But if it's a pointless metric, the results should always be disregarded by people who take the time to think about it. Just like the amount of features or lines of code in a piece of software tells me exactly nothing about how useful it is to solving my problem.
Correct, end-results is the best metric. EG small company based on NodeJS told me, "My team of 10 can produce products than their team of 100 Java developers."
Choice of programming language also matters for another reason: It influences the way we think. If the language is OO, we think in terms of objects, if is functional, we think in terms of functions, if it is assembly, we think in terms of CPU instructions and, of course, the way we think influences how we design something and the way how we design something influences pretty much everything.
Some (if not all) of the stuff you mentioned really hits hard. The misconception that a very experienced engineer (new to the project/company) can produce better design decisions for that project than a team working on that tech stack for years (and learning from mistakes and other teams). The industry (for some reason) gives lot of importance to titles unfortunately
As I implied in the video, I think that great engineers working in a great process, with a great team ethic, will do better than bad engineers. But those caveats are really important! I have worked in teams of really great coders, where the team culture was bad and/or the dev process was bad, and their individual bits of code may have been ok, but the output and overall quality of the system was poor. I have also worked with lovely teams, who weren't technical "rock stars" who did great work.
I read some research years ago that found there were few differences between programmers intra-company, but huge differences between them inter-company. An interesting observation that the researchers made was that the simple expedient of removing company intercom systems ratcheted up productivity. But company environment had more to do with programmer productivity than programmer skill.
What this video highlights above all (to me at least), is how bad we are at measuring, or conversely how difficult it is to measure these things accurately. Perhaps we need to start taking identical twins and have robots and software raise them and teach them (as) equally (as possible) different sets of skills and then see which kind of combinations actually produce best results...
I think, you only go faster by adding people, if you are able to separate tasks. For example, when I use some actively maintained library, I can use the progress made in that library without slowing down my own project, as long as there are no breaking changes.
Outstanding content on a neglected topic! On team size, there is ample evidence from other fields that as soon as a team gets too big to sit around a table together informally, all kinds of issues begin to emerge. In particular you begin to get information silos and competing cliques. I've never worked on a big software project, but my sense would be that it should be broken down into decoupled tasks that can be tackled by 8 people or less. And that any necessary coordination between teams should ideally be handled by small groups of 3-4 team leaders who meet very regularly. This is how the infantry work - under the greatest pressures imaginable. The basic unit is typically 7-8 men in a squad, with 3-4 squads comprising a platoon. Anything larger than this in a front-line unit simply can't keep co-ordinated under the stress of combat. This structure has emerged over millennia of practical experience, and teams in other fields might do well to learn from it?
Language matters - This heavily depends on what you are programming. Using Visual Basic to program on OS over C would be the stupidest decision you ever made. Is the application speed specific? C/C++/Assembly over Python. Need to interface and speed is not critical? Stay away from C. Blanket questions such as "Which language is best?" are ridiculous and misguided to begin with.
The message "if we could expound a few more calories on thinking about better solutions" does not just apply to programming. Really good concepts in your discussions. Thank you.
I've had data on the design question. When I worked at a Healthcare Analytics company, I was able to create a platform that was as much as 100 times more effective based on the lines of code. Major new products were going out the door with only a thousand to two-thousand lines of Java code (measured using NCSS) compared to over 100,000 for the previous versions of the same project. I continued this design at the next company I worked for. The company was less sure about the purpose of their products, but I was able to achieve a 20x difference compared to the previous code. Also, it's likely that the difference reduced over time because the "standard" approaches in the market improved over time.
Most of the projects I work on these days use more than one language. The naval survivability simulator I work on has a UI written in tcl/tk. The simulation itself uses Tcl as a way to tie together optimized routines in C. And I end up writing large chunks of that C with an automation tool written in Tcl. (Which also doubles as a build system). (It also interfaces with fire and flood simulators that are, themselves, written in Fortran.) I also have had to write browser based visualizations that express javascript and HTML as part of the output.
@@ContinuousDelivery I can notice it in multiple videos, I normally don't since I don't play my volume that high though. It's possible that you can do some noise reduction using Audacity on the audio and see if you can remove some of the background noises.
Regarding deadlines: Deadlines are the bane of software quality. Every non-trivial program, while it is being written, is being written for the first time. There is no reliable way to tell how long it will take to do something for the first time. Each "estimate" is a wild-arsed guess. Managers and the bean-counters will push for these estimates to be pushed down for reasons having nothing to do with whether the deadline is reasonable. Holding developers to these guesses only serves to stress them, causing them to make more mistakes. If the project is not complete at the deadline, either we let the deadline slip--in which case the deadline may as well have not been made--or we can put the project into production as-is, in which case the deadline has forced us to ship an unsatisfactory product.
Working to a deadline *is* a very good thing. Get it done. The work will only expand to fill the time allocated. If the project is cancelled while you’re still working out your processes then you have failed. There is something that will guarantee success, tenacity and sheer willpower. Do not accept failure.
The system 1/system 2 thing is true but I see the progress differently: Question 1: do I remember the answer? And if no, then comes Question 2: do I bother to figure out the answer? But the process itself is always the same up to that point. Apart of that, the true/false questions you present here are quite vague, in some cases I needed to wait for your explanation to understand what you were even asking about. But in most cases it was just "that depends". For example when you were asking about adding people, the whole dependency between number of people and efficiency of the team came on my mind because I know a bit about it. And I did not even consider the 20 people you mentioned working in single group. Also the difference is also in details about the project. If you need to implement 150 different communication interfaces, 20 people will likely deliver almost 4 times what 5 people can. If it's implementing traveling salesman problem solution, one person could do better than five. Too vague for a true/false answer.
"largest number of function points" isn't such a good measure I'd like some kind of hypothetical measure of how easy a language makes it to change the software. I used to love Delphi, it's still top of the languages that I've used and loved, it's nice to see the metrics back up my system-1 decision there. "Technical skills" is a bit too wide of an umbrella. I think I'd rather hire a programmer that knew about design patterns but was unsure of the syntax of "our" language than somebody who knew the name of every function in "our" standard library but didn't have a clue about design patterns.
The amount of salt I needed with that language comparison chart at 7:00 nearly killed me. In what universe is Eiffel more productive than Lisp? I worked on non-trivial commercial products in both (plus Smalltalk, ObjC, Perl, and Python), and I had working code in Lisp before I had an object model in Eiffel, let alone the preconditions and postconditions and loop invariants and type choices.
Programming language matters, sort of. I successfully transitioned my team from working in LabView to C#, mostly because of the available documentation, tools, libraries, and programmers. The choice of language matters because the language implies all sorts of infrastructure and ecosystem, which absolutely matter.
11:00 I often even do big refactors or just rewrite classes instead of looking for bugs, when they are not obvious and difficult to find because it's faster and in the end, I understand better, what's going on, because I removed all the old code, which does not, what I currently want, etc.
5:30, true: if it is C++, approved; if not, we will use it by force! :) 7:50, depends on the skills of those people. Plus, the communication will has a growing challenge. 10:10, depends on how desperate is that deadline. Plus, deadline is kind of an absurd concept. About refactoring, I think is recommended to do it till certain point, when you feel things won't fall apart anymore, due to the lack of it. 12:12, for a team, I guess it's the communication. If working alone, coding skills. 15:00, true, we have C++, and it is still not able to solve things for us - it only give us the right tools.
Have you tried as a team? Management isn’t there to punish, it’s there to listen and observe and change processes to fascilitate. When I push TDD, I told my customer that initially it would add 30-40% overhead setting it up and during the coding process. But knowing that fixing a bug takes 100-300% more time in the future, it’s an investment in the long term! How many project did we have that takes months to add a simple feature? Use our case as a testing ground. I showed him the Mythical Man Month, which he devoured over the weekend - he was doing a PhD in IT business - and after that book he was convinced. And broke his back for us. And it paid off later on. I’ve done so many other projects (including once I also led) that we were too quick to code. Elevated a prototype to production status and later we were like... how the hell can we fit that new functionality in? It’s like fitting a square peg into a round hole! And you should take that experience and do something with it. Because we are weaklings in IT and unprofessional, compared to other engineering branches we keep burning ourselves. When did you hear an aerospace engineer say: “3 months? We need 10 but, okay we give it a try, we can shave some off here and here...” I wouldn’t get in a plane when It was engineered in such a way :)
it is the cost of communication that slows projects, not the team size , if those 20 people need to know what everybody else is doing then it will go slower even with large teams you can spin off subteams tasked with dealing with generic libraries (every project needs very generic libraries that nobody else bothered to release :-) ) , or spin off subteams to deal with parts that don't interact much with others, or make the UI people mock their data and not depend on the backend giving them data instantly etc. , or have part of the UI team work on widgets that don't care what else is there on screen and which can be used by the rest of the UI team ...
I type my answers and justification as the questions popup, this is a valuable quiz!!! Choice or programming language matters: true More people more speed: false Working to a deadline no time to improve: false (as a team you need to DEMAND the time! Software people are too lenient to management. Electrical and aerospace engineers take their time and it’s okay! So take those few months getting your CI/CD in order, your slow down is an investment for later!) Technical skills matter most: false, I have had rather inexperienced developers that had a knack for talking to business. And had enough technical knowledge to relay the requirements in tech speak for me to code. That IMO is really valuable! There’s no silver bullet: true! If there was every body would be using it. And logic defies this because a business that has the right to survive must do something different than its competitors or be unique. And unique comes with unknown challenges and often require unique technology and processes, that are developed/thought up anew. Lots of my answers (all correct as it seems), came from reading The Mythical Man Month. I advise that book to every business person, manager and engineer. It’s understandable for everyone and that’s unique in these “tech” books.
Everything he said is scientifically backed, as a matter of fact there's a popular book for that. It's called "Thinking, Fast and Slow" by Daniel Kahneman
9:24 This is really interesting! I've always known that smaller teams worked better, out of both experience and word of mouth from other developers experience. Its nice to have a study to explain this with data. I'm going to have to read up some more publications from the QMS.
Choice of language matters? Of course. But depends on the objective right? I don't think that output, i.e. number of function points is necessarily a good measure. Surely, it should be the opposite? My, limited, understanding is that function points have a correlation to LOC. And, therefore, create more complexity, more moving parts and are therefore less predictable. Also, adding more people speeds thing up? Yes, to a degree, it does. Depends on the context of course. If it's a team of 1, I would suggest adding another definitely speeds things up. I guess the conclusion is depends on what we're trying to prove, to what purpose? As others have said below, really enjoying the channel and discussions, many thanks
The 100k of lines of code is probably the worse measure they could have picked, and shows that research don't understand the problem they are investigating. 100k lines of code is going to be significantly better than 100k from a team of 5. When you're not under pressure, it is better to write concise readable code, which means you might actually write 4 to 5 times as much code as you actually commit, but it will be clean more efficient and will do more. But if deadlines loom, you're not going to refactor nearly as much. So you're code is going to be bloated. To really measure this, you need a similar project between the teams, and measure how long it takes to make a MVP. The reality is adding more people will help if you don't have enough people, but each new team member will at some point provide deminishing return, because of org structure bottle necks and the fact more people more problems.
If I'm interpreting it right, I suspect the order of that list correlates with each language's developer norms on extracting methods. Older, "business" facing, codebases are likely to be stuffed full of 100+ line, condition and loop heavy functions.
Wikipedia defines function points as a measure of “outputs, inquiries, inputs, internal files, and external interfaces” so what you are describing sounds a big closer to cyclomatic complexity to me, or am I missing your point?
SmallTalk likely comes out that way because it's an inversion of how we conventionally create features. We do that by creating more stuff, or more configuration or more data structures. SmallTalk is essentially plumbing, you might create new messages which cascade to other new messages but it's efficient in stuff. It is not efficient in operation though, it's very cool and very, very slow. Hence things like Erlang, but Erlang has it's own issues, mostly being stubborn and going silently crazy. And on the whole, if that's a primary question at the beginning of something new, something is already wrong. It can be a primary answer, available skills, closest operating paradigm to a whole bunch of abstractions that the group mind are thinking in, and yes available tools and, of course, favourite framework. I did once see a team vote on which language to use and that withered my non-existent soul.
@@SimonPLucy Not as slow as it used to be with modern hardware, but yes I agree wholheartedly that the language-wars thing is a disfunction of our industry.
I can't say I have gained any clarity on whether programming languages make a difference. Did the experiments control for developer experience, for example? What about domain? There seem to be many latent variables. Intuitively, I actually would say language makes a difference when thinking of coding itself as a language game. Take the task of designing and writing the right abstractions for (re-)use in the code base. If you're spending time on the "language" you create within your code (e.g., the functions you define), because it improves the development of the rest of the system, then I'd expect the choice of programming language (no quotes) to have the same effect. Personally I think we're held back by the lack of widespread knowledge outside the imperative, OOP, and functional paradigms.
The paper that describes the research is linked in the description. You can't compare Sociology with Physics, none of it makes any sense if you do. You simply can't control the variables in the same way. It seems to me that Sociology is always a statistical approximation.
The best team needs skilled members that work well together. Each with their own area, like database, testing, frontend or backend. So they don't disturb each other while working. The team would also need good management or no management to be efficient. A bad management can make the best developer useless.
I see many elements that can be an issue with measuring time to make 1000 functions. What is a function ? Does a JS anonymous callback passed to a .forEach() count as a function or a loop ? Does a method count as a function ? Do basic functions like min() or max() and such are counted when they have to be made from scratch on a barebone language ? If the project is slow because the client do not provide informations, adding more people won't help much.
6:19: What are function points? The number of functions after compiliation? I guess, c++ or something similar, because of templates (generics), which get expanded for every function/method.
Oh, looks like small numbers of functions are up. Then I'd expect some language, where you don't have multiple functions/methods/constructors for similar behavior, but keyword arguments, probably you would not write constructors at all to create objects/structs, nor would you have any generics, which might create multiple versions of a function.
@@porky1118 "The function point is a "unit of measurement" to express the *amount of business functionality* an information system (as a product) provides to a user." en.wikipedia.org/wiki/Function_point
When Dave said: "System 2 thinking literally burns more calories than System 1" I was like "Oh, so I need not go to the gym then? I can sit at home and work on complex(yet interesting) problems, and still burn calories" :)
It will. I read some data in New Scientist, a few years ago, that said that thinking about going to the gym, and visualising yourself working out is nearly as good as working out 🤣🤣
When you talk about technical skills mattering most the data you selected to prove the point that it isn't true suffers from massive selection bias. Google doesn't employ people who don't have extremely strong technical skills. It's like analyzing an NBA team and concluding that height isn't a determining factor while ignoring that your entire sample is extraordinarily tall. It's not to say that the sorts of social skills you talk about aren't valuable but if you look at the way companies hire they are nice to haves after technical skill and aptitude.
My two cents: by introducing bad/average developers to the Google study, you would get the result that they talk more than the good developers, bust just for smalltalk (not the computer language) and silly questions!
Hi Dave, great video! Which do you think are those things which reduce productivity and quality the most, wat you mentioned at the end of the video? I'm thinking about not using iterative and incremental development and obviously not using CD. Are there any other "low hanging fruits" which people could easily do but do not do, therefore sabotaging themselves?
Thanks. I think that top of my list is reliance on manual regression testing. The problem with all of this stuff though is that it sounds simple, and it is simple once you are up and running with it, but it is a very different way to think about, and approach SW dev, and people find it hard to change how they think about things.
@@ContinuousDelivery Thanks alot for your answer! I agree, I think in general the cost of re- testing needs to be reduced as much as possible. Without this, it's hard to apply any agile methods. We are often required to be more agile, but without any investment in automation. This makes the goal of being agile impossible to reach. Even worse, in case of pour regression test frameworks, some people start falling into a kind of McNamara fallacy and say that a test which is not easily automatable is not important. Then we end up with alot of meaningless automated tests which are favoured simply because they are fast, not because they are useful.
Very interesting video. As regards smalltalk etc. Do you think it is possible that familiarity with the code might be making a difference? By which I mean, most new developers are not learning these old languages now. The developers using VB have been using it for years, so could this experience be skewing the data from the study?
Hey there Dave and thanks so much! Do you by chance recall the study you mentioned that identified the most common characteristic of 'Great Programmers'? I'd like to refer to it :)
The problem space largely drives the 'shape' of the solution. Some solutions are easier to express in one language vs another. That metric is super flawed to me. Different languages have pros/cons depending on the problem we're solving. This 'function point metric' problem is a contrived problem space that's just not useful. Lets see how long it takes to create the N 'function points' required for, say, a distributed cache. Are you really going to do that in VB? Why not? I mean golly, it's #4!
Languages do matter!!!!!! But for a different reason - you want to work in 1 or a few languages that all the engineers in your company already know. Asking engineers to develop their language skills at the same time they develop new project features, or even maintain project features, or even test project features, is an added pain point that will cause regret in the long run.
It just looks good to incompetent management. They see more people working like slaves so they think more gets done. They don't understand the concept of useless or unnecessary work.
Big teams do a lot of redundant work because two or more people often write code to do the same thing. That's why it is stupid to measure performance by lines of code. Massive copy-and-paste would be the best performance improvement according to that standard.
There is a process that functions like a silver bullet: replacing people with AIs or other systems that are not optimizing resource use but for better results, That is the end game. If we can't make rational decisions, build the systems that can. Down with humanocracy!
"Produced 5x fewer defects than the 20-person teams." This kind of saying always bothered me. How "few" defects did the 20-person team produce? What's 5x that? Did you mean 1/5 the number of defects? This isn't intended to be insulting toward the speaker. It's something a lot of people do and it's weird.
7:31 : results may be biased because of what kind of programmer uses what language. Maybe if a smalltalk programmer would have learned one of the new "sexy" languages results would have been better. Maybe not.
Keep in mind - google's engineers all are highly skilled. Their engineers are not an accurate sample of the population. I think what they found was a case of diminishing returns. The difference between a team of D level developers vs B level is massive. The difference between a team of B level vs A level? trivial in the big picture.
What a comeback for Smalltalk! If both of the programmers who use it would work together they could probably accomplish something amazing!
xD Amazing! I about died laughing.
@@reilithion I would have said the same about Eiffel, but unfortunately he doesn't have that option.
@@stefanhermansen8975 hahaha this is priceless. I'm dying :D We all are.
@@nexovec That's right. Banging our heads against Microsoft.
I am not convinced about smalltalk superiority untill I see the data for Kotlin and Swift maybe also Rust (also I am not expecting stellar performance from it than it comes to feature per hour metrics)
Finally an adult talking about software development! Love this channel :)
I know, right?
My military training, and later my Industrial Engineering courses, taught me that teams should 7+/-2. Bigger teams are divided up into smaller teams.
Interestlingly, George Miller studied how many things people could keep in their mind at the same time, and the famous paper he wrote was "The Magical Number Seven, Plus or Minus Two."
The worst bugs I've ever had are when I start thinking the program is not doing what it should - The program ALWAYS does what it should it's just that I've told it to do the wrong thing.
When you first start with the assumption you are right it's going to be a LONG day.
The reason Eiffel is right up there is it's focus on correctness, through a sound model of OO and assertions in the form of preconditions, postconditions, and invariants.
Adding assertions, in a disciplined way, to your code in other languages takes you a big step forward in reliability. Method preconditions give the most bang for the buck; they test that the method is being called correctly, and are also documentation. And since they come out of the design, they provide the basis of early test stubs.
I am sure 95% of this audience already knows all this.
13:37 "psychological safety" - wow. most workplaces i know - are psychological hellholes.
Sorry to hear it
This study kinda smells: Google go woke in recent years and the result suspiciously follow the narrative. I am not saying that psychological wellbeing is not important -- it is, just would prefer the study were made by somebody else
The study really smells. Mentions EQ. EQ is pseudo-scientific nonsense.
Like astreology or homeopathy.
@@cyrusol What LISP interpreter said that?
@@PMA65537 ??
It was good to hear you mention Fred Brooks! You could have included that mention when talking about the speed-people myth...which is essentially a derivative of Brooks’ Law: Adding resources to a late project makes it even later!
The biggest thing to remember about "study says" or "data shows" arguments is that for every factor you can think of which influences a result but has not been either considered or accounted for when performing the study, the credibility of the results drops.
That only gets worse when the study uses some complete nonsense metric to try and prove a point, similar to how companies measure hours worked rather than results produced. Yes, measuring one is easy while the other is almost infinitely complex and having an easy metric makes you feel good. But if it's a pointless metric, the results should always be disregarded by people who take the time to think about it.
Just like the amount of features or lines of code in a piece of software tells me exactly nothing about how useful it is to solving my problem.
Correct, end-results is the best metric.
EG small company based on NodeJS told me, "My team of 10 can produce products than their team of 100 Java developers."
Choice of programming language also matters for another reason: It influences the way we think. If the language is OO, we think in terms of objects, if is functional, we think in terms of functions, if it is assembly, we think in terms of CPU instructions and, of course, the way we think influences how we design something and the way how we design something influences pretty much everything.
it is so nice and rare to hear argumentative and thinking person.
Some (if not all) of the stuff you mentioned really hits hard. The misconception that a very experienced engineer (new to the project/company) can produce better design decisions for that project than a team working on that tech stack for years (and learning from mistakes and other teams). The industry (for some reason) gives lot of importance to titles unfortunately
As I implied in the video, I think that great engineers working in a great process, with a great team ethic, will do better than bad engineers. But those caveats are really important! I have worked in teams of really great coders, where the team culture was bad and/or the dev process was bad, and their individual bits of code may have been ok, but the output and overall quality of the system was poor. I have also worked with lovely teams, who weren't technical "rock stars" who did great work.
I read some research years ago that found there were few differences between programmers intra-company, but huge differences between them inter-company. An interesting observation that the researchers made was that the simple expedient of removing company intercom systems ratcheted up productivity. But company environment had more to do with programmer productivity than programmer skill.
What this video highlights above all (to me at least), is how bad we are at measuring, or conversely how difficult it is to measure these things accurately. Perhaps we need to start taking identical twins and have robots and software raise them and teach them (as) equally (as possible) different sets of skills and then see which kind of combinations actually produce best results...
I'm so glad I found your channel. You're like the experienced mentor I've never had :)
I think, you only go faster by adding people, if you are able to separate tasks.
For example, when I use some actively maintained library, I can use the progress made in that library without slowing down my own project, as long as there are no breaking changes.
Outstanding content on a neglected topic!
On team size, there is ample evidence from other fields that as soon as a team gets too big to sit around a table together informally, all kinds of issues begin to emerge. In particular you begin to get information silos and competing cliques.
I've never worked on a big software project, but my sense would be that it should be broken down into decoupled tasks that can be tackled by 8 people or less. And that any necessary coordination between teams should ideally be handled by small groups of 3-4 team leaders who meet very regularly.
This is how the infantry work - under the greatest pressures imaginable. The basic unit is typically 7-8 men in a squad, with 3-4 squads comprising a platoon. Anything larger than this in a front-line unit simply can't keep co-ordinated under the stress of combat. This structure has emerged over millennia of practical experience, and teams in other fields might do well to learn from it?
Language matters - This heavily depends on what you are programming. Using Visual Basic to program on OS over C would be the stupidest decision you ever made. Is the application speed specific? C/C++/Assembly over Python. Need to interface and speed is not critical? Stay away from C. Blanket questions such as "Which language is best?" are ridiculous and misguided to begin with.
You make me cry - i as programmer used to raise discussions about coding and the ex-colleagues thought i was arrogant
The message "if we could expound a few more calories on thinking about better solutions" does not just apply to programming. Really good concepts in your discussions. Thank you.
Thank you for another quality video! It was mildly infuriating when you didn't give us the answer to the multiplication problem 😂
I did wonder wether to include the answer or not 🤣 🤣 🤣
100% agree that we do NOT make decisions based on reason. Even those of us who pride ourselves on our logic are not great at it.
Free software mentorship, thanks for these videos
Its a pleasure 😎
I've had data on the design question. When I worked at a Healthcare Analytics company, I was able to create a platform that was as much as 100 times more effective based on the lines of code. Major new products were going out the door with only a thousand to two-thousand lines of Java code (measured using NCSS) compared to over 100,000 for the previous versions of the same project. I continued this design at the next company I worked for. The company was less sure about the purpose of their products, but I was able to achieve a 20x difference compared to the previous code. Also, it's likely that the difference reduced over time because the "standard" approaches in the market improved over time.
Most of the projects I work on these days use more than one language. The naval survivability simulator I work on has a UI written in tcl/tk. The simulation itself uses Tcl as a way to tie together optimized routines in C. And I end up writing large chunks of that C with an automation tool written in Tcl. (Which also doubles as a build system). (It also interfaces with fire and flood simulators that are, themselves, written in Fortran.) I also have had to write browser based visualizations that express javascript and HTML as part of the output.
This was a very helpful video, the point about great programmers communicating better, I agree with it totally
All I hear is the clicking of that remote... but great video as always!
Hmmm, I wonder why that is more noticeable.
@@ContinuousDelivery It is strange, I was not able to notice it in any of your previous videos... But maybe I am just nitpicking, sorry :)
@@ContinuousDelivery Clicker training? :P
@@ContinuousDelivery I can notice it in multiple videos, I normally don't since I don't play my volume that high though. It's possible that you can do some noise reduction using Audacity on the audio and see if you can remove some of the background noises.
Regarding deadlines: Deadlines are the bane of software quality. Every non-trivial program, while it is being written, is being written for the first time. There is no reliable way to tell how long it will take to do something for the first time. Each "estimate" is a wild-arsed guess. Managers and the bean-counters will push for these estimates to be pushed down for reasons having nothing to do with whether the deadline is reasonable. Holding developers to these guesses only serves to stress them, causing them to make more mistakes. If the project is not complete at the deadline, either we let the deadline slip--in which case the deadline may as well have not been made--or we can put the project into production as-is, in which case the deadline has forced us to ship an unsatisfactory product.
Thank you for introducing professional skills to the broader audience
Working to a deadline *is* a very good thing. Get it done. The work will only expand to fill the time allocated. If the project is cancelled while you’re still working out your processes then you have failed. There is something that will guarantee success, tenacity and sheer willpower. Do not accept failure.
The system 1/system 2 thing is true but I see the progress differently: Question 1: do I remember the answer? And if no, then comes Question 2: do I bother to figure out the answer? But the process itself is always the same up to that point.
Apart of that, the true/false questions you present here are quite vague, in some cases I needed to wait for your explanation to understand what you were even asking about. But in most cases it was just "that depends". For example when you were asking about adding people, the whole dependency between number of people and efficiency of the team came on my mind because I know a bit about it. And I did not even consider the 20 people you mentioned working in single group. Also the difference is also in details about the project. If you need to implement 150 different communication interfaces, 20 people will likely deliver almost 4 times what 5 people can. If it's implementing traveling salesman problem solution, one person could do better than five. Too vague for a true/false answer.
"largest number of function points" isn't such a good measure I'd like some kind of hypothetical measure of how easy a language makes it to change the software. I used to love Delphi, it's still top of the languages that I've used and loved, it's nice to see the metrics back up my system-1 decision there.
"Technical skills" is a bit too wide of an umbrella. I think I'd rather hire a programmer that knew about design patterns but was unsure of the syntax of "our" language than somebody who knew the name of every function in "our" standard library but didn't have a clue about design patterns.
The amount of salt I needed with that language comparison chart at 7:00 nearly killed me. In what universe is Eiffel more productive than Lisp? I worked on non-trivial commercial products in both (plus Smalltalk, ObjC, Perl, and Python), and I had working code in Lisp before I had an object model in Eiffel, let alone the preconditions and postconditions and loop invariants and type choices.
He really knows what he's talking about. I'm not a software developer in the first place, but this channel is really interesting anyway.
So how do you know that he knows ?
@@Nerwesta Just my experience with trash talker vs. skilled people.
@@xtra9996 Right I see !
Great episode! Thanks for sharing your knowledge and experience, Dave.
Glad you enjoyed it!
True - programming language matters
In the way that you expected?
Programming language matters, sort of. I successfully transitioned my team from working in LabView to C#, mostly because of the available documentation, tools, libraries, and programmers. The choice of language matters because the language implies all sorts of infrastructure and ecosystem, which absolutely matter.
11:00 I often even do big refactors or just rewrite classes instead of looking for bugs, when they are not obvious and difficult to find because it's faster and in the end, I understand better, what's going on, because I removed all the old code, which does not, what I currently want, etc.
On the second problem my brain said 13x4=52, so 50,000 ‘ish.
5:30, true: if it is C++, approved; if not, we will use it by force! :)
7:50, depends on the skills of those people. Plus, the communication will has a growing challenge.
10:10, depends on how desperate is that deadline. Plus, deadline is kind of an absurd concept. About refactoring, I think is recommended to do it till certain point, when you feel things won't fall apart anymore, due to the lack of it.
12:12, for a team, I guess it's the communication. If working alone, coding skills.
15:00, true, we have C++, and it is still not able to solve things for us - it only give us the right tools.
If I would say even one of these things that you said at my workplace - I'd get fired in a heartbeat.
condolences
Sorry to hear that.
Time to change your workplace?
Have you tried as a team? Management isn’t there to punish, it’s there to listen and observe and change processes to fascilitate. When I push TDD, I told my customer that initially it would add 30-40% overhead setting it up and during the coding process. But knowing that fixing a bug takes 100-300% more time in the future, it’s an investment in the long term! How many project did we have that takes months to add a simple feature? Use our case as a testing ground. I showed him the Mythical Man Month, which he devoured over the weekend - he was doing a PhD in IT business - and after that book he was convinced. And broke his back for us. And it paid off later on. I’ve done so many other projects (including once I also led) that we were too quick to code. Elevated a prototype to production status and later we were like... how the hell can we fit that new functionality in? It’s like fitting a square peg into a round hole! And you should take that experience and do something with it.
Because we are weaklings in IT and unprofessional, compared to other engineering branches we keep burning ourselves. When did you hear an aerospace engineer say: “3 months? We need 10 but, okay we give it a try, we can shave some off here and here...” I wouldn’t get in a plane when It was engineered in such a way :)
it is the cost of communication that slows projects, not the team size , if those 20 people need to know what everybody else is doing then it will go slower
even with large teams you can spin off subteams tasked with dealing with generic libraries (every project needs very generic libraries that nobody else bothered to release :-) ) , or spin off subteams to deal with parts that don't interact much with others, or make the UI people mock their data and not depend on the backend giving them data instantly etc. , or have part of the UI team work on widgets that don't care what else is there on screen and which can be used by the rest of the UI team ...
Just improve on throwing out bad ideas! - There is ALLWAYS one gem in every on of these videos.
I type my answers and justification as the questions popup, this is a valuable quiz!!!
Choice or programming language matters: true
More people more speed: false
Working to a deadline no time to improve: false (as a team you need to DEMAND the time! Software people are too lenient to management. Electrical and aerospace engineers take their time and it’s okay! So take those few months getting your CI/CD in order, your slow down is an investment for later!)
Technical skills matter most: false, I have had rather inexperienced developers that had a knack for talking to business. And had enough technical knowledge to relay the requirements in tech speak for me to code. That IMO is really valuable!
There’s no silver bullet: true! If there was every body would be using it. And logic defies this because a business that has the right to survive must do something different than its competitors or be unique. And unique comes with unknown challenges and often require unique technology and processes, that are developed/thought up anew.
Lots of my answers (all correct as it seems), came from reading The Mythical Man Month. I advise that book to every business person, manager and engineer. It’s understandable for everyone and that’s unique in these “tech” books.
Everything he said is scientifically backed, as a matter of fact there's a popular book for that. It's called "Thinking, Fast and Slow" by Daniel Kahneman
Hmm. I agree. But i also think intuition is a powerful tool too.
9:24 This is really interesting! I've always known that smaller teams worked better, out of both experience and word of mouth from other developers experience. Its nice to have a study to explain this with data. I'm going to have to read up some more publications from the QMS.
Choice of language matters? Of course. But depends on the objective right? I don't think that output, i.e. number of function points is necessarily a good measure. Surely, it should be the opposite? My, limited, understanding is that function points have a correlation to LOC. And, therefore, create more complexity, more moving parts and are therefore less predictable.
Also, adding more people speeds thing up? Yes, to a degree, it does. Depends on the context of course. If it's a team of 1, I would suggest adding another definitely speeds things up.
I guess the conclusion is depends on what we're trying to prove, to what purpose?
As others have said below, really enjoying the channel and discussions, many thanks
The 100k of lines of code is probably the worse measure they could have picked, and shows that research don't understand the problem they are investigating. 100k lines of code is going to be significantly better than 100k from a team of 5. When you're not under pressure, it is better to write concise readable code, which means you might actually write 4 to 5 times as much code as you actually commit, but it will be clean more efficient and will do more. But if deadlines loom, you're not going to refactor nearly as much. So you're code is going to be bloated. To really measure this, you need a similar project between the teams, and measure how long it takes to make a MVP. The reality is adding more people will help if you don't have enough people, but each new team member will at some point provide deminishing return, because of org structure bottle necks and the fact more people more problems.
If I'm interpreting it right, I suspect the order of that list correlates with each language's developer norms on extracting methods.
Older, "business" facing, codebases are likely to be stuffed full of 100+ line, condition and loop heavy functions.
Wikipedia defines function points as a measure of “outputs, inquiries, inputs, internal files, and external interfaces” so what you are describing sounds a big closer to cyclomatic complexity to me, or am I missing your point?
SmallTalk likely comes out that way because it's an inversion of how we conventionally create features. We do that by creating more stuff, or more configuration or more data structures. SmallTalk is essentially plumbing, you might create new messages which cascade to other new messages but it's efficient in stuff. It is not efficient in operation though, it's very cool and very, very slow. Hence things like Erlang, but Erlang has it's own issues, mostly being stubborn and going silently crazy.
And on the whole, if that's a primary question at the beginning of something new, something is already wrong. It can be a primary answer, available skills, closest operating paradigm to a whole bunch of abstractions that the group mind are thinking in, and yes available tools and, of course, favourite framework.
I did once see a team vote on which language to use and that withered my non-existent soul.
@@SimonPLucy Not as slow as it used to be with modern hardware, but yes I agree wholheartedly that the language-wars thing is a disfunction of our industry.
System 1 goes to cache
System 2 goes to compute
I can't say I have gained any clarity on whether programming languages make a difference. Did the experiments control for developer experience, for example? What about domain? There seem to be many latent variables.
Intuitively, I actually would say language makes a difference when thinking of coding itself as a language game. Take the task of designing and writing the right abstractions for (re-)use in the code base. If you're spending time on the "language" you create within your code (e.g., the functions you define), because it improves the development of the rest of the system, then I'd expect the choice of programming language (no quotes) to have the same effect.
Personally I think we're held back by the lack of widespread knowledge outside the imperative, OOP, and functional paradigms.
The paper that describes the research is linked in the description. You can't compare Sociology with Physics, none of it makes any sense if you do. You simply can't control the variables in the same way. It seems to me that Sociology is always a statistical approximation.
The best team needs skilled members that work well together. Each with their own area, like database, testing, frontend or backend.
So they don't disturb each other while working.
The team would also need good management or no management to be efficient.
A bad management can make the best developer useless.
I see many elements that can be an issue with measuring time to make 1000 functions.
What is a function ? Does a JS anonymous callback passed to a .forEach() count as a function or a loop ? Does a method count as a function ?
Do basic functions like min() or max() and such are counted when they have to be made from scratch on a barebone language ?
If the project is slow because the client do not provide informations, adding more people won't help much.
6:19: What are function points? The number of functions after compiliation? I guess, c++ or something similar, because of templates (generics), which get expanded for every function/method.
Oh, looks like small numbers of functions are up.
Then I'd expect some language, where you don't have multiple functions/methods/constructors for similar behavior, but keyword arguments, probably you would not write constructors at all to create objects/structs, nor would you have any generics, which might create multiple versions of a function.
@@porky1118 "The function point is a "unit of measurement" to express the *amount of business functionality* an information system (as a product) provides to a user."
en.wikipedia.org/wiki/Function_point
OK, the rationality bit at the beginning became so chowderheaded that I couldn't keep watching.
When Dave said: "System 2 thinking literally burns more calories than System 1"
I was like "Oh, so I need not go to the gym then? I can sit at home and work on complex(yet interesting) problems, and still burn calories" :)
It will. I read some data in New Scientist, a few years ago, that said that thinking about going to the gym, and visualising yourself working out is nearly as good as working out 🤣🤣
When you talk about technical skills mattering most the data you selected to prove the point that it isn't true suffers from massive selection bias. Google doesn't employ people who don't have extremely strong technical skills. It's like analyzing an NBA team and concluding that height isn't a determining factor while ignoring that your entire sample is extraordinarily tall. It's not to say that the sorts of social skills you talk about aren't valuable but if you look at the way companies hire they are nice to haves after technical skill and aptitude.
My two cents: by introducing bad/average developers to the Google study, you would get the result that they talk more than the good developers, bust just for smalltalk (not the computer language) and silly questions!
Software development is a never ending marathon....which you might have to change the course you are running on a number of times...
Um. The chart at 6:27 has function points at the top, not hours. So that would make C the top ;)
😉
Hi Dave, great video! Which do you think are those things which reduce productivity and quality the most, wat you mentioned at the end of the video? I'm thinking about not using iterative and incremental development and obviously not using CD. Are there any other "low hanging fruits" which people could easily do but do not do, therefore sabotaging themselves?
Thanks. I think that top of my list is reliance on manual regression testing. The problem with all of this stuff though is that it sounds simple, and it is simple once you are up and running with it, but it is a very different way to think about, and approach SW dev, and people find it hard to change how they think about things.
@@ContinuousDelivery Thanks alot for your answer! I agree, I think in general the cost of re- testing needs to be reduced as much as possible. Without this, it's hard to apply any agile methods. We are often required to be more agile, but without any investment in automation. This makes the goal of being agile impossible to reach. Even worse, in case of pour regression test frameworks, some people start falling into a kind of McNamara fallacy and say that a test which is not easily automatable is not important. Then we end up with alot of meaningless automated tests which are favoured simply because they are fast, not because they are useful.
Very interesting video. As regards smalltalk etc. Do you think it is possible that familiarity with the code might be making a difference? By which I mean, most new developers are not learning these old languages now. The developers using VB have been using it for years, so could this experience be skewing the data from the study?
I don't think so, but could be I suppose. That is the trouble with sociology - no real control in the experiments!
6:35 odd ordering considering some of these are quite similar
Got to read Haidt boys, intuitions come first, reason and logic second.
Hey there Dave and thanks so much! Do you by chance recall the study you mentioned that identified the most common characteristic of 'Great Programmers'? I'd like to refer to it :)
The problem space largely drives the 'shape' of the solution. Some solutions are easier to express in one language vs another.
That metric is super flawed to me. Different languages have pros/cons depending on the problem we're solving. This 'function point metric' problem is a contrived problem space that's just not useful. Lets see how long it takes to create the N 'function points' required for, say, a distributed cache. Are you really going to do that in VB? Why not? I mean golly, it's #4!
Asking very unprecise question may cause contradicting answers to be correct depending on the lacking context.
Languages do matter!!!!!! But for a different reason - you want to work in 1 or a few languages that all the engineers in your company already know. Asking engineers to develop their language skills at the same time they develop new project features, or even maintain project features, or even test project features, is an added pain point that will cause regret in the long run.
Then again, of course, we rarely choose languages at random - gotta work with an existing infrastructure most of the time.
@3:06 : DAMN!! Dave can read my mind!! :-D :-D :-D
Another great video... love your channel!
Thanks so much!
I'd agree with you, if you only brought snacks...
Great video!
Silver bulllet just kills vampires!
Great lecture. Thanks a lot !
False- more people doesn't mean moving faster
...and the data is with you 😎
It just looks good to incompetent management. They see more people working like slaves so they think more gets done. They don't understand the concept of useless or unnecessary work.
excellent content as always. Thank you.
Not all ideas are created equal - there are stupid ideas :D
Excellent video! Thank you very much.
Superb content, as always. :)
Thanks :)
"Team of 5 people does almost same work as team of 20 people"
I hope bosses don't see this video
Big teams do a lot of redundant work because two or more people often write code to do the same thing. That's why it is stupid to measure performance by lines of code. Massive copy-and-paste would be the best performance improvement according to that standard.
@@hawkbirdtree3660
Yes , boss!
*proceeds to log in to world of warcraft
System 1: Do you want to prove this wrong to me by giving be food?
System 2: I don't know, I don't care.
Another great video!
Thanks 🙂
Ada/SPARK guarantees absence of runtime errors.
False - There is always time to refactor, otherwise you will pay dearly down the line
you refactor, and then the requirements change.
The requirements always change, wether you refactor or not, so refactor to make it easier to change 😁😎
There is a process that functions like a silver bullet: replacing people with AIs or other systems that are not optimizing resource use but for better results, That is the end game. If we can't make rational decisions, build the systems that can. Down with humanocracy!
"Produced 5x fewer defects than the 20-person teams." This kind of saying always bothered me. How "few" defects did the 20-person team produce? What's 5x that? Did you mean 1/5 the number of defects?
This isn't intended to be insulting toward the speaker. It's something a lot of people do and it's weird.
Yes 1/5
who the heck measures performance by counting lines of code? is this a better comment if I do....
this?
I'm surprised Clojure is not in 25 most efficient languages
I thought all of that list was kind of surprising
The reason Clojure is not on the list is because they're lazy.
So there are no teams of 6-19 people, or what happened there?
Assuming function points are synonymous to functions then why is more functions a good thing?
They aren't synonymous with Functions. en.wikipedia.org/wiki/Function_point
@@ContinuousDelivery ah that makes sense. I would be curious to know what the function points to big tattoo is.
Why is your background 5fps
If you are programmer - either you are sick or genius, nothing in between!
Why can't I be a sick genius?
7:31 : results may be biased because of what kind of programmer uses what language. Maybe if a smalltalk programmer would have learned one of the new "sexy" languages results would have been better. Maybe not.
great video, thanks
Relying on data when the data sucks.
I didn't wait for the answer
I google-fu'd it
haha!
Glad I studied Eiffel at Uni
With a name like Eiffel, I would expect it to tower over all the other languages.
What university teaches Eiffel?
@@Squeeeez This was a while ago, but UTS (Uni Tech, Sydney). It was our first programming class.
Keep in mind - google's engineers all are highly skilled. Their engineers are not an accurate sample of the population. I think what they found was a case of diminishing returns. The difference between a team of D level developers vs B level is massive. The difference between a team of B level vs A level? trivial in the big picture.
Considering how bloated, slow and bad in terms of usability and UI Google's software is, I'm not sure about those engineers.
i will take some snacks for my interviewee
I am not convinced @Dave. Give me my snacks.
Damn, I love your channel!
I am not a nerd! My mum says I'm cool!
I am not a nerd either, oooh, did you see the SpaceX landing?😁 😂
System 1 == Brain's cache