
John Carmack discusses the art and science of software engineering (2012) - dshankar
https://blogs.uw.edu/ajko/2012/08/22/john-carmack-discusses-the-art-and-science-of-software-engineering/
======
ternaryoperator
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.

~~~
angersock
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?_ "

~~~
hinkley
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?

~~~
angersock
Well, when software engineering is as good for one's personal social life as
being an athlete, perhaps I'll buy your argument. :)

More seriously, I see what you're saying--that said, there is a huuuuge
difference between how we develop software now versus even five years ago,
much less ten or twenty.

Github. Stack Overflow. Agile methods (ugh). Lean methodologies. Various
testing methodologies. Changes in the funding structure of companies. Order of
magnitude increase (comfortably) in debugging tools for web and network
applications. The entire single-page browser app movement. The entire GPGPU
movement. Truly convenient and open collaborative coding platforms.

The field, and the people in it, have changed a great deal, and we've learned
a lot. I'm increasingly skeptical of professors of professional software
engineering who don't, as a day job, professionally engineer software. This
applies to other folks--and I mean this nicely--like Uncle Bob or Martin
Fowler as well.

Folks like Carmack who have been pushing the envelope and getting scarred the
hard way for 20 years are probably simply better sources of learning.

~~~
InclinedPlane
TDD and agile are both about 15 years old, and both built on well-established
pre-existing development patterns. Github doesn't change many of the
fundamentals of how software improves in quality or how development works.

What I've observed in the industry has been a shocking lack of self-awareness
about application of best practices, and decidedly half-assed attempts to
improve. The state of the industry is not dev shops on the bleeding edge of
the best tools, best methodologies, best policies, etc. It's almost
universally a tale of failing to even get to "ok" in terms of well-known best
(or even better) practices. There are a ton of dev shops that don't do any
code reviews at all, and formal code reviews (which have been shown to be one
of the best methods for improving code quality) are almost unheard of. Even at
places that take testing seriously or do TDD they still typically don't do it
very well.

That's why folks like Uncle Bob and Martin Fowler continue to have so much
traction in the industry, because simply following good advice that was old 20
years ago is _still_ a huge step forward for the average, or even above
average, dev shop in the industry today.

Saying "we've learned a lot" just tells me that I shouldn't take you
seriously, because clearly we haven't. Software dev. is still a shambles.
Security is still a nightmare. Performance is still a nightmare. Quality and
robustness is still a nightmare. Work/life balance is still a nightmare.

Reading books like "The Mythical Man Month" (which is 40 years old!) still
holds a ton of lessons that have yet to be taken to heart by the majority of
the industry.

------
vvanders
_" I would like to be able to enable even more restric­tive sub­sets of
lan­guages and restrict pro­gram­mers even more because we make mis­takes
con­stantly."_

This seems to be very much the direction Rust is going in.

------
daenz
> It’s about social inter­ac­tions between the pro­gram­mers or even between
> your­self 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
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
Tomorrow's his day to shine!

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

------
javajosh
_> And it’s nice to think where, you know we talk about func­tional
pro­gram­ming and lambda cal­cu­lus and mon­ads and this sounds all nice and
sci­ency, but it really doesn’t affect what you do in soft­ware engi­neer­ing
there, these are all best prac­tices, and these are things that have shown to
be help­ful in the past, but really are only help­ful when peo­ple are mak­ing
cer­tain classes of mis­takes._

We're looking for the right set of constraints on the programming activity
based on patterns of common mistakes.

~~~
mikekchar
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
You've described exactly how I feel about these things.

