6 ms·

John Carmack discusses the art and science of software engineering (2012)

145 points by dshankar 11y ago

daenz 11y ago
> It’s about social interactions between the programmers or even between yourself spread over time. There's nothing quite like looking at some code and saying "who in the hell did this?", then looking at the blame and realizing it was you, years ago. Learning from those moments is super valuable.
- xahrepap 11y ago
  I call that guy "Yesterday Joel" ... I'm constantly cursing that imbesel in normal conversation. Today Joel hates that guy. But Today Joel really looks up to Tomorrow Joel and hopes someday to be just like him.
  - alexpersian 11y ago
    Tomorrow's his day to shine!
markbnj 11y ago
A great talk, pithy and full of insights gleaned from a lot of experience. Thanks for posting it.
ternaryoperator 11y ago
Very good essay. However, Carmac's view that there is very little quantified info about what works and what doesn't overlooks the work of software engineering practitioners, such as Capers Jones, who has long studied projects quantitatively and published detailed statistics on the effectiveness of different development approaches. His book "The Economics of Software Quality" is an excellent summary of his findings across thousands of projects. Reading it is like the first time you run a profiler and you realize that what you think you knew is true in part, but that other factors you'd not counted are have an outsize effect that you've misestimated.
- coreyoconnor 11y ago
  I've run into the same opinion from other developers: "there is very little quantified info about what works and what doesn't" In my experience they are looking for the wrong answers. They want an answer of how to design software. How to define the entities, classes, functions etc. Quantitative software development discusses less of design, IMO, and more organizational factors. EG: How a companies organization and processes impact quality. This is not what practitioners expect. Yet, this is where the science of software development is. Thanks for the book reference! An economic perspective on software quality sounds enlightening.
  - shadowfox 11y ago
    Now I am curious as to whether there has been any work in quantifying (or at least studying) the impact of processes vs engineering (in the sense of design and development) on quality and long term maintenance of software. My google-fu is clearly failing me.
- angersock 11y ago
  Thanks for the reading suggestion! That said, it seems that his last practical experience in the field was better than two decades ago ( https://en.wikipedia.org/wiki/Capers_Jones https://en.wikipedia.org/wiki/Capers_Jones ). A criticism of that sort is available to other folks as well--I feel compelled to ask, "Interesting results, but what have you shipped recently?"
  - brehaut 11y ago
    "but what have you shipped recently?" Looks like he has shipped 14 books and at least 36 papers on software engineering methodologies.
  - hinkley 11y ago
    Don't you think this is a bit like not listening to coaches or sports medicine experts because they haven't been professional players in two decades?
javajosh 11y ago
>And it’s nice to think where, you know we talk about functional programming and lambda calculus and monads and this sounds all nice and sciency, but it really doesn’t affect what you do in software engineering there, these are all best practices, and these are things that have shown to be helpful in the past, but really are only helpful when people are making certain classes of mistakes. We're looking for the right set of constraints on the programming activity based on patterns of common mistakes.
- mikekchar 11y ago
  I find that best practices are a bit like design patterns. They are emergent in that a successful team will undoubtedly be using many of them. However, they are not something you can prescribe directly. Just like you can't use design patterns like ordering off of a menu (I'll have a bowl full of factories, a side order of singletons and a large bridge, please), you can't pick a handful of "best practices", sew them together and expect that, in itself, to make you successful. Being aware of best practices gives you the ability to move in that direction when you see opportunities. It is a mistake, in my opinion, to try to force the opportunities by dictating best practices (something that is done far too often in software process engineering). The best practice you choose depends a lot on the situation and the people involved. Having said that, I have all too often been in situations where I'm thinking, "I know how to be successful if we could do X, Y, and Z. I have absolutely no idea how to be successful doing the things we are doing now." It's tempting to try and force people's hands, but I have never seen it work. It's usually much better to search for an A, B, and C that will work instead. Not always easy, but it's I suppose it is how you demonstrate that you deserve the big bucks ;-)
  - mreiland 11y ago
    You've described exactly how I feel about these things.
vvanders 11y ago
"I would like to be able to enable even more restrictive subsets of languages and restrict programmers even more because we make mistakes constantly." This seems to be very much the direction Rust is going in.

