Live data from Hacker News

John Carmack discusses the art and science of software engineering

blogs.uw.edu

21–30 of 74 posts

Re: John Carmack discusses the art and science of software engineering

#21
I program mostly in Objective-C nowadays, but I started professionally with PHP. When I first started Objective-C, I found it really constricting in comparison. In PHP you can do things a thousand ways, most of the terrible. In Objective-C, specifically with Cocoa, things are a lot more rigid and prescribed. I found this frustrating, but love it now. It's made my PHP better too when I do occasionally go back. It forced me to think more about architecture. I also understand why my CS dept taught us Scheme first, not Java.

To link that back to the post, this is the type of constriction he's talking about to make better programmers. Cocoa and Objective-C restricted me to only writing at least halfway decent code. With PHP, because of it's flexibility, you're free to get things done quickly, but in a terrible way. Sure with PHP you can do things right too, but it takes a lot more self-discipline and also a priori knowledge.

Sorry to post yet another rag on PHP.

Re: John Carmack discusses the art and science of software engineering

#22
post #3

Running your code through static analysis can be eye-opening. And just like when you opened your eyes for the first time... you'll probably cry.

Static code analysis has a long-term benefit as well as the more obvious short-term benefit. That is, it teaches us to be better developers as we strive to have the static analysis catch less issues in our code the next time [1]. I used static analysis to improve my style for C, Python, and most recently Ruby [2].

I think it had a lasting effect on my personal coding habits. But every once in a while, I will use the tools on my new code and it still finds things. I would probably benefit from being more persistent in using these tools.

[1]: This assumes that the issues caught be your static analysis tool are valid concerns, which in my experience, they tend to be.

[2]: Some static analysis tools that I've used with Ruby are reek, roodi, flay, and flog. Reek and roodi report code smells. Flay reports structural similarities (opportunities for refactoring). And flog estimates the complexity of your methods.

Re: John Carmack discusses the art and science of software engineering

#23
post #3

Running your code through static analysis can be eye-opening. And just like when you opened your eyes for the first time... you'll probably cry.

If I had a dollar for every time I saw this... if(obj == null && obj.isValid()) I'd have approximately 960 dollars per project.

> if(obj == null && obj.isValid())

Why would you encounter this (often)? It seems to me that this code would never evaluate to true.

Re: John Carmack discusses the art and science of software engineering

#24
post #7

Earlier quoted context omitted.

The more you know, the more you realize you don't know. That would be a great book though.

Yep. Also, the smarter you are the more you tend to doubt yourself. Whereas less intelligent people tend to have more confidence in what they're doing. Bites me in the ass all the time.

one possible conclusion from that is that most "must-read" programming books are by authors who don't know that they don't know what they're doing.

Re: John Carmack discusses the art and science of software engineering

#25
With the NASA style devel­op­ment process, they can deliver very very low bug rates, but it’s at a very very low pro­duc­tiv­ity rate

I wonder how many non-developers understand this. I, along with the rest of my team, am trained in PSP (http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm) and TSP (http://www.sei.cmu.edu/tsp/) and we use it in our day-to-day development.

It definitely helps us keep our defect rate below one bug/kLOC but it's an expensive process that results in very low LOC/day productivity. If very low shipped bug counts are very important to your organization, great. But most businesses these days seem to care more about having a usable product than they do a perfect (or close to it) product. Especially if it's on the Web where you can do multiple releases per day.

As an industry, we really need to bear in mind that different business domains need radically different approaches to software engineering.

Re: John Carmack discusses the art and science of software engineering

#27

Earlier quoted context omitted.

If I had a dollar for every time I saw this... if(obj == null && obj.isValid()) I'd have approximately 960 dollars per project.

> if(obj == null && obj.isValid()) Why would you encounter this (often)? It seems to me that this code would never evaluate to true.

I hope he means

> if (obj != null && obj.isValid()) { }

Which is semantically correct due to the fail-fast evaluate of AND, it does require a double check since it's strange from a logic point of view. This is one the reasons that brace languages are hard to optimize since you can't commute things that ought to commute.

Re: John Carmack discusses the art and science of software engineering

#28

With the NASA style devel­op­ment process, they can deliver very very low bug rates, but it’s at a very very low pro­duc­tiv­ity rate I wonder how many non-developers understand this. I, along with the rest of my team, am trained in PSP ( http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm ) and TSP ( http://www.sei.cmu.edu/tsp/ ) and we use it in our day-to-day development. It definitely helps us keep our d…

Can you follow up with some information about the (P|T)SP experience?

I looked into it about a year ago and thought it was a ridiculous amount of overhead, and the blurbs about the initial data Humphrey used to create it was not persuasive. The "take our class" ads were not encouraging either.

So if its working for you in actual development, I'd LOVE to hear more about what it does/doesn't do for you.

Re: John Carmack discusses the art and science of software engineering

#29
Richard Feynman wrote[1]:

"We could, of course, use any notation we want; do not laugh at notations; invent them, they are powerful. In fact, mathematics is, to a large extent, invention of better notations. The whole idea of a four-vector, in fact, is an improvement in notation so that the transformations can be remembered easily."

What he said about mathematics, I think it applies even more to programming.

[1] The Feynman Lecture on Physics, Volume 1, Chapter 17

Re: John Carmack discusses the art and science of software engineering

#30
post #4

If he wrote a book about programming, I'd buy it in a heartbeat. Too bad that even he probably is still figuring everything out.

Well O'reilly recently did put out "Making Software What Really Works, and Why We Believe It" http://shop.oreilly.com/product/9780596808303.do which is a collection of essays backed by not lore, but actual scientific studies about software development. A few topics touched on in the book: • How much time should you spend on a code review in one sitting? • Is there a limit to the number of LOC you can accurately review? • How much better/faster is pair programming? • Does using design patterns make software better? • Does test-driven development work as well as they say? • How much do languages matter? • What matters more: How far apart people are geographically, or how far apart they are in the org chart? • Can code metrics predict the number of bugs in a piece of software? • Which is better: offices or cubes? • Does code coverage predict the number of bugs that will be later found? • What is right/wrong with our bug tracking systems today? • Why are graduates so lost in their first job?

If you haven't yet run across this book I highly recommend you check it out. At least for me it really meshed with my own quest to further delve into the mix of social and technical issues around software development. For more info on the book besides amazon reviews etc I also wrote up a blog entry last year which goes into more depth on the book http://benjamin-meyer.blogspot.com/2011/02/book-review-makin...

Post reply on HN