Facts and Fallacies of Software Engineering

Category: Programming
Author: Robert L. Glass
4.1
All Stack Overflow 8

Comments

by au750   2019-09-12
Hi,

If you want to be a generalist, you may want to learn things which are useful independently of the programming language.

Some books that would qualify in my opinion (as examples):

- Code Complete: A Practical Handbook of Software Construction, Second Edition by Steve McConnell

https://www.amazon.com/Code-Complete-Practical-Handbook-Cons...

- Facts and Fallacies of Software Engineering by Robert L. Glass

https://www.amazon.com/Facts-Fallacies-Software-Engineering-...

Learning the different approches taken by multiple programming languages is certainly useful. It may not be that much relevant which language it is unless you want a job specifically in that language.

I can't speak for Google but I guess it is more relevant how familiar you are with software development practices and general knowledge about architecture, design, testing, algorithms to name a few than a specific language.

by btilly   2017-08-19
I've never been a fan of extended analogies as a way of explaining things. At some point you need to understand the subject for itself, and not in terms of something else.

That said I strongly second his point about the value of keeping designs simple. And I have an interesting piece of evidence in support of it.

I just read http://www.amazon.com/gp/product/0321117425?ie=UTF8&tag=... and one of the "facts" that Robert Glass brings up is that a 25% increase in requirements results in a 100% increase in software complexity.

I put "facts" in quotes because the claim is only supported by one study and I have lots of questions around how one would define key terms like "software complexity". However based on experience I am inclined towards believing that something like this is true. If you further believe (as I do), that the source of the requirements doesn't matter, then adding internal requirements about design is going to result in complications.

As a result I am inclined towards simple, clean designs. I gladly introduce polymorphism, abstraction layers, and so on fairly frequently. But only if I see a concrete benefit from doing so. If I am not convinced that this piece of abstraction produces a net win within the context of this software solution, I don't do it.

(For the record I am not a software master by any means. In Zed Shaw's terms I'd be an expert, although early mentoring with the right person kept me from ever suffering from the love of complexity that he pastes all experts with.)

by InclinedPlane   2017-08-19
A lot of these come from Glass's excellent book "Facts and Fallacies of Software Engineering": http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...

It's quite concise (224 pages), but it's chock full of quite excellent advice. Each one of these points (and many others) is fleshed out in a separate chapter that gives a good deal of background, clarification, and supporting evidence.

by btilly   2017-08-19
Never meaningfully demonstrated? Have you tried to verify the claim?

Go read Peopleware. You will find described very carefully set up coding comparisons that routinely found a factor of 10 productivity difference between different experienced programmers on the same task, and also a discussion of what organizational factors lead to those productivity differences.

There is other research on the topic as well. For instance http://www.computer.org/portal/web/buildyourcareer/fa035?utm... cites "individual differences" research that found a 30 fold difference between mediocre programmers and the top programmers. That article is supposed to be a distillation of http://www.amazon.com/Facts-Fallacies-Software-Engineering-R... so I'd look there if you want citations into how that research was done and what exactly they found.