145 points by dshankar 11y ago

daenz 11y ago

> It’s about social interactions between the programmers or even between yourself spread over time. There's nothing quite like looking at some code and saying "who in the hell did this?", then looking at the blame and realizing it was you, years ago. Learning from those moments is super valuable.

xahrepap 11y ago
I call that guy "Yesterday Joel" ... I'm constantly cursing that imbesel in normal conversation. Today Joel hates that guy. But Today Joel really looks up to Tomorrow Joel and hopes someday to be just like him.
- alexpersian 11y ago
  Tomorrow's his day to shine!

markbnj 11y ago

A great talk, pithy and full of insights gleaned from a lot of experience. Thanks for posting it.

ternaryoperator 11y ago

Very good essay. However, Carmac's view that there is very little quantified info about what works and what doesn't overlooks the work of software engineering practitioners, such as Capers Jones, who has long studied projects quantitatively and published detailed statistics on the effectiveness of different development approaches. His book "The Economics of Software Quality" is an excellent summary of his findings across thousands of projects. Reading it is like the first time you run a profiler and you realize that what you think you knew is true in part, but that other factors you'd not counted are have an outsize effect that you've misestimated.

coreyoconnor 11y ago
I've run into the same opinion from other developers: "there is very little quantified info about what works and what doesn't" In my experience they are looking for the wrong answers. They want an answer of how to design software. How to define the entities, classes, functions etc. Quantitative software development discusses less of design, IMO, and more organizational factors. EG: How a companies organization and processes impact quality. This is not what practitioners expect. Yet, this is where the science of software development is. Thanks for the book reference! An economic perspective on software quality sounds enlightening.
- shadowfox 11y ago
  Now I am curious as to whether there has been any work in quantifying (or at least studying) the impact of processes vs engineering (in the sense of design and development) on quality and long term maintenance of software. My google-fu is clearly failing me.
angersock 11y ago
Thanks for the reading suggestion! That said, it seems that his last practical experience in the field was better than two decades ago ( https://en.wikipedia.org/wiki/Capers_Jones https://en.wikipedia.org/wiki/Capers_Jones ). A criticism of that sort is available to other folks as well--I feel compelled to ask, "Interesting results, but what have you shipped recently?"
- brehaut 11y ago
  "but what have you shipped recently?" Looks like he has shipped 14 books and at least 36 papers on software engineering methodologies.
- hinkley 11y ago
  Don't you think this is a bit like not listening to coaches or sports medicine experts because they haven't been professional players in two decades?

javajosh 11y ago

>And it’s nice to think where, you know we talk about functional programming and lambda calculus and monads and this sounds all nice and sciency, but it really doesn’t affect what you do in software engineering there, these are all best practices, and these are things that have shown to be helpful in the past, but really are only helpful when people are making certain classes of mistakes. We're looking for the right set of constraints on the programming activity based on patterns of common mistakes.

mikekchar 11y ago
I find that best practices are a bit like design patterns. They are emergent in that a successful team will undoubtedly be using many of them. However, they are not something you can prescribe directly. Just like you can't use design patterns like ordering off of a menu (I'll have a bowl full of factories, a side order of singletons and a large bridge, please), you can't pick a handful of "best practices", sew them together and expect that, in itself, to make you successful. Being aware of best practices gives you the ability to move in that direction when you see opportunities. It is a mistake, in my opinion, to try to force the opportunities by dictating best practices (something that is done far too often in software process engineering). The best practice you choose depends a lot on the situation and the people involved. Having said that, I have all too often been in situations where I'm thinking, "I know how to be successful if we could do X, Y, and Z. I have absolutely no idea how to be successful doing the things we are doing now." It's tempting to try and force people's hands, but I have never seen it work. It's usually much better to search for an A, B, and C that will work instead. Not always easy, but it's I suppose it is how you demonstrate that you deserve the big bucks ;-)
- mreiland 11y ago
  You've described exactly how I feel about these things.

vvanders 11y ago

"I would like to be able to enable even more restrictive subsets of languages and restrict programmers even more because we make mistakes constantly." This seems to be very much the direction Rust is going in.